Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Scene graph thoughts

4 views
Skip to first unread message

Murrgon

unread,
Jun 25, 2002, 11:48:44 AM6/25/02
to
Greetings,
I am doing some research on scene graphs and would like some others
thoughts about the subject. I have read the section in "3D Game Engine
Design" on scene graphs and looked at references on the net to Java3D
and Open Inventor.

It seems to me that these types of graphs are primarily only used
for rendering purposes. Some of them describe additions like collision
detection and physics, but those things seem like an "add-on" or after
thought. So if a scene graph is for rendering, how do you fit it together
with something like geometry organization (BSP, Octree, portals, etc)?

When you want to add something to the scene, how do you figure out
"where" to insert it, or is that something that needs to be determined
beforehand in the loaded scene file?

Here is an example of a scene graph hierarchy that I have come up with for
a possible racing game:

root
renderTarget
viewPort
camera
enviroment cubeMap
renderTarget
viewPort
camera
textures for back ground element #1
render states for back ground element #1
back ground element #1 mesh
textures for back ground element #2
render states for back ground element #2
back ground element #2 mesh
textures for race track
render states for race track
race track mesh
textures for car
render states for car
car mesh
carBody mesh
frontLeftTire
frontRightTire
rearLeftTire
rearRightTire
viewport
camera
textures for rear-view mirror
render states for rear-view mirror
rear-view mirror mesh

Performing an in-order traversal through this graph would first render the
environment cubemap, then the back ground, the race track and then the car.
I also added a separate viewport for a rear-view mirror.

This graph seems to differ from the others I have looked at in that it is
defined by layer. For instance, the first layer after the root alwasy has
a renderTarget setting. The next layer is a viewport and after that a
camera. It seems straight forward, but I am wondering if I will run into
problems with this setup?

Any thoughts would be appreciated.
Thanks

Murrgon

Eric Grange

unread,
Jun 25, 2002, 12:11:12 PM6/25/02
to
> So if a scene graph is for rendering, how do you fit it together
> with something like geometry organization (BSP, Octree, portals, etc)?

Not directly.

Scene graphs usually favor scene description flexibility over rendering
efficiency. An engine based around BSP/Octree/etc. will typically
be based on a rather static scene description (there can be mobile
items, but most of the data is actually a "precompiled" set,
suited to a particular rendering logic).

BSP/etc. are commonly integrated into scene graphs with "magic nodes"
in the hierarchy, that take care of rendering that BSP/etc. geometry
in the most effective manner.
Of course, you'll find all kinds of hybrid variants that "compile"
scene graph geometry on the fly to BSP/etc., and others that "decompile"
BSP/etc. so they fit the scene graph architecture.
The choice entirely depends on your needs (fastest rendering?
simplest design? jack of all trades? etc.)

Eric Grange
http://glscene.org

Fred Klingener

unread,
Jun 25, 2002, 1:38:32 PM6/25/02
to
"Eric Grange" <egr...@glscene.org> wrote in message
news:3D189620...@glscene.org...

> > So if a scene graph is for rendering, how do you fit it together
> > with something like geometry organization (BSP, Octree, portals, etc)?
>
> Not directly.
>
> Scene graphs usually favor scene description flexibility over rendering
> efficiency. An engine based around BSP/Octree/etc. will typically
> be based on a rather static scene description (there can be mobile
> items, but most of the data is actually a "precompiled" set,
> suited to a particular rendering logic).

. . .
I've been interested in doing kinematics on the scene graph, and this thread
is as good as any to jump in on.

I had thought that the sg was oriented more toward rendering, and it started
getting awkward as soon as you introduce simple things like (what mechanical
engineers used to call) constraints (but because of pollution of that word
in cg contexts has to be renamed something else now, but I don't know
what)and got progressively worse when you try to model 'kinematic
inversions'.

Some models can be cycled through 'kinematic inversions' by keeping the same
basic internal connectivity and rearranging the connections to the
environment. Generations of kinematicians grew old concerning themselves
with what happens when you grab a different link of your 4-bar linkage and
identify another as the input. Other more interesting examples might be
shifting gears in a planetary gear set or a human figure walking with first
one foot attached to the ground, then another.

If you drew the scene graphs for a couple connectivity states (inversions)
of the 4-bar linkage, the planetary gear set, or those of a walking human
figure, the similarities would be obvious, but the differences are large
enough to suggest the impracticality of reassembling the scene graph by
brute force every time the external connectivity changed.

Models for none of these examples sit very well on the acyclic, directed,
and more or less static scene graph, so the immediate questions include 1.)
is there a supergraph on which you can express the internal connectivities
or constraints (graph cycles?) and express external connections in a way
that they can be changed on the fly, and 2.) is one type of supergraph
better than another in the ease and speed with which it can be decomposed
and then recomposed into a scenegraph for presentation to the graphics
system whenever the internal or external connectivity changes?

To begin with, to be able to express internal constraints, the supergraph
certainly has to be cyclic, and, with a good object design, the supergraph
cycles should hide whatever computations are required to satisfy those
constraints frame-by-frame. The, with the imagined scene graph of a 4-bar
linkage in mind, it almost certainly will be undirected.

Any ideas?

Fred Klingener
Brock Engineering

Hans-Bernhard Broeker

unread,
Jun 25, 2002, 5:19:07 PM6/25/02
to
Murrgon <mur...@hotmail.com> wrote:

> thought. So if a scene graph is for rendering, how do you fit it together
> with something like geometry organization (BSP, Octree, portals, etc)?

I wouldn't agree that a scene graph is very much "for rendering" ---
if you want a data structure optimal for rendering over everything
else, a scene graph isn't what you're looking for.

A scene graph is, first and foremost, a useful way of organizing the
*construction* of a 3D world, and changes to it. I.e. it's most
useful application is probably in the areas of 3D object / world
design programs, and animation of 3D objects.

BSP and other methods organize polygons by their absolute position in
space, mainly, without consideration for how a polygon happened to end
up in its actual position. A scene graph allows to organize them by
relations like "is a part of", or "moves together with", "is made of
the same material as", or "is a an exact clone of", instead. Or
whatever other relation you think is useful.


--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Martin Baker

unread,
Jun 28, 2002, 1:30:04 AM6/28/02
to
I am also doing some experiments with including physics/games information in
scene graphs. See the following page:

http://www.martinb.com/threed/games/index.htm

But I'm not really sure how to take this forward. Any ideas?

Martin


0 new messages