Advertisement Jump to content


This topic is now archived and is closed to further replies.


Optimising, Z sorting and other problems

This topic is 5894 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 to you all Recently i have been thinking of ways to optimise and refine my rendering system, currently its just brute force....... It goes like this: 1) The terrain is rendered (one large 128*128 vertex array) 2) The map is rendered (a linked list of polygons objects, to allow fast dynamic geometric modifications) 3) The entities are rendered..... Those are frustum culled, the models use backface culling, triangle strips and fans, so thats not too slow Of course, you can guess that the slowest part is the terrain and map rendering... But there is also another problem.... It seems that with the new nvidia drivers, you can''t get to use a 32 bits z buffer, even if you request it in the pixelformat and run in 32 bits colors (yes my near and far clipping planes are set properly)..... So there is a bit of Z fighting, and transparent surfaces are not properly drawn (entities appear to be in front of them). So i''ve been thinking about creating an octree system, split my map polygons and put every part of them in individual nodes. This seems like a possible solution, but what about the terrain polygons...... It gets quite complicated to put the terrain in an octree..... It would kill the use of vertex buffers... As for the transparent surfaces, the only way to get away with those seems to be Z sorting, but how the hell can you perform that quickly...... You have to sort all the polygons in the frustum, most likely in a linked list, perform distance checks against the viewer for everyone of them..... Again, that kills the purpose of vertex buffers, because you have to perform z sorting each frame. Another problem...... What about smooth shading... If i want per vertex normals, i can only calculate them once every polygons are in their octree node? and how do i do that, i would have to check each vertex of each polygon, see what other vertex is sharing them in other polygons....... average normals !? Does anyone think its even viable to put the whole terrain as separate polygons in every octree node and then compile a whole triangle strip for every octree node with the normals for smooth shading. And if so, that raises ANOTHER problem, because its not easy to get data about each polygon of a triangle strip in order to perform collision detection for example... Every solution seems to be creating new problems and not really solve anything.

Share this post

Link to post
Share on other sites
Just over the last 2 days i wrote a terrain engine, and i had those same sorts of questions, so i can probably help.

Dont used linked-lists especially brute forced. Too slow.
I used a quad-tree (no point with octree, as it is really only a 2d plane). Each node of the tree had a glList bound to it.

From 15 fps in brute force, using frustum culling on the quad-tree with the lists this jumped to 60 fps. (60 being my monitors refresh rate). And that is with a 512x512 heightmap too.

My Quad-tree code what the Oct-tree from GameTutorials re-written, and the glList info was out of the OpenGL Red Book

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!