Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

STG Verbs

From FlightGear wiki
Revision as of 13:04, 24 September 2016 by Hooray (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.

Update 09/2016: Stuart committed the code to enable two new STG verbs:


These were introduced to Modify FG to recognie the new STG verb and add controls to enable/disable loading these models and logic to disable the random objects and buildings for tiles (or better sub-tiles) when these are enabled and exist.[1]

it is a good idea to have new STG verbs[2]

The STG verbs will be a very welcome incentive to also get the piers and platforms into the LOD scheme. [3]

the STG verbs use an element of randomness in the LOD range. If, instead of a single mesh of 1km sie, we had (say) 4, each of 2kmx2km, the apparent popping would should be reduced, while still retaining around the same number of buildings per mesh and the performance advantages that provides. That's about the same size of "mesh" that we use for trees and buildings.[4]

To enable the reading of these verbs you will need to set /sim/rendering/building-mesh=true and obviously reload scenery.[5]

as the name suggests, loads buildings and sets LOD to /sim/rendering/static-lod/rough and /sim/rendering/static-lod/detailed respectively. The verbs are only parsed by the STG loader if /sim/rendering/osm-buildings=true so there will be no runtime or loadtime impact on systems with this disabled. The reason for the two verbs is to allow osm2city to generate two levels of LOD for larger and smaller buildings. It currently does this by generating a single model with two meshes, one for each LOD level. Rather than do this within the model, I think it's more effective to handle this in the STG loader as two separate models and simplify the scenegraph by saving an extra LOD node.[6]