Jump to content
  • Advertisement
Sign in to follow this  
SiS-Shadowman

OpenGL Rendering Qeue

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

every day i'm getting deeper into 3d programming and i start wondering if it is nessecary to render all the objects / particles / etc.. in a certain order? i know that i need to render first all non transparent objects and after that all transparent in back to front order. but apart from that, is there anything else i need to take into account when i want a good performance in my game? currently i'm rendering everything in a logical order ( where it's possible ). my engine gets bigger and i don't want to screw everything up by making basic mistakes and realizing that i have to rewrite half of the code. do you know if it's nessecary? if so, what reason does it have? *edit* i'm using direct x ( perhaps that makes a difference to opengl )

Share this post


Link to post
Share on other sites
Advertisement
Having a batch renderer that sorts by shader, params, texture, depth, etc is a needed construct in any rendering engine if you want performance. It is usually written to be configurable as to how you want to sort, etc.

Share this post


Link to post
Share on other sites
To add on to what Saruman said, what you want to do is minimize the changing of states. Everytime you switch a shader or a texture or whatever you're going to incur a penalty. So, more specifically, you don't just want to sort by states, but you probably also want a system to prevent redundant state changing (setting a shader that is already active). The easiest way to do that, for me at least, was to organize the render states into groups with an ID. At which point sorting by id is trivial. Also, depth sorting (from front to back) is important so that you can get early rejection of occluded pixels. If your project is small, you may not notice too much of a difference, but the larger your project gets, the more important such optimizations become.

Share this post


Link to post
Share on other sites
Typically one would sort by any shader effects (as these are the most exespenive changes). So if 2 meshes (or mesh subsets) use the same shaders then your typically going to want to bind the shader and render both. After sorting by effect, you can sort by other material properties. :-) Hope this helps.

Share this post


Link to post
Share on other sites
You can reduce fillrate requirements considerably by rendering your opaque objects front-to-back, due to the fact that background pixels get rejected by the z-buffer more often. After this, if you have partially transparent (alpha-blended) objects, render them from back to front.

Fillrate is the most important bottleneck of your graphics hardware in pixel shader-heavy games, and almost all new 3d games are just that.

You can combat software-side bottlenecks by drawing as much as possible with as few calls as possible.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nik02
You can reduce fillrate requirements considerably by rendering your opaque objects front-to-back, due to the fact that background pixels get rejected by the z-buffer more often. After this, if you have partially transparent (alpha-blended) objects, render them from back to front.

Fillrate is the most important bottleneck of your graphics hardware in pixel shader-heavy games, and almost all new 3d games are just that.

You can combat software-side bottlenecks by drawing as much as possible with as few calls as possible.


it is often more efficient to just do a z-only pass than sorting the opaque objects in a front to back order (especially since such a sorting can conflict with the sorting for few shader changes)

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!