This project is read-only.

How would you recommend Xen users to manage a Scenegraph?

Nov 2, 2008 at 2:49 AM
I have been studying the Xen framework for a while now and I'm now looking into creating a quick game using it. Something that I need to add is a Scenegraph.
My needs are rather small as the levels will be quite small (it's a 3d top view shooter game).

However, I want to create a tree based scenegraph that will store all the game object instances, their model, texture, position, rotation and other game properties. I thought I could separate the scenegraph from its current rendering pipe: I would traverse the scenegraph for input and AI updates, colision detection and other game updates but then add them to a rendering pipe that would sort, cull and render using only one DrawTargetScreen instance.

I don't know if this is a good idea but this way I could separate the logic from the rendering in a neafty way and it would allow me to later on change the Tree based scenegraph to any other scene graph system (i.e: octree).
What would you recommend?

Nov 2, 2008 at 3:54 AM
Edited Nov 2, 2008 at 7:08 AM

If it works for the game you are making, then it's a good idea. (I know, that sounds like a bit of a cop-out :)

One of the goals I have with xen is that it is an API, not an engine. An engine would be designed around a certain type of scene graph, with certain ways you do things. The way this usually ends up is that everyone wants to do things slightly differently, so the engine gets expanded and expanded, hacked and tweaked until it's an awful mess.

With xen I simply want to provide a solid api that you can do what you want with. For example, while I do provide a scene partitioning binary tree class, it is really just there to make culling more efficient - and has the single restriction that it's children be static.

Basically, it's entirely up to you. I could provide all sorts of scene management classes and tools - but these would require all sorts of assumptions about the objects being placed within them. And really, it isn't an ideal fit for a graphics api.

For example, you might notice there is no interface for an 'entity'. So there is no way to get even simple things like position, size, rotation. This is by design. I wanted it this way. The moment you start saying 'to do this, you need this' then you start putting limits and causing problems. The OGRE engine is a good example - to begin with, everything had a position and quaternion rotation. But then someone needed scale, so they added scale. Then they made a reflection effect, so they needed to mirror along an axis, and a few other corner cases.. In the end it was complex and bloated.

In your example, you could have a 'SceneDrawer' class. This class would implement IDraw, it could traverse your own data structures, finding all the entities within and calling their Draw() methods.

Something that implements IDraw doesn't have to actually draw something. Unlike DrawableComponent in XNA, IDraw is intended to be called in a tree-like structure. Your geometry implements IDraw -> your meshes implement IDraw -> your models implement IDraw -> your entities implement IDraw -> your scene implements IDraw. (And so on :-)

I hope that makes sense. I understand that many people want something that provides methods for doing everything they might want. I certainly respect that. It's just I feel that if you go that route you will only ever truly satisfy a very small portion of your users.

Nov 2, 2008 at 3:48 PM
It makes perfect sense :)

Thanks for the answer, I'll make my way through this implementation and I'll share the end results in here just for the sake of having something that helps out any other potential Xen user.