Scenery LOD ideas for FlightGear: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Ideas: added more comments regarding threading and CDLOD, along with Project Rembrandt.)
m (should be updated/merged)
 
(16 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Out of date}}
{{Mergeto|Scenery LoD}}
= Ideas (2012) =
Moving forum discussion to the wiki:
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.
Maybe there could be one single globe texture, and each tile btg would have it's correct texture coordinates into that image.
Line 9: Line 11:
* 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 18: Line 20:




* 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. Traditional CLOD implementations are not GPU friendly, this implementation is, and has the benefit of LOD based on camera position. The algorithm that would be the best bet for implementation is something similar to the streaming CDLOD implementation in the code samples.
* 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.
* For higher end GPUs, implementing some of the techniques from these blog posts may help increase FPS on OpenGL 3 and 4 level hardware. [http://rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/] [http://rastergrid.com/blog/2010/10/hierarchical-z-map-based-occlusion-culling/] [http://rastergrid.com/blog/2010/10/opengl-4-0-mountains-demo-released/] [http://rastergrid.com/blog/2010/06/instance-cloud-reduction-reloaded/] [http://rastergrid.com/blog/2010/02/instance-culling-using-geometry-shaders/]


= References =
= References =
* http://flightgear.org/forums/viewtopic.php?f=5&t=15132&p=148846#p148837
* http://forum.flightgear.org/viewtopic.php?f=5&t=15132&p=148846#p148837
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=12005&start=45#p137855
* http://forum.flightgear.org/viewtopic.php?f=6&t=12005&start=45#p137855
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=12005&start=45#p137873
* http://forum.flightgear.org/viewtopic.php?f=6&t=12005&start=45#p137873
 


[[Category:Scenery]]
[[Category:Scenery]]
[[Category:GSoC]]

Latest revision as of 07:37, 21 May 2020

This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

Merge-arrow.gif
It has been suggested that this article or section be merged into Scenery LoD.

Ideas (2012)

Moving forum discussion to the wiki:


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. Traditional CLOD implementations are not GPU friendly, this implementation is, and has the benefit of LOD based on camera position. The algorithm that would be the best bet for implementation is something similar to the streaming CDLOD implementation in the code samples.
  • 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.
  • For higher end GPUs, implementing some of the techniques from these blog posts may help increase FPS on OpenGL 3 and 4 level hardware. [2] [3] [4] [5] [6]

References