scenegraphs and other monstrosities

DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #1
After mentioning it in this thread about file formats, here is what I came up with so far.

The basic idea of my scene-graph is that its a hierarchy of nodes, and each node affects its child nodes.

An example scene graph:
[Image: scenegraph.jpg]

How skeletal animation could be done:
[Image: skeleton.jpg]

It's all pretty vague so far, but I think its a good concept. It may seem like it introduces a lot of extra nodes, but not each of those nodes has to be implemented, some can possibly be aggregated, eg. a "transformation animation" could handle position, rotation, etc. instead of having separate instances for rendering. I think for storage it does make sense to separate the components, as to only store minimal information, and leave greater flexibility for loading the file.

So much so far, I'll post updates as soon as I come up with some new stuff.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #2
What does the "pos anim node" contain?
Also, why not post this to the file format thread? If we are trying to create a commonly agreed-on format, dividing the discussion on two threads may not be the best way to go Smile
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
PowerMacX Wrote:What does the "pos anim node" contain?
Also, why not post this to the file format thread? If we are trying to create a commonly agreed-on format, dividing the discussion on two threads may not be the best way to go Smile

The other thread seems to be focused on much simpler stuff than what I have in mind. "Scene-graph" seems to be a word that is not even recognised ("sub objects" anyone?).

Anyway, about the "pos anim node": It's symbolic for position animation. The idea behind it is simple key-framed animation of position.

[Image: animationnodes.jpg]

The picture above shows in which order the nodes are "evaluated" when rendered, being part of the scene-graph tree. In the actual game, the 3 nodes of different transformation animations could be represented by a single object as an optimisation.
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #4
DoG Wrote:The other thread seems to be focused on much simpler stuff than what I have in mind. "Scene-graph" seems to be a word that is not even recognised ("sub objects" anyone?).
Ehem... I was thinking sub-objects from the start. Anyway, I'm not exactly sure where you're trying to go with this now but I'll play along for a bit more because I'm still interested. I've been studying many different 3d file formats since this topic came up, which has been very educational BTW. Plus, I hate long threads and here's a new one to mutilate! Who could resist such temptation?

To be clear, I am not a trained computer scientist per se but I've read my fair share of programming papers and what you seem to be describing is not what I've understood to be a classical "scene-graph" but just another way to store a model. Except that you are referring to individual data blocks as nodes. I'm trying to wrap my mind around your diagrams but I just keep thinking it looks like another way to represent an md3. So to continue the discussion, I'm guessing that you mean that the "root node" is just *one* model in the file. Right?
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #5
DoG Wrote:The other thread seems to be focused on much simpler stuff than what I have in mind. "Scene-graph" seems to be a word that is not even recognised ("sub objects" anyone?).

After reading some posts by someone who will remain nameless Rolleyes it may seem so! Anyway, scene graphs seem more adequate for level files, since the kind of animation you are describing seems to modify objects (or sub objects) positions/orientations, but not shapes. A basic characteristic of scene-graphs is actually optimizations due to the assumption that they are massively complex, in terms of size, number of sub objects, textures, etc. At least that's the case for classic scene-graphs, and most of the optimizations usually associated with scene-graphs aren't necessary when we are talking about "individual objects": Portals, minimization of texture switching, positioning/orientation of sub-objects using matrices (as opposed to quaternions), etc.

Maybe this could be the thread for a "3D scene file format?"
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #6
I have very different scene-graph architecture working right now, but it is too limited and awkward. For any who are interested, the source code is available at http://dog4.dyndns.org:8080/svn/yag/yag/ (look in the YAGGraphicslib @ graphicobject.h etc)

Now, if you look at OpenScenegraph for example, they do a very similar thing as to what I have in mind, at least as far as their concept of the scene-graph goes.

Every scene-graph that is a tree must have a root node, that is the nature of trees. I have only done the first diagram to see what a "whole" scene might look like.

The nodes can be pretty much arbitrary. Animating shapes is also possible (vertex-morphing) if you simply introduce a node capable of doing that. I just haven't mentioned that to keep it simple. The only restriction is that nodes only affect their children. Obviously, the actual triangle mesh must be a leaf node, as all state information we set in OpenGL affects how the triangles are rendered.

Furthermore, by keeping each node conceptually and functionally simple, nodes can be merged however the respective game engine requires it, either for performance or simplification. By making nodes to complex, implementing appropriate runtime objects could become overly complex, but by keeping the nodes in the file simple allows such optimisations when required, yet also allows for a simplistic implementation when performance is of no concern (eg. prototypes).

As far as a single object vs. a whole scene, it doesn't make a bit of a difference. Special nodes could be inserted into the scene graph, for example to group objects into rooms for portal rendering. Whether we are dealing with a single mesh or thousands, it doesn't make a difference for the file format.
Quote this message in a reply
Post Reply