Jump to content
  • Advertisement
Sign in to follow this  
Red Ghost

OpenGL Scenegraph rendering

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

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.

Share this post


Link to post
Share on other sites
Advertisement
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 ;) )

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
@ 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm
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.


Not strictly true; if you have heavy pixel shader load then sorting in a rough front to back order allows you to take advantage of early z-rejection to avoid running pixel shaders.

Also, you need to sort back-to-front for transparent objects to be rendered correctly.

Share this post


Link to post
Share on other sites
a good method
just lay down a z only pass first of all objects (cheap u can sort from near to far but from my experience it buys you very little)
then loop through the materials (not gl gl materials but a collect of shader texture etc)
draw all meshes that use this material (near or far to the camera make zero difference)

*even better lay down depth with occlusion testing, then gather the results to be used in the material shading phase

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!