Jump to content
  • Advertisement
Sign in to follow this  
mede

OpenGL Performance in the Pipeline

This topic is 4875 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

what is the best order for the objects sended to OpenGL pipeline ?? - Per Distance ?? The Card has to paint less points because many points are excluded by the z buffer algorithm - Per Material ?? The OpenGL setting for material must not be changed often because all objects with the same material are rendered together - Is there a other order ??? - Take this even a roll ?? [Edited by - mede on June 15, 2005 2:43:07 AM]

Share this post


Link to post
Share on other sites
Advertisement
Here's the known recepy for optimal rendering performance:
Unless you're applying some alpha blending to your scene's elements, render your shapes from front to back; by doing so you're taking advantage of the hardware accelerated z-test.

Sort your shapes per-textures; switching from one image to the other involves some pretty heavy internal operations and should be kept to a minimum.

The OpenGL setting for material must not be changed often because all objects
with the same material are rendered together


Where did you hear that part?

Share this post


Link to post
Share on other sites
The OpenGL setting for material must not be changed often because all objects
with the same material are rendered together


em this is a misunderstanding... i mean should i sort the objects for material before rendering? this has the advantage that i must change the material settings of the pipline only after each group of objects for same material


but i think to sort the objects for deapth is much important than for material ???
think changing material states of pipeline isent a performance expensive thing ???

Share this post


Link to post
Share on other sites
If the order doesn't affect the appearance, generally speaking the rule of thumb seems to be to minimise the number of glBegin() glEnd() calls.

Because you can't change many material parameters between glBegin() and glEnd(), that would seem to favour sorting by material.

But as with any optimisation whatsoever, don't do it just "for the hell of it", only do it if you know it will definitely benefit you - you will have to benchmark YOUR application with and without this optimisation.

Sorting by material is going to take a finite amount of time; if this time is greater than the time saved by not doing begin/end, then it's pointless.

However this will depend on your sorting algorithm, how many objects you have, how complex your objects are, your video hardware, your CPU hardware, your video driver and the phase of the moon (at the very least).

Therefore, if it provides a really good benefit on some configurations (/ PoM) but not others, it might be worthwhile benchmarking it at runtime (i.e. when the game starts up).

Mark

Share this post


Link to post
Share on other sites
Quote:
- Per Distance ??
The Card has to paint less points because many points are excluded by the z buffer algorithm

check my website below stuck a couple of newshots showing overdraw in that scene drawing from front to back gives an extra ~1% (practically nothing), sorting by material though is worth a lot more

Share this post


Link to post
Share on other sites
ah this is a statement i can use ;)

sorting by material though is worth a lot more

Share this post


Link to post
Share on other sites
Pipeline optimizitations are amongst the hardest nuts to crack.

I don't have much new to say from what already been said here in essence you will have to test what actually works for you and your application, there is no other way to know.

A few general pointers tho, *roughly* drawing from front to back order will indeed as you say help rendering times due to early z buffer rejections, but in reality only if it occluded something that would have been expensive to draw. Your front to back order does not really have to be exact either, if you can save alot of time in sorting by having it roughly, that usually works for the best. Not all objects does have to be sorted either, small and cheap objects that are unlikely do occlude anything would perhaps normaly just be a waste of time sorting them, what you really wanna render first is large objects very close to the camera, occluding as much as possible.

However what often can make huge leaps in terms of performance is a better use of hardware resources. Most state changes in OpenGL are extremly expensive, and the often most missused state change would be the texture units. Changing a texture is often very expensive! Thus if you use alot of texture make sure you are are not changing textures ant more than you absolutely have to. Sort your objects by texture usage (this might sound as it goes against sorting by front/back order, but try both, and then try a hybrid approach!). Try merging textures, if you have 4 64x64 textures perhaps they can be put into one 128x128 texture, essentially freeing up 3 texture units (due to filtering it may not always be possible, but for a terrain engine I know someone who got magnitudes of increased performance from texture merging and texture sorting)

Share this post


Link to post
Share on other sites
There is some stuff in the Forum FAQ about optimisation, specifical the links to this year and last years GDC stuff (videos and pdf files, ignore the fact they are on ATIs site, they were done with nVidia as well).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!