Sign in to follow this  

optimize rendering

This topic is 3341 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 3341 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this