Reliably resetting states

OpenGL Development JOGL Development
#1

I’m wondering how to reliably reset all state information in OpenGL. Say I have a rendering loop with several passes, each of which contains several texture states, all having differing arguments set, glTexEnv, glTexCoordPointer, you name it. Of course, not all state info is set in the main loop, material objects for example set all states they require to be rendered correctly themselves.

Problem is, when the material changes, the new material involuntarily “inherits” states the old material left. I’ve already put in - with tears in my eyes, because it’s so expensive - pushAttrib and popAttrib to overcome the problem, and it worked, after a fashion. But now I’m stuck for the tenth time with a non-working shadow mapping stage which behaved just fine an hour ago, because somewhere, somehow, a state isn’t reset, and I’m sick of it >:(

So, question: Is there some general purpose “reset everything” call which allows clearing all states, especially those for arb multitexturing, in a single command? PushAttrib and popAttrib dont seem to catch all of it. I know this could be costy, but tracking each single state and making sure all state changes are optimal is an optimization I save for long dark winter nights.

Thanks

Wolfgang

#2

Back to our old topic can’t you just backtrack along your STATE partitioning tree?

SNR

#3

In theory, yes, but the tree doesnt branch at each state. In practice rendering goes like this:

Set states valid for all stages and passes
Traverse passes necessary
Set states valid for pass (e.g. enable lighting or blending)
Traverse visuals using pass (as provided by visibility culling)
Track material changes, set material states on change (e.g. texture, combine)
Set states for current visual (e.g. array pointers)
Render visual

Throw in multipass per light for projective light and shadowing and you get a nightmare of state changes. I guess I could throw in debug code tracking all the changes and observe if something is not reset correctly, but the amount of code necessary makes me blanch :slight_smile:

Cheers

Wolfgang

#4

Remove all you push/popAttrib calls and just have each object set all state that it is responsible for whether default or not. That seems to be the most efficient way of doing it from what I’ve seen of all the different scene graph internals. Anything that is the same as before generally doesn’t cost anything to “change state” with most modern graphics cards.

#5

I like that idea, thanks a lot. I never thought the drivers would catch obviously redundant state changes. Okay, so one standard block of states it is …

Thanks again

Wolfgang

#6

State changes are so common in opengl, you’d think there would be a way to load a set of states like you can load a matrix or load a pile of vertex information. Is it possible to set say 5 or 6 states with a single call? Should it be possible to? I’ve never performance tested things to that degree so I have no idea if state changes take much time at all (I assume in java that JNI overhead adds up quite a bit though).

#7

You can compile a display list where you set all your states. That way you can set all the states in one call, and maybe the driver optimizes it somehow.

#8

Yeah, the display list method would at least clear the overhead of JNI… I’m glad you thought of it, now I can go kick myself for not thinking of it too. :stuck_out_tongue:

#9

Sorry to disturb you while kicking :slight_smile: Are you sure that each and every state change, i.e. texparami, texenv, enableclientstate usw. is captured in a display list? I’ve read some warnings that many states wont be cached in a display list. I mean, if it works, great, I’ll embrace it of course, but I’ve got my doubts (and no time right now to try it, switching the whole engine to glsl :slight_smile: finally)

Cheers

Wolfgang

#10

Lists typically can only affect server-side state, not client side state like bound vertex array stuff.

glPushAttrib/popAttrib is the closest you’ll get if you want to save the current state. Realistically the overhead isn’t much assuming you work from some known base state (and remember to put things back after you’ve used them). Equally, all the expensive state changes (shader, texture) you’ll want to be doing sorting on anyway.

#11

Also depends on what you classify as “state changes”. The texture parameter stuff is considered a state change if you don’t use texture objects, but as soon as you use them, they are bound to the object, and no longer considered a state change. It’s sort of an inherent display list. OpenGL is, in general, moving this way anyway now with the general object list capabilities (Vertex Buffer Objects, Shader Objects etc). Super Buffers, from what I understand of them, are yet another step in that direction.

I would highly recommend that you get a copy of the Red Book, as it talks a lot about what state changes are client vs server-side and thus what can be in a display list and what can not.