Scene Graph?

[teraskasi]

Hi. I'm working on a game engine for a top down space game with similar game play to subspace.

 

Right now I'm researching scene graphs for that purpose. I was wondering if Discretion is using any sort of scene graph? Although I have a pretty good grasp of the basics of scene graph implementation, I'm still a bit confused and can't complete my implementation. Pretty much all scene graph stuff I can find is geared towards 3D worlds, and is really bloated IMHO. I'm just looking to implement a basic 2D scene graph with possibly a "depth" node to create the illusion of 3D by scaling transformations so that distant objects move less as the camera moves. The game I have in mind is only like subspace in the way of being top down 2d and having a similar combat system -- I don't plan on having bases, tiled maps, etc.

 

I suppose the classic subspace game didn't really need a scene graph, but what I have in mind really should use it. The scene graph will have celestial objects orbiting other celestial objects: stars, planets, moons, asteroids, etc. Colonies that are attached to planets, and space stations that are only attached to the nearest star, but are otherwise drifting through deep space.

 

Not only that but man made objects (ships, stations, etc) will have base hulls, and components attached to the base hull. Similar to when a player is attached to another player in subspace -- having weapon turrets like that, except the weapon turrets will not all be in one spot like subspace. Rather, they'll each have a unique place on the hull of the ship.

 

Just thought you might want to know why I'm looking for an implemented scene graph.

[Samapico]

If I only knew what a scene graph was...

[CRe]

If I only knew what a scene graph was...

 

http://en.wikipedia.org/wiki/Scene_graph

[teraskasi]

Hmm yeah there's the wikipedia entry, but to put it in the simplest terms I can, it's a tree style data structure, where the top most node (trunk) is the root of the entire scene and the most background object, and the bottom most nodes (leafs) represent the most foreground objects, as the tree is drawn from the root to the leafs. There can be various kinds of nodes in the tree, and that typically depends on the needs of the project, but for a game you'll typically find a graphics node, a rotation node, a translation node, a DOF (transformation) node, a scaling node, a switch node, and so on.

 

The graphic node would of course contain the graphic representing the object in question, such as a ship's base hull. Let's say I wanted to add a weapon turret to the base hull of the ship. It might look something like this:

 

> Ship Base Hull Graphic Node (Display the graphic)
> > Translation Node (set the position for all children relative to the center of the ship, say... x=0,y=10 for the front of the ship )
> > > Rotation Node (rotation changes based on player control)
> > > > Turret Graphic Node (Display the graphic at the new location)

Edited October 17, 2008 by Steel Arm

[»doc flabby]

This is something i'm trying to write for my project interestingly. Its currently not in any workable form though....

 

You might be able to get away with just using a http://en.wikipedia.org/wiki/Z-buffer for your project rather than a full blown scene graph as its just in 2d.

Edited October 17, 2008 by doc flabby

[Bak]

Discretion doesn't use a scene graph currently. Although it may be a neat thing to put in at some point.

[teraskasi]

I'd be happy to post my code once it's in a somewhat working condition. The trouble I'm facing is: What is the best (most efficient) way to let updates (transformations) propagate through the tree?

 

It seems to me that the only way to propagate changes is for every node to have a full set of data to accommodate every type of node... In other words.... If you having a scaling node, then a rotation node... The rotation node needs to now keep scaling information to p!@#$%^&* on to it's own children. It somewhat defeats the point of having separate node types.

 

But... I've also come to the realization that I can't use just SDL 2D anyway, because SDL doesn't have a fast real-time way of rotating sprites aside from the way it's done in Subspace with different frames (pre-rendered images), so I'm probably going to end up using OpenGL with SDL and OpenSceneGraph. That's probably for the best though, since I wanted to eventually add some 3D elements, such as 3D planets in the background.

 

I don't think a Z-Buffer is enough for me. The whole thing I want to do is easily manage the relationship between objects. The game I am looking to create is intended to be a much for dynamic, moving world than that of Subspace where objects are mostly all static.

[Bak]

What is the best (most efficient) way to let updates (transformations) propagate through the tree?

You might be able to use pointers to rotation/scaling nodes to speed things up.

 

It somewhat defeats the point of having separate node types.

well it still allows you just just change one rotation value and have it effect an entire set of objects... even though it might not be super-efficient. Just a good abstraction