FGScenery Design
| This article is a stub. You can help the wiki by expanding it. |
Motivation
By using an abstract API, a terrain engine could be choosen at runtime. But it will definitely take some work to abstract out the terrain engine. The good thing is, such an abstract API would make the scenery subsystem more modular and easier to use than in its current, tightly coupled form [1].
Background
Peter Sadrozinski is looking at bringing in some new terrain ideas ( .SPT hierarchy ). If we use Mathias' quadtree approach to LOD, then the tilecache and tilemgr don't seem to be relevant.
Peter has done a quick experiment by removing tilemgr from the subsystem list, and adding the appropriate APIs ( schedule scenery for groundcache / FDM, and AI) to the scenery subsystem itself.
He also had to hookup the materialLib changed event through scenery as well. The main question, is, is there a specific reason the tilemgr is its own subsystem? It looks pretty tightly coupled with FGScenery subsytem. The idea is to derive FGScenery from a virtual base class with a well defined API, that we can then derive either the current FGScenery, or the quadtree based .SPT loader based on a fg property. This also formalizes the Scenery API so we could possibly abstract OSGEarth as well. (He has been studying the OSGEarth patches as well)[2]
The main question, is, is there a specific reason the tilemgr is it's own subsystem?
It looks pretty tightly coupled with FGScenery subsytem. My idea is to derive FGScenery from a virtual base class with a well defined API, that we can then derive either the current FGScenery, or the quadtree based .SPT loader based on a fg property. This also formalizes the Scenery API so we could possibly abstract OSGEarth as well. (I've been studying the OSGEarth patches as well)
All scenery classes should:
- insert and manage the terrain branch of the scenegraph.
- accept ground elevation queries.
- accept landclass queries ( for friction, etc ) Really, that's about it. caching, etc is an internal feature dependent on the scenery implementation.
maybe the scenegraph root should be created somewhere else. Currently, FGScenery creates the root and all branches (models, AI, AI interiors, particles, precipitation). I feel it would be better if it just worried about the terrain branch. [3]
- ↑ http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg30462.html
- ↑ Peter Sadrozinski (Jul 24th, 2016). [Flightgear-devel] TileMgr - does it need to be a global / subsystem .
- ↑ Peter Sadrozinski (Jul 24th, 2016). [Flightgear-devel] TileMgr - does it need to be a global / subsystem .