Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A standard technique is to insulate the objects' effect on the render state from each other by doing all changes from some default OpenGL state within a glPushAttrib/glPopAttrib scope. In C++ define a class with constructor containing</p> <pre><code> glPushAttrib(GL_ALL_ATTRIB_BITS); glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS); </code></pre> <p>and destructor containing</p> <pre><code> glPopClientAttrib(); glPopAttrib(); </code></pre> <p>and use the class RAII-style to wrap any code which messes with the OpenGL state. Provided you follow the pattern, each object's render method gets a "clean slate" and doesn't need to worry about prodding every possibly modified bit of openGL state to be what it needs.</p> <p>As an optimisation, typically you'd set the OpenGL state once at app startup into some state which is as close as possible to what everything wants; this minimisies the number of calls which need to be made within the pushed scopes.</p> <p>The bad news is these aren't cheap calls. I've never really investigated how many per second you can get away with; certainly enough to be useful in complex scenes. The main thing is to try and make the most of states once you've set them. If you've got an army of orcs to render, with different shaders, textures etc for armour and skin, don't iterate over all the orcs rendering armour/skin/armour/skin/...; make sure you set up the state for the armour once and render all the orcs' armour, then setup to render all the skin. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload