Eurographics Italian Chapter Conference (2007)

Raffaele De Amicis and Giuseppe Conti (Editors)

Challenges for modern Scene-Graph Systems

Wolfgang Müller-Wittig† 1

Gerrit Vo߇ 1

1 Centre
for Advanced Media Technology
Nanyang Technological University
Singapore

Abstract

Current scenegraph systems, especially systems used to build general purpose virtual reality systems, are trailing
game engines and similar specialized systems in terms of the adaption of new rendering methods like the different
real-time shadow algorithms. This paper analysis the fundamental OpenGL state abstraction layers present in
current scenegraph systems with respect to their influence on the adaption of new and complex rendering algo-
rithms.
Categories and Subject Descriptors (according to ACM CCS): I.3.6 [Computing Methodologies]: Computer Graph-
ics Methodology and Techniques I.3.7 [Computing Methodologies]: Computer Graphics Three-Dimensional
Graphics and Realism

1. Introduction build to serve a wide variety of application environments,

and hence need to support a wide variety of models and ef-
Driven by the recent advances in computer graphics hard-
fects. As a consequence game engines can optimize their un-
ware, previous too complex and time consuming algorithms,
derlying graphics structure implementation according to the
like enhanced shadow maps [MT04] or parallax bump map-
requirements given by the models and effects used. Scene
ping [Wel04], became available for the use in real time
graphs, which provide the foundations for common virtual
graphics environments. But upon closer inspection it be-
reality systems, in contrast have to provide more general ab-
comes clear that many of these techniques are generally de-
stractions and have to balance the requirements given by the
ployed in game engines and similar, highly specialized en-
wide variety of application requirements.
vironments. In comparison their occurrence as part of gen-
eral purpose virtual reality systems is more sketchy. These
algorithms are available but usually they are integrated as An integral part of any scene graph system is to pro-
vide an abstraction for the underlying graphics hardware,
add ons, build to suit a narrow application environment and
only of use with datasets specifically designed to cope with especially to hide the complexity needed to optimally
the given limitations, like number of textures and which of feed the deep pipelines of modern graphics hardware.
This is achieved by utilizing a low-level API, in general
the available texture units to use. The core difference, which
leads to the observed discrepancy in usage, is the difference OpenGL [SAFL99] [SALB04] is used for general purpose
in knowledge about the scenes to be rendered. Game engines cross platform systems. On top of this API several layers
are build. Shortcomings in these layers as well as overall
are build against a predefined set of models and effects, gen-
eral purpose virtual reality systems on the other hand are missing layers are responsible for the observed lack of
general support described above. Of particular interest are
the layers abstracting the appearance attributes because here
the major substantial progress has be made, whereas as the
† e-mail: [email protected] OpenGL primitive interface stayed nearly constant.
‡ e-mail: [email protected]


c The Eurographics Association 2007.
46 Wolfgang Müller-Wittig & Gerrit Voß / Challenges for modern Scene-Graph Systems

