optimize rendering
Author
Hello,
While making a game I am -of course- continuously increasing the amount of meshes. right now, i am rendering all of them, thereby severly slowing down the process. Is there a way to optimize this by only rendering meshes that are visible?
thanks for any hints!
You could use the Viewport's (in the GraphicsDevice) Project method to find out where that point in the world is, based on your camera's view and projection matrices. I can't completely remember off the top of my head but i think if the resultant Vector3's z value is between zero and one then that means it's on the screen. The only problem is that you are only using one point to judge the visibility of an entire mesh. For instance let's say you used a mesh's center point that is off-screen but a side of the mesh should still be visible on-screen. So you may want to do something like use 8 boundary points of the tightest rectangular prism you can make out of the mesh. This only helps in dealing with meshes that are to the side or behind the camera. It won't do anything about meshes that appear behind other meshes. I believe the only way to figure that out is by using an occlusion query, where the mesh is to kind of like rendering it anyway so you might as well just render them.
What you're looking for is called 'frustum culling'.
Here's a link to a tutorial, with source code:
http://www.flipcode.com/archives/Frustum_Culling.shtml
Good luck!
/Simon
Here's a link to a tutorial, with source code:
http://www.flipcode.com/archives/Frustum_Culling.shtml
Good luck!
/Simon
first of all make frustum cull to eleminate the meshes which doesnt seen by your camera. here is a good tutorial for frustum cull.
http://www.lighthouse3d.com/opengl/viewfrustum/
after frustum call u have two options.
first way : u can make occlusion query for occlusion culling to eleminate the meshes which doesnt seen becouse of other meshes in front of them. here is a good tutorial for occlusion cull.
http://www.gamedev.net/reference/programming/features/occlusionculling/
second way : to do a good occlusion cull u need very well designed LOD meshes. it s hard to do for small games. u can render your meshes from front to back in an order instead of occlusion culling. if u do that the pixels which doesnt seen will not be calculated. becouse smaller depth valued pixels have been calculated before.
one last thing dont forget back face culling for the meshes which arent two sided.
good luck on your game.
http://www.lighthouse3d.com/opengl/viewfrustum/
after frustum call u have two options.
first way : u can make occlusion query for occlusion culling to eleminate the meshes which doesnt seen becouse of other meshes in front of them. here is a good tutorial for occlusion cull.
http://www.gamedev.net/reference/programming/features/occlusionculling/
second way : to do a good occlusion cull u need very well designed LOD meshes. it s hard to do for small games. u can render your meshes from front to back in an order instead of occlusion culling. if u do that the pixels which doesnt seen will not be calculated. becouse smaller depth valued pixels have been calculated before.
one last thing dont forget back face culling for the meshes which arent two sided.
good luck on your game.
More extensive optimizations will depend on exactly what is in your scene.
If you have terrain, it is best to store the terrain in chunks and draw only the chunks that are within view.
Furthermore, using a BSP (binary space partition) you can eliminate many objects all at once. This is a very simple technique which involves dividing space in half recursively to some fixed depth.
When you wish to render an object at a location, you use its basic bounding box to determine the largest half-space that fully contains the object.
During rendering, you walk down the halves of the BSP and do frustum culling on the halves themselves. If a half fails, none of the objects fully contained inside the half will be visible either, so you do not have to test them at all. You also do not need to go into its children to test them either.
This speeds up rendering by a large factor.
Another popular optimization is sorting the objects so that there are as few state changes during rendering as possible. You don’t want to enable fog if it has already been enabled, for example.
LoD (Level-of-Detail) may help as well, and DirectX mesh objects can help you with this without the need of defining the lower-detailed meshes manually.
And, mixing this with terrain, once you have your terrain divided into chunks, you can start to use lower-resolution chunks at farther distances. As they fade away into the distance, they reduce their polygons smoothly, hopefully not creating too many artifacts in the process. If you have ever played a game where the terrain seems to morph over distances (parts suddenly rising up as you get closer, for example), you have seen this method in action, and now you know why that happens.
L. Spiro
If you have terrain, it is best to store the terrain in chunks and draw only the chunks that are within view.
Furthermore, using a BSP (binary space partition) you can eliminate many objects all at once. This is a very simple technique which involves dividing space in half recursively to some fixed depth.
When you wish to render an object at a location, you use its basic bounding box to determine the largest half-space that fully contains the object.
During rendering, you walk down the halves of the BSP and do frustum culling on the halves themselves. If a half fails, none of the objects fully contained inside the half will be visible either, so you do not have to test them at all. You also do not need to go into its children to test them either.
This speeds up rendering by a large factor.
Another popular optimization is sorting the objects so that there are as few state changes during rendering as possible. You don’t want to enable fog if it has already been enabled, for example.
LoD (Level-of-Detail) may help as well, and DirectX mesh objects can help you with this without the need of defining the lower-detailed meshes manually.
And, mixing this with terrain, once you have your terrain divided into chunks, you can start to use lower-resolution chunks at farther distances. As they fade away into the distance, they reduce their polygons smoothly, hopefully not creating too many artifacts in the process. If you have ever played a game where the terrain seems to morph over distances (parts suddenly rising up as you get closer, for example), you have seen this method in action, and now you know why that happens.
L. Spiro
Author
Thanks for all the replies!
I got the frustum working. Since it is a spacegame with not many objects (only planets and ship, I have no BSP yet, perhaps when making dustclouds, I will look into that.
also, when I am some further, I can look at LOD. now object are visible for a long long time ;)
I got the frustum working. Since it is a spacegame with not many objects (only planets and ship, I have no BSP yet, perhaps when making dustclouds, I will look into that.
also, when I am some further, I can look at LOD. now object are visible for a long long time ;)
If I were you, I would use an octree or quadtree. They are similar to BSP except they divide the world 8 times (for an octree) and 4 times for a quad tree at each branch. They are also very easy to implement compared to a BSP tree and will fit nicely with your frustrum culling. Octrees can use a lot more memory though so if your scene is spread mostly in just 2 directions then its probably better to stick with a quadtree.
Here is a link to a tutorial on quadtrees.
Hope that helps.
Here is a link to a tutorial on quadtrees.
Hope that helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
