Hey everyone,
I have a question about scene-graphs when it comes to rendering the scene. You usually have to sort the objects that you want to draw for various reasons. (blending, using different shaders, …)
My question is, how do you combine this with the scene-graph? I read multiple articles about this and I often read that the scene-graph shouldn’t care about rendering routines at all.
But how do I get the subset of my scene that I need, for example all transparent/semi-transparent objects. Do I keep track of them or do I query my graph for those objects on every frame?
My scene-graph right now is just a simple hierachy. A root with multiple childs that again have multiple childs and so on.
I actually found much information on scene-graphs but I didn’t find that much about how to actually extract certain objects out of it efficiently.
From your scene graph, you query a list of potentially visible objects that you then proceed to render. You sort the list of rendered objects by certain critera (e.g. shaders, textures, …)
to try minime switching of those objects. You will probably also want to sort transparent objects by depth.
There are different aproaches to that, also involving the graph itself. One could try to pre-arange the objects in the graph in a way that minimizes the sorting costs of the list.
On the other hand, you might want to arange the graph in a way that minimizes cache-misses. You could even pregenerate a static list of visible objects for each area in the
scene, reducing computation time to a minimum by compromising memory consumption (and also not having dynamic scenes).
The topic of scene-graphs and visibillity culling is huge. There are many different ideas and concepts with different pros and cons. There’s no ideal solution that includes everything at no cost.
A scene graph is just a bounding volume hierarchy used for accelerated access to the spatial data. You can instead use a spatial partitioning scheme to represent your scene if you want, though this performs less well if your objects are dynamic. The main thing is that you need one or the other – i.e. some form of spatial acceleration data structure – to access your scene data so you don’t have a for i=1…num_objects_in_world required to access them.
As far as rendering from either, the typical scheme used to determine what’s in the view frustum is to have some visitor object that culls a view frustum against this scene graph using frustum-to-bounding-primitive tests. Based on these tests it serializes one or more lists of things to draw. In the process of serializing these lists it can do some simple binning and some full sorting when require – e.g. for translucents. These lists are then the input to the draw processing. This kind of technique has been used in scene graphs for quite a long time – for examples you can pick up any open source scene graph such as OpenSceneGraph and take a look.