Scenery LOD ideas for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m (→Ideas: spelling fix) |
(→Ideas: added some links for reference about improving rendering framerates on higher end hardware.) |
||
Line 21: | Line 21: | ||
* 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. | * 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 = |
Revision as of 20:57, 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.
- 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]