Object generation utility

  • Thank you Stu for the new version 0.2

    Especially the test.osm and test.xml helped me a lot, to understand how you defined and interpreted the OSM data.

    This helped me to define a Poma_base lift station.





    1) I am very thankful, that you included my wishes in your road map.

    Though size and direction of way objects are sure a tough thing to program, but they are the key to correctly placement non round objects.

    And this even in an appoximately correct size.


    _________________________________________



    2) Cable_cars and chair_lifts often have a station on the base and on the top end.

    The OSM value is typically arialway="station" and name="specific name"

    Can you please give me a XML example to assign a generic top and base station, independing of the given name?

    Purpose is to always generate a staion without adapting to the specific OSM name.


    osm key of the base_station


    OSM keys of the chair_lift way:


    osm key of the top_station (sometimes has a different name then the base station)


    I do have models for base and top:


    ____________________________________


    3) Another question:

    I look for a rule which assigns a Pylon style for small skilift with aerialway:occupancy of (2 .. 6)

    and another bigger pylon type for aerialway:occupancy of 8 .. 20.


    Can you help how I can do so?


    Cheers,

    Thomas

  • assign a generic top and base station, independing of the given name?

    If you want a generic station for all nodes aerialWay="station" you can ignore the name tag

    I look for a rule which assigns a Pylon style for small skilift with aerialway:occupancy of (2 .. 6)

    and another bigger pylon type for aerialway:occupancy of 8 .. 20.

    With 0.2 the only way to achieve this would be with a redundant mapping table as shown below.

    Code
         <modelNameMapping>
            <mapEntry key="aerialway:occupancy" value="2" name="AerialWays\Lift_Tower\small_tower"/>
            <mapEntry key="aerialway:occupancy" value="3" name="AerialWays\Lift_Tower\small_tower"/>
            ...
            <mapEntry key="aerialway:occupancy" value="6" name="AerialWays\Lift_Tower\small_tower"/>
            <mapEntry key="aerialway:occupancy" value="8" name="AerialWays\Lift_Tower\large_tower"/>
            <mapEntry key="aerialway:occupancy" value="9" name="AerialWays\Lift_Tower\large_tower"/>
            ...
            <mapEntry key="aerialway:occupancy" value="20" name="AerialWays\Lift_Tower\large_tower"/>
          </modelNameMapping>



    As part of the derived tag upgrade I am working on would be the ability to round an existing OSM tag.

    For example a new derived tag "towerSize" could be defined as aerialWay:occupancy rounded by 6 or 8 or whatever divisor you want.

    Then the towerSize tag can be used to select tower model in the mapping table. The derived tag exists only internally to osm2AFSobject not in the osm data.


    It was intended more to make use of real number tag data that you want to round down to integral values, but it would work for the redundant integer case as well.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Stu,

    thank you for the station tip. This already works for me (syntax for ver 0.2):

    What I did not thought about station:

    Bigger Gondola ways already have a building in pre cultivated areas. That will interfer with a poma_top or _base station.

    Especially in ORBX Swiss this will get a problem. A solution for Scenproc is to filter arialway=station, if you do the cultivation yourself.


    Regarding occuppancy I will better wait for your version 0.x

  • thank you for the station tip.

    I was surprised that this scenario worked.

    Turns out it is working because of a bug that got introduced due to the test.OSM

    I was relying on test.OSM as a regression test and I did not go back to test real OSM data.

    Much easier to debug with constrained dataset, but needs to work with real world data as well.


    The test.OSM was created from scratch and I did not put power="tower" tags on the nodes in the 1.x test cases except for test case 1.4 where i was testing the node selection behaviour but with default model so I did not detect the problem. If there are no node tags the model map matching will look at way tags. Because the power towers were untagged, the ways tags were compared and the cables="N" selection worked.

    With the real world OSM tags test case 1.3 failed, but your scenario worked.


    Most data is defined at the way level (ie cables or aerialway:occupancy) so the presence of node tags should not preclude the use of way tags.

    I need to combine the node and way tags before model matching. Are there any cases where there will be a conflict between node and way tags??


    The other problem with your configuration is that there is no way to distinguish between upper and lower stations if they are both tagged aerialway="station". In addition there is the collision issue between stations and scenProc cultivated buildings.


    Lessons learned: cut and paste real OSM data for the test cases to avoid unrealistic sparse data, Also sanity check against real OSM



    Mea culpa!


    /Stu

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Another idea, which has nothing to do with osm2AFS but a lot with skying areas:


    If you like night skying and illuminated tracks, just insert these two lines into your scenProc script:


    PlacePointsAlongLine|piste_type="downhill"|SINGLE|20;20|-5;5|10|String;point|ski_light_orange|hdg

    CreateAF2Light|point="ski_light_orange"|1.0;0.6;0.0|30|0;0;1|3


    The only other thing to do is edit the /scenproc/gdat-data/osmconf.ini file:

    on the [lines] section add:

    # keys to report as OGR fields

    attributes=name,highway,waterway,aerialway,barrier,man_made,power,tunnel,bridge,railway,natural,aeroway,piste:type


    Then the result will show all the ski pistes:


  • after you changed the Schema again...

    No schema change, just a code fix.



    a similar building for top and base.

    Building model needs to be symmetric (along the lift line) because top and bottom stations will have the same orientation with respect to the lift line.


    That is the benefit of explicit node models for bottom and top stations so they can have appropriate structure and orientation.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Stu,

    maybe you can implement a command, which is modifying the direction attribut, so the building always shows towards the aerialway?

    I think no one will spend the time to assign that manually, so I am searching for a method to automize this. Better this, then no building.


    Can you help me with my railway sign scenario?

    I do not want any model, if it is not contained in the modelNameMapping list.



  • I do not want any model, if it is not contained in the modelNameMapping list.

    The scenario as specified would work (after a fashion) if signal_unwanted is not an object model file.

    There will be unnecessary entries in the TSC and the TM.log will have error entries "... signal_unwanted.tmb not found" but the offending entries will not be rendered and AFS will carry on without any notable issues. However not a very elegant solution.<X


    A better approach would be through the <referencedNodes><selectionCriteria>

    Sort of an extension of test case 1.3. if the selection criteria contains railway:signal:minor:form or railway:signal:distant:form or railway:signal:main:form

    only those nodes would be mapped and rendered. The default model could be blank in that case.


    However, to combine those criteria into one configuration would require the orCondition production. I left a place holder in the schema for this, but did not implement it because I could not think of a scenario. Higher priority for this item in the roadmap.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

    Edited once, last by lenidcamper ().

  • Thank you Stu, for confirming my scenario. I was hoping that I did something stupid, but now it seems to be the only way, before you implement the or statement.

    Unluckily there is no other common key I could use to filter the signal. And the count I get with the key=railway and value="rail" is overwhelming.


  • maybe you can implement a command, which is modifying the direction attribut, so the building always shows towards the aerialway?

    Providing an explicit orientation to a model exposes some awkwardness in specification and interperetation.


    AFS has two competing properties to represent orientation


    [tmsimulator_scenery_object] has [orientation]

    and
    [tmsimulator_scenery_object_animated] has [rot_in_degree]


    Currently osm2AFSobject calculates orientation for nodes along ways to give alignment of power pylons or lift towers (or signal lights it seems!!) relative to the direction of the way but requires no specification.


    The default model and map entry elements allow rotation_in_degrees to be specified counter-clockwise from north.


    If orientation can be specified for a model in the osm2AFSobject configuration what is the interpretation?


    Should not be specified for an animated model. Not possible to prevent this with existing schema.

    For a single node it should mean CCW from north as for the [orientation] and [rot_in_deg]

    For node along a way is it offset from nominal way orientation?

    If this is defined on a model entry it only applies to the first (or last?) node in the way.


    Not very clean functional requirements.


    The ski lift station scenario can be solved with explicit model declarations.


    I don't think I want to complicate the osm2AFSobject feature set with such a specialized case.


    /Stu

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • How should I otherwise assign an explicit model declaration?

    Renaming the station would work. Although if both stations have aerialway="station" tag you cannot use that as a selection criteria in the mapping table. You would need to use name="LesCrets" for the upper station.


    or


    Add a tag with k="model:name" and v= "AerialWays\LesCrets\LesCrets_lower_station" on the lower station node.

    Then create LesCrets_lower_station.tmb from a model with appropriate footprint and orientation.


    The explicit model will be used instead of a mapped model.


    PS


    The mapping table was designed as a selection by value for the same key.

    Using multiple keys in a mapping table may work, but the result will be unpredictable if both keys appear on a node. it will depend on the order the tags appear on the node.


    Another benefit of the explicit model:* tag aproach is that public OSM tag data does not have to be modfied.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

    Edited 2 times, last by lenidcamper: ps pps ().

  • Stu, congrats on all the progress with OSM parsing for 3D objects!


    Would it be easy for you to spin-off pre-configured mini-programs for different objects for the casual / novice scenery builders? For example, a user could:


    1) download an OBJGEN-POWERPOLES add-on utility,

    2) copy their OSM file to the correct folder,

    3) run the utility (no script/config file editing required),

    4) then move the newly created POWERLINES folder with TSC file to their FS2/scenery/places folder

    5) go test fly the new objects


    No more than 5 minutes of effort


    This divide-and-conquer approach might make it easier to fine-tune some of the oddities of each object type and allow the casual / novice user base to easily try the objects they are interested in.

  • Would it be easy for you to spin-off pre-configured mini-programs for different objects for the casual / novice scenery builders? For example, a user could:

    I am focused on the core functionality at the moment.


    If one of the beta testers would like to create scenario based configuration files and batch file wrappers I would be happy to include those in the next release.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • My idea for the far future

    A program or script which does the following:

    Select needed area with a modified Grid generator (level 10 tiles)

    Select the needed objects per GUI checkmarks.

    A model library containing the typical objects with alternates.

    Fetching the osm data as tile 10 size.

    Calling Scenproc with adapted script and elimination of osm2AFS objects

    Calling osm2AFS with the adapted script according to the checkmarks

    Copying the files: (control tsc for toc, toc itself and tsc from osm2AFS) to appropriate places directory, based on grid tile name


    The goal should be minimal user interaction (and no editing of OSM data).

    A kind of ini file, editable for the more experienced should allow to add additional models and scenes could contain the pathes to them. This should allow to modular combine the needed scenarios per checkmarks.


    The tile 10 names and coordinates can be taken from vogel69 s tool: Grid generator: https://flight-sim.org/filebas…/127-afs2-grid-generator/

    If an adaption is needed, he maybe will help.

    Also nickhod Aeroscenery could be a good starting point, as it already knows about tile grid and shows a map. https://github.com/nickhod/aeroscenery

    Tile 10 size is not too big to cause major delays during loading.


    What does this community think?



    Google Earth pro with level10 tiles


    I already do this semi-automated with some batch/drop files, but a programmer is needed to do it fully automated.

  • Great Idea ! Probably it would be easier for people with basic knowledge like me, with some kind of « preset » scenarios and preset « acceptable « objects. For exemple, aerial ways (gondola, chair_lift, cable_car etc...) with typical pylons (taller for chair and cabins and car than platter or tbar), with basic upper station, would be great. I think it could be the case for windmill, and other repetitive architectural objects, with 2 or three « basic « xml objects...

    Thank you very much