   3D Geometry Optimization
  When a 3D game becomes more complicated, there should be optimizations made for rendering the big scene (Not that I need that yet, but It's good to know). I would like to hear some ideas and techniques on how to do the following:1) If there is a big terrain which cannot be loaded all at once in the memory, how to load only one part a time?2) Should progressive meshes be used for the terrain?3) Objects that cannot be seen (too far/out of view) should be manually not rendered (using some own culling system). If not, then when I render them, directx will decide that they cannot be seen, but will it be done at the same speed?And is there any good tutorial for "Complicated scene management"?   
Quote:Original post by UriKiller1) If there is a big terrain which cannot be loaded all at once in the memory, how to load only one part a time?This can get pretty complicated, depending on how hardcore you are about it.  The general idea behind it would be 'when you get close to an unloaded area, load the missing geometry from file, create new buffers, and page out and old area'.Quote:2) Should progressive meshes be used for the terrain?I guess you can try, but generally people tend to manage the geometry themselves.  For example, look up 'geomipmapping'.  Full blown progressive meshes would be a bit too memory and CPU intensive, I would think.Quote:3) Objects that cannot be seen (too far/out of view) should be manually not rendered (using some own culling system). If not, then when I render them, directx will decide that they cannot be seen, but will it be done at the same speed?D3D does not perform any pre-vertexshader culling on the geometry to determine if it is in the current viewport.  This is your job to do.  You can use anything from a quadtree /octree to PVS to a simple frustum collision check to do this.   ;Quote:Original post by UriKiller1) If there is a big terrain which cannot be loaded all at once in the memory, how to load only one part a time?Quote:Original post by circlesoftI guess you can try, but generally people tend to manage the geometry themselves.  For example, look up 'geomipmapping'.  Full blown progressive meshes would be a bit too memory and CPU intensive, I would think.Please take some care when raccomanding GeoMipMapping on a memory-limited scenario.Assuming we need an out-of core approach, GMM presents two problems:1- Granularity. GMM in this conext does have a too big granularity. The whole idea of loading patches "on demand" is possible only by buffering. Although this is not really an issue since patches are usually small, the need for extra buffers mean that this vertex memory is often not visualized.2- High memory usage. This is THE issue. GMM is brute force with a twist. It takes the LOD0 level and builds additional LODs from that in a trivial manner. In a memory-limited scenario, this could have nasty conseguences for paging. The other way around is to accept again a lot of memory is not visualized. In a memory limited scenario, I believe patched brute force could have better results.In general, in memory-limited scenarios I would avoid considering an algorithm to be "fast" or "slow" depending on CPU time or generated vertices since the bottleneck is more likely to be located on disk loading or buffer fetching.Hugues Hoppe's homepage does present a nice paper on Geometrical Clipmaps. If you can afford VTF, this does have both the advantage of fine granularity, low processing time and memory usage. I wouldn't expect it to hit similar performance to non-paged approachs but this isn't the goal of out-of-core algorithms.