In general the part of a scene graph system which change can be applied. After wards it has to fill up again be-
is responsible of preparing the scene for processing by fore the nominal performance can be reached. If these state
the graphics card is called rendering backend. It has the changes happen too often it might not be possible to fill up
responsibility to convert the scenes as given by the user the pipeline completely, and in the worst case waste all the
into the final image. The rendering backend does so by benefits of the pipelined architecture.
traversing the scene graph, collecting the visible geometries
and passing them on to the underlying hardware. During But not all problems with state changes can be attributed
this process it is the responsibility of the backend to find an to the simplicity of the hardware. Some are caused by limited
order of the geometries which allows the best utilization of resources that have to be managed, like texture memory and
the given hardware. texture caches. Texture are usually stored in special, high
performance memory, the texture memory, on the graphics
board itself. Furthermore the active areas of the textures are
In the following we will describe the abstraction layers stored inside a special cache, the texture cache, as close as
found in current OpenGL based scene graph systems. possible to the processing unit. Like any other multi-level
cache system changing its contents to often will decrease
the overall performance. Thus the second task of the scene
2. Challenges for current Systems graph system is to take care of managing the state. Specif-
Graphics hardware as abstracted by OpenGL and thus seen ically to minimize the number of state changes in order to
by scene graph systems can be viewed as a state machine avoid pipeline stalls and cache pollution.
by which the primitives are processed and transformed to Scene graphs therefore include state sorting facilities as
form the pixels of the final image. The state variables which part of their draw operation. Current systems like Open-
describe how the primitives are drawn include light and SceneGraph, OpenSG or OpenGL Performer [RH94] iden-
material parameters, textures and blending, and customized tify a State by a unique identifier and use a bucket sorting
shaders. strategy to group primitives by their associated state. This
way primitives sharing the same state are drawn directly af-
ter each other without the need of a state change. The con-
2.1. OpenGL Abstraction
cept of using a unique state identifier for the sorting pro-
This layer has two main tasks. The first, which is visible to cedure was based on the observation that each StateChunk
the programmer, is to provide access to the state variables. occurred exactly once inside the State and thus the prim-
Modern scene graph systems like OpenSG [RVB02] or itives where likely to share the complete State instead of
OpenSceneGraph [OB05] group similar variables together single StateChunk and thus sorting by chunks would be an
to form logical clusters, for example all texture, material nearly never used overhead. Unfortunately this assumption
or light information are grouped together. These are called broke down with the appearance of multi textures and shader
StateAttribute (OpenSceneGraph) or StateChunk (OpenSG), programs from OpenGL version 1.3 on. Now it was com-
where a set of them is called State and fully describes how mon to share one or more textures between States or use the
the associated primitives will be drawn. The benefit of same shader program and only vary the shader parameters
grouping them in a logical way is that the programmer has between different primitives as the multi texture example in
a better understanding which variables belong together and figure 1 illustrates.
must be manipulated in a synchronized way.
The OpenGL state of each of the tunnel segment building
blocks (ceiling, floor, left and right wall) contains a color tex-
The second task relates to the way modern graphics hard- ture and a light texture (see figure 2). Blended together they
ware is build. The OpenGL graphics pipeline is not only put allow the simulation of the complex lighting environment.
into hardware but in order to achieve real-time performance In order to create a complete tunnel n segments are joint to-
for complex models it has to be pipelined, so that different gether. Due to the varying light textures each of the n floor
parts of the rendering pipeline work independently of each elements, for example, is seen by the existing state sorters as
other, like independent vertex and fragment stages. Further- having a unique, independent state even if all floor elements
more each of the stages them self contains multiple units share the same color texture and other state settings. This in-
working in parallel, like the 24 fragment units of a NVidia ability to utilize information about shared StateChunks dur-
Geforce 7800 GTX. To be able to build these parallel units ing the sorting process may result in the following worst case
and the pipelines in hardware they have to be rather simple. rendering order. First each element of segment i (floor, ceil-
As a number of different pieces of geometry may be in op- ing and walls) is drawn followed by each element segment
eration at any given time, changing the state, and thus the i + 1. This segment by segment processing continues until
way the units operate, has to be synchronized with the data segment n. Thus activating each of the color textures n times.
flow through the pipeline. As simple hardware cannot do that In comparison a StateChunk aware sorter will be able to first
the pipeline has to be, at least partially, empty before a state draw all floor elements followed by all ceiling, all left and


c The Eurographics Association 2007.
 Wolfgang Müller-Wittig & Gerrit Voß / Challenges for modern Scene-Graph Systems 47
