Posts by lenidcamper

    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

    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

    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


    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