Autogen Ships:
Tom
I am impressed with what you have been able to do with ObjectGen !!
You have pushed it a lot far than I ever expected (providing great beta testing along the way.)
I guess I will have to hire you as my marketing department.
/Stu
Posts by lenidcamper
-
-
Is there maybe a bug in the derivedWayLenght calculation?
Eagle eyes.
You are correct I missed a multiply after the round.
In my haste to release I adjusted the test case rather than the code to get the expected result.
In test case 0.3.1.1 the wayLength was correct so I incorrectly concluded that I set incorrect test criteria in 0.3.1.2.
pushed a patch with the fix.
-
Do I have to understand the Round parameter in the way, that i.e. waylength is devided by the round faktor?
Then you compare the result against the mapEntry value?
For wayLength, Diameter (indirectly via wayLength) and roundedOSMtag the values are divided by the roundTo value, rounded to the nearest integer and multiplied by the roundTo value.
PS: for me the test.bat only works, if the content is modified to:
must be some Windows setting because it runs as shipped for me.
Can you tell me how you generated the digit models?
SketchUp has a 3DText menu/toolbar option. Enter text at origin, paint texture, scale, export as dae, run through modelconverterX to tgi, run through contentConverter to tmb, copy tmb to object library (they all use the same ttx), add entry to xml.
Once I got into batch production mode they took about 15-20 seconds each.
-
Released version 0.4
Major change is rebranding as ObjectGen (had to sack the entire marketing department )
- Added support for large OSM files. Allows bounding box override to be entered as argument to process subsections of OSM file.
Optimization for large node list processing.
- Added variability percentages for animation attributes to avoid "lock-step" effect on large groups of animated objects (ie wind farms)
See readme and UserGuide
-
They are 129, 98, 81, 56m.
Those raw length values would round to 130 100 80 60 assuming my length calculation agrees with JOSM.
So the only valid map entry would be 130, but it should have detected that one at least.
As you might of noticed there were no test cases for derivedLength since I did not think of a scenario.
I'll have a look to if there is any issue
-
There may be a box, BUT it can never be a black box.
Given the various technology constraints every scenery development effort is a compromise.
Every scenery developer will push the compromise in different directions.
Commercial scenery developers compromise on image resolution to keep the DLC size manageable.
Do you want high detail even at the risk of color imbalance, or is color corrected imagery paramount over resolution.
Some hobbyists focus on trees , others on autogen buildings, or highly detailed airports.
Any wrapper needs to have sufficient hooks that additional or alternate steps can be worked into the process.
Coming up with a flexible plug and play architecture is no small task.
/Stu
-
Released version 0.3
Added concept of derived tags to extract additional OSM data in a form easily used for object model selection.
-
I take your point even though my scenery process is without collisions
Level 9-12 at ZL 16
Level 13-15 at ZL 19
I guess I will just have to continue with my script.
My comments about intermediate states are still relevant.
-
it would be better to allow multiple selected squares to be installed, and that's on the list for 1.1
With the GeConvert concurrency control in 1.0, I don't see why install cannot be part of the standard workflow.
In 0.6 many concurent GeoConvert processes would eventually blow up the page file, so if I wanted to download multiple tiles overnight I would have to single (or double) stream the GeoConvert the next day. I ended up writing a powershell script that probed the install folder for last install date and installed all tiles converted after that date.
The problem with select to install (or multiple select to install) is that from the map there is no indication of "install state"
If I am expanding the coverage of an area at level 13 , I may not remember which tiles I just downloaded and converted.
It would still be useful to have visibility of intermediate states. (ie Downloaded, Converted, Installed)
But if the standard workflow will run end to end it is seems like a better approach.
/Stu
-
The choice of 0.1 was more a question of convenience than anything else. A tile of 1.0 degree was too big and anything in between was awkward for specifying coordinates by hand. Other people seem to have selected the same size for much the same reasons.
If there is support for cultivation from a map driven interface in the style of AeroScenery , then the awkward coordinates are not an issue. It comes down to optimal loading size. There have been discussions on optimal cultivation tile size for scenery load in other threads and I think the consensus is that for dense cultivation (particularly trees) smaller is better (even down to level 13). If the interface and cultivation modules are well integrated it should be irrelevant how many tiles are generated.
On a related topic. Currently the [size] parameter is hard coded to 5000. I should probably expose that in the XML in case people do generate different tile sizes.
/Stu
-
My idea for the far future
A good vision.
Early in my cultivation efforts I went to a tiled approach. I decided on 0.1x0.1 tiles. I created a utility that once I entered the center coordinates of a tile it spat out a set of bat files and power shell scripts to download the OSM file, download image file for tree autodetect, generate elevation contours, run scenProc, run osm2AFSobject, and deploy the results.
I decided on the 0.1 degree tile size because it was more user friendly than the AFS hex tile convention for names and coordinates.
When AeroScenery came out I contemplated switching to the AFS hex tile convention but have not gone there (yet). You really need a map driven interface to give usability and visibility of the cultivation state for hex tiles.
Any cultivation integration framework needs to be highly adaptable. For example as I am flying if I see an annoying cultivation glitch, I use my Flight Path Recorder and Google Earth to determine exactly where in which cultivation tile the discrepancy lies. I can then update the OSM or configuration file as required and add that tile to the Cultivate_These_Tiles batch file to run later. In my experience cultivation is an iterative process that is never really done.
Everybody has their own criteria on what "good enough" means. Or their own idea of what aspects of cultivation are important. For me trees are important. I use auto detect for trees to give a realistic sparse distribution at elevation and elevation contours to vary the tree species with elevation.
But autogen buildings leave me cold. Orbx True Earth is a step in the right direction, but I an not ready yet to give up the rich variation of the ortho image roof textures for the handful of stock textures. Even in commercial DLC's I have replaced most of the ortho images with higher resolution.
osm2AFSobject was developed because significant objects in the landscape are important to me, but again we need to work on the textures.
So in summary, I agree that more automation of scenery development is a good thing , but the core technologies are not yet at the state that there is a one size fits all solution.
A black box approach can only provide average results.
/Stu
-
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.
-
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.
-
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
-
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.
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.
-
with the default terrain mesh?
This was immediately on startup with custom elevation at level 14
However when I started again to get a screenshot. all towers were fixed with a appropriate exposure of the piers.
So i don''t know what caused the effect. If it occurs again I will definitely get a screenshot.
-
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.
-
This seems to have changed recently. I went back to look at some power pylons in an area I am familiar with.
Previously on "level ground" along the valley floor the piers were showing slightly.
Now there is a random amount (+- 2 or 3 M) of the piers showing (or buried).
The TOC size and TTH set have not changed from when the objects were placed correctly wrt ground level.
I am not sure exactly when this behavior changed, but probably within the last week or two.
I certainly would have noticed this effect while testing PylonGen and osm2AFSobject in that area .
/Stu
-
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
-
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.