all right wall elements, activating each color texture exactly or depth texture have to be stored in order to reuse them in
one time. later stages.
Again the simple bucket sorting approach of the render-
ing backend can neither handle the ordering constraints of
the traversals nor provide storage for the temporary results.
A simple example for multi stage algorithms are shadow
maps [SKW∗ 92], figure 5. This algorithm creates real-time
shadows by first rendering the scene as seen from the light
position (Stage 1, figure 3). The resulting depth buffer is
stored in a texture and reused later. The next stage (Stage
2, figure 4) renders the scene as seen by the camera but
only the ambient color terms are active in order to generate
the shadow colors. The last stage (Stage 3, figure 5) draws
Figure 1: Multi texture environment. the scene from camera perspective with diffuse and specular
lighting enabled. The result from Stage 1 is used to decide
whether a pixel is lit or inside the shadow.

Figure 2: Color and light textures.

The state based approach is the major limitation of this

first layer. Figure 3: Shadow mapping stage 1 (color buffer).

2.2. Multi Pass Abstraction

This abstraction is used to draw a single set of primitives
repeatedly with different States in the specific order given
by the order of the States.
This method is called multi pass rendering where pass n
is defined as drawing the primitives with n − th State. Be-
cause of the specific order of passes required the primitives
can not be sorted into the existing set of buckets according
to their state used for the respective pass. The simple so-
lution systems like OpenSG use is to introduce a so called
MultiState which instead of StateChunks contains the States Figure 4: Shadow mapping stage 2.
for each of the n passes. For sorting purposes the MultiState
is treated like any other State with its corresponding bucket As the rendering backend was not capable of handling
into which the primitives can be sorted. The drawback of multiple stages, current systems offloaded the logic needed
this approach is that if the States of individual passes are to different areas. OpenSG for example uses per stage view-
shared between different MultiStates the fact that they are ports in order to provide the correct ordering and the pos-
contained in different buckets requires them to be activated sibility to store temporary results. And by doing so it splits
for each MultiState instead of once for each pass. each stage into an independent rendering traversal which has
no knowledge about any other. This split makes it difficult to
pass information between different stages. Often it is also
2.3. Multi Stage Abstraction
found that one stage is completely executed, including all
Not only are sets of primitives drawn repeatedly using mul- OpenGL calls, before the next stage is processed. One set
tiple States but whole subtrees are traversed multiple times of problems with this approach arise from the fact that the
in a specific order. Furthermore temporary results like color processing of the stages is taken out of the one integrated


c The Eurographics Association 2007.
48 Wolfgang Müller-Wittig & Gerrit Voß / Challenges for modern Scene-Graph Systems

the need to provide an intermediate caching structure. This

structure should be able to exploit frame to frame coherences
and at same time detect valid changes that trigger a required
rebuild of the shading program.

2.5. Out of Order Rendering

