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

NewBTGLoader

From FlightGear wiki
Jump to: navigation, search
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2018.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear 3.x. 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.


The current Loader

The .STG is loaded, and .BTGs (base, airports) are then loaded via SGLoadBTG() in simgear/scene/tgdb/obj.cxx.

  • calls SGBinObject's read_bin, which performs the load of the actual .btg file.
  • generates a material cache based on the tiles center coordinate
  • rotates the tile for axis alignment. (this could be done in terragear, if we want - I haven't seen how long this takes.)
  • creates tileGeometryBin which contains the tile geometry - material sorted triangles, fans, and strips. Also all the different types of lights in an intermediate format.
  • it then collects the material sorted triangles into an OSG node tree, and adds it to the scene graph
  • if simplifyDistant is set, it the runs the OSG simplifier on the OSG node tree
  • it then creates an OSGPageLOD node for deferred detailing of the tile, as the tile is most likely loaded some distance from the view camera ( other than initial startup )

The paged LOD node contains:

  • A pointer to the OSG node tree if simplify near is not the same as simplify far.
  • A RandomObjectCallback used to generate trees, lights, objects, and buildings.

The RandomObjectCallback object is populated with the material cache, the tileGeometryBin, and the path.

When the randomObjectCallback read_node method is called by OSG, it uses the material cache and tileGeometryBin to position and texture all of the random objects.

Issues with the current loader

tileGeometryBin is huge - much larger than the OSG node tree, and it won't ever be deleted as long as the tile is in the scene graph.

  • I believe we can refer to the EffectGeode in the RandomObjectCallback, then re-implement the random object positioning code to use the osg::Geometry node's triangle list instead of the texturedMaterialMap.
I now have a visitor in the RandomObjectCallback implemented, and I can retrieve the triangle list and material for each list. --Psadro gm (talk) 13:17, 10 January 2015 (UTC)
  • We don't have the local material information of these triangles - we need to store that away with each Drawable. It looks like we only save 1 drawabe per EffectGeod, so we could add a userData to it.
Since EffectGeode is a SimGear class, we can just add the material pointer - SGMaterial inherits from osg::Referenced - use a smart pointer. --Psadro gm (talk) 13:17, 10 January 2015 (UTC)
  • It also looks like we need whatever SGTexturedTriangleBin::getTextureIndex gives stored as well. The material code wants this.
Upon closer inspection - we can easily retrieve this from the osg::Geometry as well - it's just the floor of the x coordinate of the first triangles first vertex. ( unsure what it's used for, really ) --Psadro gm (talk) 13:17, 10 January 2015 (UTC)

New loader ideas

  • since we have triangle indices from the Drawable, generating polygons from triangles should be fast. Maybe we don't need to store this in the .stg file? This would work with current scenery as well, instead of needing a new world wide scenery build.
  • current progress is detailed in the forum here : http://forum.flightgear.org/viewtopic.php?f=5&t=25081&p=229490#p229490