SceneGraph + Renderstates

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SceneGraph + Renderstates

      Hey Mike: you mentioned in chapter 14 about how quirky the renderstates can be since you need to restore them each time you modify them. you also claim that this may cause TOO many calls to SetRenderState...

      The first point I agree, any time I leave a responsibility up to the programmer (not the framework) I find it a bad practice.

      What would setting the renderstate too many times do?

      What if you had a RenderStateStack and you could push and pop just like you do with matrices? Wouldn't this work better?
    • Every time you set a renderstate, you are causing traffic on the bus between the motherboard and the graphics card. This is a relatively slow process compared to the normal operations of the graphics card.

      That's why shader programming is such a hot thing, these days because the programmer's intentions are all on the graphics card instead of the CPU, and the shader code runs directly on the graphics hardware instead of depending on electron traffic between the CPU and the graphics card.
    • RE: SceneGraph + Renderstates

      As far as restoring render states and what not, I think you're better off sorting your scenegraph so that it renders everything that requires a specific state, then everything that requires the next state and so on. That way you minimize render state changes.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • So, i could decorate certain scene node classes with attributes denoting their renderstate requirements (I'm using .net remember) ... then I could sort based on those.

      The only thing I don't like about that is I don't want to use reflection during my render loop... blech!
    • Or, to prevent sorting, you could make more than one scenegraph and render them in succession. Then all you have to do is make your state changes before you call each state->Render(). When you create an object you drop it into the appropriate graph and there's no actual CPU time spent sorting, which I'd imagine would be more than the extra few cycles for the extra function calls.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."