Rendering 65,000 polygons
Author
I'm working on an engine in directX. I have this terrain setup that consists of approx 65,000 polygons that is causing a bit of a performance problem. Is there any way to speed up the rendering? Each polygon is being rendered with the draw index primitive method.
Are you drawing all 65,000 polys with one draw call? Because if you are, then it shouldn't give you any performance problems unless you have a really old 3D card.
I would assume that you have a batching problem, i.e. you have too many state changes or draw calls in your rendering process. If that's not the case, try only rendering the parts of the terrain that are inside the view frustum using something like a quadtree to create a hierarchy of terrain tiles.
I would assume that you have a batching problem, i.e. you have too many state changes or draw calls in your rendering process. If that's not the case, try only rendering the parts of the terrain that are inside the view frustum using something like a quadtree to create a hierarchy of terrain tiles.
You can definitely use a terrain Level of Detail (LOD) technique or two, rendering the whole thing at once is not a very good idea when it comes to performance.
There are many algorithms, the most important are the ones targetting the vertex/polygon count, one possible algorithm that you can use is called "Chunck Level of Detail" or CLOD, which tesselates vertices based on distance from camera, ie. the actual terrain data that you keep in memory to draw are dynamic like a particle system.
There is also a technique called geo-mipmapping, which makes the texture tiles that are distant from the camera less detailed.
I have looked around a little and I got those two techniques for terrain LOD:
- Continuous LOD Terrain Meshing Using Adaptive Quadtrees
- Real-Time Dynamic Level of Detail Terrain Rendering with ROAM
The Terrain Geomorphing in the Vertex Shader article in gamedev also has useful information.
Well, I hope I helped :)
There are many algorithms, the most important are the ones targetting the vertex/polygon count, one possible algorithm that you can use is called "Chunck Level of Detail" or CLOD, which tesselates vertices based on distance from camera, ie. the actual terrain data that you keep in memory to draw are dynamic like a particle system.
There is also a technique called geo-mipmapping, which makes the texture tiles that are distant from the camera less detailed.
I have looked around a little and I got those two techniques for terrain LOD:
- Continuous LOD Terrain Meshing Using Adaptive Quadtrees
- Real-Time Dynamic Level of Detail Terrain Rendering with ROAM
The Terrain Geomorphing in the Vertex Shader article in gamedev also has useful information.
Well, I hope I helped :)
Sure, terrain LOD makes a lot of sense. But 65,000 polys shouldn't give you any problems even when rendered with brute force. Crysis has an average of 1.2 million polys visible at any time and it runs okay-ish...
Quote:Each polygon is being rendered with the draw index primitive method.
You should really clarify what you mean by this. Are you making 65,000 draw calls (very bad) or are you rendering all the polygons at once with a single draw call(using vertex index buffers). The second approach should be very fast.
I don't really know anything about 3D hardware but 65000 is suspiciously close to 2^16. Any chance that switching from a 16 to a 32-bit index buffer could be a performance issue?
Quote:Original post by BlipsYou're not really meaning that you render each poly separately don't you?
Each polygon is being rendered with the draw index primitive method.
Quote:Original post by Harry HuntI agree 100%. In this case the notion of "very old card" referres to pre-GeForce4 cards or maybe even pre-GeForce.
Are you drawing all 65,000 polys with one draw call? Because if you are, then it shouldn't give you any performance problems unless you have a really old 3D card.
This obviously assumes the vertex stage is actually bottlenecking, which might not be the case given the few information.
Please leave away ROAM and in general, avoid whatever it's CLOD. Those algorithms were designed with a kind of hardware which doesn't exist anymore since a long time - streaming vertex data to GPU buffers nowadays, although not so bad for small streams is generally way more expensive than throwing an extra 3000 triangles.
EDIT: uhm, beaten on time on exactly the same points.
I suppose what he really means is 64*1024.
Well, I suggested those techniques because Blips stated that he is working on a directx engine, I doubt that he wants his engine to be limited to drawing only one scene-setting involving a terrain.
Drawing a one million polygon terrain without any LOD is... well, my information are maybe outdated when it comes to terrain rendering but I can't imagine how it's a better idea.
Drawing a one million polygon terrain without any LOD is... well, my information are maybe outdated when it comes to terrain rendering but I can't imagine how it's a better idea.
Author
Thanks for all the responses. I believe the terrain is being rendered in a loop, that draws each primitive individually with the draw indexed primitive method. I'm pretty new to directX, so I'm not to aware of any alternatives.
Quote:Original post by BlipsYEah, that'll be extremely slow. You should never have more than 500 - 1000 DrawPrimitive calls per frame, any more than that and your spending most of your time doing nothing but submitting batches to the driver.
Thanks for all the responses. I believe the terrain is being rendered in a loop, that draws each primitive individually with the draw indexed primitive method. I'm pretty new to directX, so I'm not to aware of any alternatives.
The best way to do it would be to create a dynamic vertex buffer, lock it at the start of your terrain rendering, and then add in triangles as you "render". Then unlock the vertex buffer and render all triangles in one go. That should be substantially faster.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement