Posts by lenidcamper

    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



    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


    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

    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

    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

    There is a fix for the "tree_row" issue


    In the scenProc\gdal-data\osmconf.ini


    In the [lines] section replace


    attributes=name,highway,waterway,aerialway,barrier,man_made,power,tunnel,bridge,railway


    with


    attributes=name,highway,waterway,aerialway,barrier,man_made,power,tunnel,bridge,railway,natural


    Arno said he will update the config for the next release


    cheers

    /Stu

    I've noticed that some tags don't work at all in SceneProc, I'm not sure if anyone else experienced with this or the author has a predefined list of key/values

    But back to the original question.


    I too have never been able to get natural="tree_row" to work either with LineToPolygon or PlacePointsAlongLine


    This may be a scenProc limitation.