I don't really know how to go about fixing these things, I'm just reporting on what I think needs work - not that this needs to be done now, of course (optimization comes last in my book). I just anticipate it becoming more of a headache in the future when we try to increase scene complexity. Of course, it will need to be fixed to be able to compare visually with GPU-optimized sims.
One thing I was thinking about was minimizing the number of vertices sent to the GPU by using what we already have.
For instance, we have a tree structure containing three levels of detail. Level one (the root, or actually FlightGear/data/scenery) contains subdirectories of 10x10 degrees (am I correct here?), which all contain directories with 1x1 degree chunks.
What we can do (quite easily I presume) is storing highly optimized scenery data of the particular chunk (either 10x10 or 1x1 degree) as a file into the root directory of that particular chunk.
For example (default scenery in the base package):
Scenery/ Scenery/w130n30.btg.zg Scenery/w130n30/w123n37.btg.gz Scenery/w130n30/w123n37/
If the scenery is too far from the viewer to show useful data, then the optimized version could be loaded until it comes close enough to show the details.
Now, if you make sure the outline elevation of the optimized and the detail data is the same you wont even see any gaps in the scenery. It might be a good idea to leave all the highest points of the chunk visible also but that might need a good algorithm.
Erik
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
