Hi, I would like to know what are the different approaches for correctly rendering a scenegraph without too much state changes in OpenGL. I implemented a simple engine where the scenegraph only caters for scene organisation (object position and transformation). When drawing the scene, my renderer culls the scenegraph for visible leaf nodes then sorts the visible nodes by main drawing state changes (essentially Lighting, Blending states and texture switching). Thus when rendering my visible nodes, main state changes are reduced to a minimum. Note that scene node rendering data is stored within the leaf node (color, material, texture, state changes through calling my renderer state stack methods). This is sufficient for correctly rendering simple scenes. Still I am left wondering for more difficult scenes (especially reflected objects) where my approach shows its limits. Any ideas ? Ghostly yours, Red.

How about creating another scenegraph?
Use your existing scenegraph to determine visibilty, do physics, AI stuff etc, and create a new state-storted(maybe even depth sorted) scenegraph where you only use nodes in your scenegraph that you flagged as 'visible'.
This is what I intend to do with the scenegraph I'm working on.

Hope this makes sense.(Since it does in my head, but it's rather hard to convert to plain English ;) )

Quote:Original post by Red Ghost
I would like to know what are the different approaches for correctly rendering a scenegraph without too much state changes in OpenGL.

As you say, state sorting is the way to go. GPUs are getting too fast to bother with front-to-back or such.

Quote:Original post by Red Ghost
I implemented a simple engine where the scenegraph only caters for scene organisation (object position and transformation). When drawing the scene, my renderer culls the scenegraph for visible leaf nodes then sorts the visible nodes by main drawing state changes (essentially Lighting, Blending states and texture switching). Thus when rendering my visible nodes, main state changes are reduced to a minimum. Note that scene node rendering data is stored within the leaf node (color, material, texture, state changes through calling my renderer state stack methods).

I do something very similar but with a very gross-grained sorting. Also, nodes are preprocessed so at runtime multiple nodes are collapsed in optimal batches.
I still didn't get to a "benchmark-valid" version, but initial tests were encouraging.

Quote:Original post by Red Ghost
This is sufficient for correctly rendering simple scenes. Still I am left wondering for more difficult scenes (especially reflected objects) where my approach shows its limits.

I suppose the issue comes with re-sorting everything. A grosser-grained sort will help you quite a bit while batch collapsing will get you more power from your xform pipes.

@ Fase
That is an idea but in my own experience, I think that two scenegraphs are difficult to maintain as they impose twice as much management for correct node insertion and removal (not to mention serialization).

@ krohm
I am already using a gross grained sorting system for registered scenegraph nodes for display.
Regarding reflection, a scene must be drawn twice (once normal and once as a mirror reflection.
This means two possibilities:
1- to have a special mirror node holding the mirror mesh with a binary switch: 1st pass rendering the mirror node to render all child node reflections and 2nd pass to render child nodes normally(thus two pass rendering of the scenegraph).
2- or create a simple mirror node and register all nodes which may be reflecter as children of that mirror node (one pass rendering of the scenegraph).
I will try out the second possibility.

Thanks all.

Red.

Since I wanted to add mirror nodes, I continued thinking about the two solutions. Then I understood that both of them should be discarded.
In fact I was beginning to think of the scengraph as a mean to avoid state change and not as an organizing tree of objects. I then understood I was beginning to hack my scenegraph to do something unrelated to its purpose.

In fact mirror rendering has nothing to do with the scenegraph. Mirror rendering only concerns the display list deducted from the scenegraph after culling. Thus my final solution is to create a mirror node and to let the renderer use that node for drawing as many times as needed the display list.

Red.

Yes, maybe I've stretched it a bit too much! ;)
Absolutely true.