The ever increasing complexity of geometric models re-
quires optimizations already at the initial traversal stage of
a scene graph based rendering system. An important conse-
quence of the introduction of optimizing traversals, as for
example implemented for occlusion culling, is the loss of
a fixed traversal order. As a consequence any proposed ap-
proach to the previous mentioned challenges should inte-
Figure 5: Shadow mapping stage 3. grate well with a dynamic change in the traversal order from
frame to frame. In particular intermediate structures should
be light-weight enough to be stored and restored with the
current traversal state.
rendering traversal. Thus information only available during
the rendering traversal, like accumulated transformations or
bounding volume visibility in dynamic scenes, is lost and 3. Conclusion
must be recreated. This introduces unnecessary overhead by
In this work we have analyzed the abstraction layers as they
using additional traversals in order to recreate the lost infor-
are found in current, OpenGL based, scene graph systems.
mation. Furthermore it is difficult to decide if a particular
Our analysis focused on challenges which are likely to im-
stage has to be executed or not. If, for example, the object
pact the adaption or development of newer real-time com-
which uses the temporary result from a stage is not drawn
puter graphics algorithms, like the class represented by en-
because it is culled away the stage creating the result should
hanced shadow map methods. In particular we were inter-
be skipped too. As the stages are independent and each is
ested in the impact in terms of performance penalty and flex-
executed before the next stage is started there is no easy way
ibility of use.
to prevent an earlier stage from running once it is detected
that the result is not needed in a later stage. All the shortcomings and inflexibilities described actu-
ally do not prevent modern multi pass or multi stage algo-
rithms to be used with the current rendering backends of
2.4. Shading Languages
modern scene graph systems. But they come at a price, both
With the introduction of shading languages OpenGL lost a in terms of unnecessary overhead in runtime and implemen-
key feature current scene graph systems heavily relied on, tation complexity. Often this price is too high, so that al-
the ability to distribute the actual state changes. Within cur- gorithms are either not adapted or adapted in a way that is
rent systems the state changing OpenGL calls were distrib- tailored to a specific scenario in order to prevent the per-
uted on two levels. At the lowest level the OpenGL calls formance penalties. Thus making it hard to use the tailored
are grouped and abstracted into individual objects, for ex- implementation in general scenarios.
ample the OpenSG state chunks described in 2.1. The ab-
Currently approaches for first set of challenges have been
straction objects (StateChunks), as they can be defined and
proposed [VR06], but especially in the shading language
created anywhere in the scene graph, are collected during the
area further research is needed.
rendering traversal and each geometry is associated with a
collection of them. If, during the geometry processing, con-
secutive collections contain changes the minimum amount
of OpenGL calls are generated as the changing StateChunk
pairs are evaluated individually.
Shading languages introduced another layer into this
process. As described above prior to the arrival of shad-
ing languages each individual StateChunk would emit the
required OpenGL calls directly. With shading languages a
unique shading program has to be generated from the col-
lection of StateChunks, in addition to the still needed state
changing OpenGL calls. As the regeneration of the shad-
ing program is to expensive to repeat it every frame there is


c The Eurographics Association 2007.
 Wolfgang Müller-Wittig & Gerrit Voß / Challenges for modern Scene-Graph Systems 49
References
[MT04] M ARTIN T., TAN T.: Anti-aliasing and continu-
ity with trapezoidal shadow maps. In Proceedings of the
2004 Eurographics Symposium on Rendering (2004), Eu-
rographics, pp. 153–160.
[OB05] O SFIELD R., B URNS D.: Openscenegraph, ref-
erence guide. Online, http://www.openscenegraph.org,
2005.
[RH94] ROHLF J., H ELMAN J.: Iris performer. a high per-
formance multiprocessing toolkit for real-time 3d graph-
ics. In Proceedings of SIGGRAPH 1994 (1994), Glassner
A., (Ed.), Computer Graphics Proceedings, Annual Con-
ference Series, ACM, ACM Press / ACM SIGGRAPH,
pp. 381–395.
[RVB02] R EINERS D., VOSS G., B EHR J.: Opensg - basic
conepts. OpenSG 2002 Workshop, January 2002.
[SAFL99] S EGAL M., A KELEY K., F RA -
ZIER C., L EECH J.: The OpenGL graph-
ics system: A specification (version 1.2.1).
ftp://ftp.sgi.com/opengl/opengl1.2/opengl1.2.1.pdf,
1999.
[SALB04] S EGAL M., A KELEY K., L EECH J., B ROWN
P.: The OpenGL graphics system: A specification (ver-
sion 2.0). http://www.opengl.org/documentation/
specs/version2.0/glspec20.pdf, 2004.
[SKW∗ 92] S EGAL M., KOROBKIN C., W IDENFELT
R. V., F ORAN J., H AEBERLI P.: Fast shadows and light-
ing effects using texture mapping. In Proceedings of SIG-
GRAPH 1992 (1992), Computer Graphics Proceedings,
Annual Conference Series, ACM, ACM Press / ACM
SIGGRAPH, pp. 249–252.
[VR06] VOSS G., R EINERS D.: Towards a Flexbile Back-
End for Scenegraph-Based Rendering Sytems. In Pro-
ceedings of Graphite 2006 (2006).
[Wel04] W ELSH T.: Parallax mapping. In Shader X3. Ad-
vanced Rendering with DirectX and OpenGL, Engel W.,
(Ed.). Charles River Media, 2004, pp. 89–95.


c The Eurographics Association 2007.