Just posted the initial release of osm2AFSobject
So kick the tires and see if the wheels fall off.
/Stu
Just posted the initial release of osm2AFSobject
So kick the tires and see if the wheels fall off.
/Stu
Substract the two X Coordinate range (projected) values from each other and multiply them by 0.476 and you get the diameter in meters.
Yes it is possible to calculate the way length (which would be the circumference in the storage tank case).
It would then be able to calculate diameter based on an assumption that the way is circular.
In any case the calculated number would not be particularly useful for model selection.
The height tag for windmills is useful because 70M or 90M are really a class designation not a specific measurement.
The calculated diameter will be a float value. Even if converted to an integer how much variation will be based on the drawing accuracy of the way author.
After spending a lot of time to generalize the osm2AFSobject utility I am reluctant add back in specific assumptions about features.
It may be possible to add the concept of a computed tag with a binning capability to smooth out variance.
You don't want a different model map for every meter in size.
In any case that will not make the next release which I am trying to get out the door (as a beta at least)
There are a lot of changes from PylonGen to test.
The animated windmills, and ski-lift line with top station scenarios are working.
I need to work on documentation and some stress tests before I release.
/Stu
Of course It would be great if it would possible to cultivate cableways and skilifts pylons too,
I had though of ski lifts.
It should work out of the box for the generic lift pylon case.
What I wanted to try was defining explicit models for the first and last nodes to give lower and upper stations.
On my list of scenarios.
/Stu
Please have a look at Vienna tanks here: 16.5026131, 48.1730016
thanks
the tank instances I have come across so far have had very sparse data.
I see what is there.
manmade water towers also?
the XML should work for water towers as well
there is no "feature" specific logic
As long as there is enough tag information to select the feature and map to a model, it will work
the algorithm is as follows
for each way configuration
for all ways that match the way selection criteria
if the way configuration is flagged as one node issue one object at the center point of the feature
with the model name selected by the model precedence order
otherwise for each node in the way that matches the node selection criteria issue an object at the
node position with appropriate model
then for each node configuration
for each node that matches the node selection criteria issue an object at the node position
with the appropriate model.
if the model is animated add the object to the animated object list instead.
Display More
where rot in degree should be a random parameter for wind turbines
so rot_in_degrees means initial angle for the animation?
This is an example of where I am headed with the XML configuration.
Please review for flexibility for the scenarios you have in mind.
I've posed some questions in the comments.
Much easier to read if you paste into Notepad++
/Stu
<?xml version="1.0" encoding="utf-8"?>
<osm2AFSobjectConfiguration>
<!--
Relative path prefix to be added to paths defined in model name declarations
Resulting path from generated TSC to the TMB file in the deployed scenery folder structure.
Yields paths of the form
..\..\..\..\objects\modelGrouping\modelName\tmbFileName
for the folder structure in the generated TSC.
D:\MyExtraUserFolder
-objects
-modelGrouping
-scenery
-places
-sceneryPackage
-subFolder
- xxx.TSC
Defining the relative path prefix here avoids duplicate specification of path prefix in the XML or OSM file..
-->
<relativePathPrefix>"..\..\..\..\objects\"</relativePathPrefix>
<!-- ============================================================================================ -->
<!-- configuration to process way features of interest -->
<wayConfiguration>
<selectionCriteria>
<!-- criteria to select ways to process
only "and" criteria currently supported (any scenario need "or" criteria???)
exclusionCriteria may be needed.
-->
<andCriteria>
<!-- select ways matching key value pairs. -->
<keyValueEntry key="power" value="line" />
</andCriteria>
</selectionCriteria>
<!-- OSM tag key used to specify explicit model name. Explicit model name takes precesdence. -->
<explicitModelNameKey>"model"</explicitModelNameKey>
<!-- Default model name to use if no other can be resolved-->
<defaultModelName>"PowerPylons\6-cables\6-cables"</defaultModelName>
<referencedNodes>
<selectionCriteria>
<!-- selection crtieria for nodes referenced from a way. Only process nodes matching key value pair.
Some power lines have extraneous nodes that are not tagged as power="tower".
No object should be generated for these.
-->
<andCriteria>
<keyValue key="power" value="tower" />
</andCriteria>
</selectionCriteria>
<modelNameMapping>
<!-- select model name based on tag with key value pair -->
<mapEntry key="cables" value="3" modelName="PowerPylons\3-cables\3-cables"/>
<mapEntry key="cables" value="4" modelName="PowerPylons\4-cables\4-cables"/>
<mapEntry key="cables" value="6" modelName="PowerPylons\6-cables\6-cables"/>
<mapEntry key="cables" value="8" modelName="PowerPylons\8-cables\8-cables"/>
<mapEntry key="cables" value="10" modelName="PowerPylons\10-cables\10-cables"/>
</modelNameMapping>
</referencedNodes>
</wayConfiguration>
<!-- ============================================================================================ -->
<wayConfiguration>
<selectionCriteria>
<andCriteria>
<keyValueEntry key="man_made" value="storage_tank" />
</andCriteria>
</selectionCriteria>
<!-- storage tanks are often depicted with a way defining the circumference.
if <oneObject> is true a single object will be exported at the midpoint of the way.
Any other tag information to aid in model selection seems to be missing.
An explicit model name tag can be added to the circumference way.
This is easily done in am OSM editor like JOSM where you cam measure the diameter of the tank
and select an appropriate sized model accordingly.
If no way is defined for a tank, a single node at the center with model key set would work as well.
-->
<oneObject>"true"</oneObject>
<explicitModelNameKey>"model"</explicitModelNameKey>
<defaultModelName>"StorageTanks\40MDome\40Mdome"</defaultModelName>
</wayConfiguration>
<!-- ============================================================================================ -->
<nodeConfiguration>
<selectionCriteria>
<andCriteria>
<keyValueEntry key="man_made" value="storage_tank"/>
</andCriteria>
</selectionCriteria>
<explicitModelNameKey>"model"</explicitModelNameKey>
<defaultModelName>"StorageTanks\20mFlat\20Mflat"</defaultModelName>
</nodeConfiguration>
<!-- ============================================================================================ -->
<nodeConfiguration>
<selectionCriteria>
<andCriteria>
<keyValueEntry key="power" value="tower"/>
<keyValueEntry key="generator:source" value="wind"/>
</andCriteria>
</selectionCriteria>
<explicitModelNameKey>"model"</explicitModelNameKey>
<defaultModelName>"Windmills\90M\90M"</defaultModelName>
<modelNameMapping>
<mapEntry key="height" value="25" modelName="Windmills\25M\25M" />
<mapEntry key="height" value="70" modelName="Windmills\70M\windturbine_v39_70m_0_5">
<!-- animation specifciations may be model specific ???
(are there any other animation specification properties???)
(Do we need animation specification for explict or default models???)
-->
<animation rotation_in_degrees="115.9" duration ="0.0" time_scale="1.2"/>
</mapEntry>
</modelNameMapping>
<!-- orientation seems to be ignored for animated models. "windWard" would be nice option!-->
<orientation>"0.0"</orientation>
</nodeConfiguration>
</osm2AFSobjectConfiguration>
Display More
One big wish I have for Stu is the implementation of animated windturbines.
I need to get the XML spec working first.
The generalized utility is currently working equivalent to PylonGen using the XML, but there are a lot more scenarios to test.
The animation configuration does not look like much of a stretch. Good sleuthing
/Stu
Such a tool makes me thinking. How can it be used outside of the power pylons.
I am working on a generalization that uses an XML file to define way or node selection criteria and feature to model mapping criteria.
Stay tuned.
/Stu
I also noticed some AFS2 pauses with a moderate number of pylons.
As I said the models were straight forward conversions from SketchUp to TMB
The updated V1.0.1 release includes the SketchUp files in the PowerPylonModels library.
Somebody with more 3D modelling experience than I can have a go at optimizing them.
/Stu
PS switching from cylindrical to square pylons would probably help
Great tool! I wonder too if this tool can easily be adapted for other objects e.g. farmhouses.
Certainly it is possible to process other OSM features. The power lines were sort of low hanging fruit with no current solution.
Even with a well defined set of features of interest to process there needs to be a way to specify the selection of
OSM features and mapping to model names.
We already have (some of) that in scenProc. The PlacePointsOnLineVertices command has the capability to create objects with defined orientation.
I think the mapping of OSM attribute values to model names is useful because it covers 90% or 95% of the cases without intervention.
I don't think scenProc has enough flexibility to do that. Also scenProc is missing is the ability to generate the TSC files.
I am a fan of extracting as much as we can from OSM. I am thinking about an XML configuration file to specify the feature to model mapping.
I'll have to think if there is a way to generalize this without adding a lot of complexity. I don't want to reinvent scenProc.
/Stu
Posted an update
I think this fixes the locale dependent formatting issue.
Some other cleanup as well.
I suspect something to do with culture dependent number formatting for the mid point.
The pylon positions were formatted correctly?
/Stu
sorry if it was not clear
The following command entered from the command line in whatever folder you unzipped the PYLONGEN
PylonGen.exe .\myOSMfile.osm
would process the OSM file and generate the TSC and log file in the same folder. The TSC file would expect the PowerPylonModels folder at the same folder level in the scenery/places hierarchy that you deploy the TSC file.
PylonGen.exe .\myOSMfile.osm ..\
would allow the PowerPylonModels folder to be moved up to the parent folder of the TSC file in the deployed folder hierarchy
The PowerPylonModels folder is only used at AFS2 run time not during the PylonGen step.
Hope that clarifies things. Any other issues let me know
/Stu
What are your typical pylon counts in your generated TSC files?
The models average 7,000 or 8,000 vertices. (according to ModelConverterX)
I did not spend any time on model optimization. I was more interested in proof of concept.
It will be possible to substitute more efficient models if required.
A significant feature of VFR flight are lines of power pylons stretching off into the haze.
In the absence of a MakeAF2Object directive in scenProc, I created a utility PYLONGEN to parse OSM files and generate a TSC file with entries
for each node along ways tagged with k="power" v="line".
PYLONGEN will use the bounds defined in the OSM file to calculate the coordinates
for the TSC and reject any pylon points out of bounds.
PYLONGEN expects the arguments
- path to OSM file
- [optional] relative path to PowerPylonModels folder in the deployed scenery folder structure. Assumes the same folder if arg not provided. This allows positioning the
PowerPylonModels folder to be shared by multiple tsc files in a folder hierarchy. I place the generated tsc (along with other cultivation files) in places subfolder
for each 0.1x0.1 cultivation tile. The PowerPylonModels folder at a higher level in the hierarchy can be shared by all tiles.
The utility will produce TSC and log files in the current directory.
Model selection precedence
If the power="line" way has a tag model="yourSiteSpecificModelName", the specific model will be used for that line. This allows customization for distinctive pylon styles.
If no model defined but the line has a cables tag defined for the way, a generic N-cables model name will be be selected based on number of cables. A number of generic pylon models have been provided. if you encounter cable arrangements not supported there will be "not found" errors in the tm.log for the missing tmb files. You have the choice of creating a model for that configuration or setting a specific model for the way .
As a last resort the defaultPylon model will be used.
Way and node ids are added to the TSC to track back to OSM file for any missing or spurious towers.
Model development
Example models were converted from SketchUp 3DWarehouse (I found ZoSoChiles 3d Model conversion post most helpful in getting the pylon models converted.)
The model base must be centered on the drawing origin.
No geo-position info should be defined in the model.
The model should be aligned for a east west cable run.
The piers should be extended well below grade to allow for slope placement. Steep slopes may require manual elevation tweaks in the TSC.
Limitations
You may need to set the time of day to align 3D generated shadows and ortho image shadows.
Ortho image of power cables are sometimes highly visible and may not be aligned with implicit line of sight from the camera position. I do not think anything can be done to fix that.
*****************************************************************************************
*****************************************************************************************
**** Note PylonGen has been superceded by generalized XML configuration driven osm2AFSobject
*****************************************************************************************
*****************************************************************************************
The PYLONGEN utility has been uploaded to flight-sim
/Stu
I have encountered (and a number of other people have noticed) a phenomenon I am calling the "clearcut" artifact.
When cultivating trees in large forested areas you sometime see a linear swath where no trees were cultivated despite
the fact that that area is within a landuse="forest" feature.
I was not sure if this was a scenProc or AFS2 issue so I contrived some simple test cases.
I defined a 0.1x0.1 degree tile in the middle of a lake with a single landuse="forest" featue for ease of evaluating the results.
Cultivating with 0.0001 separation and maximum randomness yields 938,000 trees in the first example.
This gives an even distribution as one would expect. (the far corner is haze obscured not truncated)
with 0.00009 spacing we get 1,164,000 trees and clearcut artifacts appear
and with 0.00008 spacing we get 1,474,000 trees
It is clear that the problem gets worse with the number of trees but still not not distinguish between a scenProc issue or an AFS2 issue.
Cultivating at 0.0001 separation a second time and loading both TOC files (1,800,000 trees) the artifacts appear
And at 0.00009 two TOC files (2,328,000 trees) the artifacts are worse than a single 0.00009 TOC
Since both TOC files will render correctly on their own, but show artifacts when loaded together, it seems
the the issue is in AFS2 management of plant_list entries. The cases with clearcut artifacts have multiple
WARNING: more than 20480 trees planted
entries in the log.
Can IPACs explain the rational for the 20480 limit and the resulting rendering behaviour?
thanks
/Stu
natural="tree_row" is a line feature
LineToPolygon|FTYPE="LINE" And natural="tree_row"|3|String;landuse|tree_row
PlacePointsInPolygon|landuse="tree_row"|0.00005;0.00005|1.0;1.0|INHERITPARENTATTR
CreateAF2Plant|landuse="tree_row" And FRAND >= 0.2|4;12|0|broadleaf
CreateAF2Plant|landuse="tree_row" And FRAND < 0.2|5;10|0|conifer
will create a 3m polygon along the tree_row features and place points in the landuse="tree_row" polygons
The PlacePointsAlongLine directive is not well suited for tree cultivation.
/Stu
This was well inside the area with custom mesh. The TIFF data looks clean (no spikes or walls).
It was quite reproducible .
Duplicate 9-11 mesh => problem.
No duplicate mesh => no problem.
If nobody else encounters this problem then good.
I just did not want anyone else to spend a day or two chasing down the same issue.
/Stu
if you used your own data to convert level 7 too instead of using the AeroFly mesh
Be VERY careful duplicating Aerofly mesh levels.
I recently experienced a nasty problem that took quite a while to sort out.
I encountered major "rendering disruptions" that appeared to be repeatable at a specific location (with some variation with altitude and speed). In the ASG29 there was significant warping/rippling of the display for several seconds. In the R22 it was fatal. There were the display ripples plus the cyclic started oscilating wildly ignoring joystick input, resulting in eventual death spiral.
At first I thought it was some cultivation issue since I was experimenting with dense forest generation.
Eventually I tracked it down to custom elevation mesh. It turns out there was a tile that for some reason (I blame my evil twin) had level 9,10 and 11 TTH as well as 12, 13 and 14
Removing the duplicate TTH files eliminated the disruption. It may be that the revised scenery load algorithm worked harder to resolve and render the duplicate mesh. The R22 flight model is more sensitive than the ASG29 so the negative side effects may be amplified.
In any case duplicating TTH files seems to be a bad idea
/Stu