Difference between revisions of "Scenery LOD ideas for FlightGear"

From FlightGear wiki
Jump to: navigation, search
(Ideas: added more comments regarding threading and CDLOD, along with Project Rembrandt.)
m (Ideas: spelling fix)
Line 9: Line 9:
 
* Allocate a huge texture for a single 10x10 degrees area
 
* Allocate a huge texture for a single 10x10 degrees area
 
* load tiles as usual
 
* load tiles as usual
* render the tile to a small subpart of the huge texture
+
* render the tile to a small sub-part of the huge texture
 
* replace the tile geometry by a quad using the corners of the tile and map the small chunk of texture to it
 
* replace the tile geometry by a quad using the corners of the tile and map the small chunk of texture to it
 
* unload the tile geometry to free memory
 
* unload the tile geometry to free memory
Line 19: Line 19:
  
 
* For the LOD algorithm,  CDLOD [http://vertexasylum.com/2010/07/11/oh-no-another-terrain-rendering-paper/]  would probably be the best bet. CDLOD is like Chunked LOD, but plays nice with the GPU, and subdivides the LOD based on the distance from the camera/view point.
 
* For the LOD algorithm,  CDLOD [http://vertexasylum.com/2010/07/11/oh-no-another-terrain-rendering-paper/]  would probably be the best bet. CDLOD is like Chunked LOD, but plays nice with the GPU, and subdivides the LOD based on the distance from the camera/view point.
* the LOD algorithm should be moved to a seperate thread, otherwise it really will just drain on the main thread, and will have less, if not worse performance that is possible with a properly implemented LOD system. This may have some problems however due to the potential for the LOD system to have issues with the property tree and threading.
+
* the LOD algorithm should be moved to a separate thread, otherwise it really will just drain on the main thread, and will have less, if not worse performance that is possible with a properly implemented LOD system. This may have some problems however due to the potential for the LOD system to have issues with the property tree and threading.
 
* It may be wise to base the LOD changes off of Rembrandt, rather than the current FGFS code base. Deferred rendering from Rembrandt is a major rendering change, and it may or may not play nice with a new LOD implementation based on the non-deferred rendering of the current code base.
 
* It may be wise to base the LOD changes off of Rembrandt, rather than the current FGFS code base. Deferred rendering from Rembrandt is a major rendering change, and it may or may not play nice with a new LOD implementation based on the non-deferred rendering of the current code base.
  

Revision as of 15:53, 13 February 2012

Moving forum discussion to the wiki:

Ideas

Maybe there could be one single globe texture, and each tile btg would have it's correct texture coordinates into that image.

For LOD, I'd implement something like this :

  • Allocate a huge texture for a single 10x10 degrees area
  • load tiles as usual
  • render the tile to a small sub-part of the huge texture
  • replace the tile geometry by a quad using the corners of the tile and map the small chunk of texture to it
  • unload the tile geometry to free memory
  • repeat for each tile of that area
  • save the texture to disk and repeat for another 10x10 degrees area

Sharing the same texture for a huge area save state changes. The tile quad geometry could be saved in the btg format to a Terrain.LowRes directory tree, using the material property to reference the shared texture


  • For the LOD algorithm, CDLOD [1] would probably be the best bet. CDLOD is like Chunked LOD, but plays nice with the GPU, and subdivides the LOD based on the distance from the camera/view point.
  • the LOD algorithm should be moved to a separate thread, otherwise it really will just drain on the main thread, and will have less, if not worse performance that is possible with a properly implemented LOD system. This may have some problems however due to the potential for the LOD system to have issues with the property tree and threading.
  • It may be wise to base the LOD changes off of Rembrandt, rather than the current FGFS code base. Deferred rendering from Rembrandt is a major rendering change, and it may or may not play nice with a new LOD implementation based on the non-deferred rendering of the current code base.

References