Scene Graph - Compiling

So, sweet, I have a couple nodes set up that I can use to compose a simple scene. I have a geometry node, a DOF node, and the all important base node.

I can create a simple scene comprised only of these nodes, the problem is, I'd have to hard code it! ICKY!!!! Who wants to honestly, create a truck geometry node, with a dof, 4 more dof's for each wheel, and then 4 more wheel geometries! Blecky!

I've thought up a simple solution to this problem.....

So, what if I could create a truck object with all of those geometry nodes and dof's etc etc, all in a simple function call, something like:

Code:

---

AddObjToScene(struct ObjectInfo);

---

Simple! But hmmm, what is an object info structure? I'd say it would be something like this:

Code:

---

struct ObjectInfo
{
  int ObjectID;
  int NumGeoNodes;
  int NumDOFNodes;
  // etc etc
};

---

A simple object that holds information on what this greater, more complex object is comprised of. How many geometry nodes are included? How many depth of fields? How are they all connected? How can we easily look up this object (ID)?

Then there is still another thing to deal with, where does all this information come from? Surely you could create objectinfo structs and hard code them into your game, but how flexible is that? Without modifying the source and recompiling headers, you couldn't change it!

Howabout a file type? Containing all the information that the object info structs need, simple stuff! So we could do something like this..

Code:

---

CreateObject(filename);

---

Sweet, so all the pieces are there, except one! We need to be able to create Object files without modifying a text file, who wants to do that? Not me! I think a simple editor would answer this problem, create a small editor program that simple creates object files, you could create any type of object you want! Super dynamic!

So there are all the pieces.

CreateObject(takes object parameters)
creates a file

CreateObject(filename)
creates an objectinfo

AddObjectToScene(ObjectInfo)


There it is, three simple steps, all done!

What do you guys think?

It is interesting that it seems you are exactly recreating the layout of my renderer :)


How do you add stuff without hardcoding? You make the data types vague. you don't program it to see something like a 'truck' or a 'wheel.' You can, but that code would just go in the game code, not the engine code. The engine should just see geometry, textures, stuff like that.

Download the octagon engine (paul's projects), it has a very efficient layout (more efficient than mine) and the renderer is very high tech (stencil shadow volumes, everything writtein in fragment/vertex shaders).

When I create the object info class, it might be a single model (with joints and bones etc etc)

But we need more than one node, it isn't very simple, so we need a data file to fill out the requirements of the scene graph, yknow?

Maybe a truck was a bad example..

Lets say, a torch..

We have the torch model, attacfhed to it is a particle emitter, and attatched to the torch as well is a light emitter, and maybe an ambient sound emitter (for flames)..

Now, When we're working with out editor, we don't really want to deal with creating the torch geometry node, creating the particle node, creating the ambient node, etc etc..

We just wanna go, bam, create torch!

Then it adds a torch object to the scene graph with all its complexities.

I understand that this is kinda defining game objects, but really its not, its just making the renderers job easier by compiling a set of nodes under a name...

The object creation gui could be something as simple as telling the object how many geometry nodes it has, how many transformation nodes, how many light nodes, how many particle emitters, how many ambient emitters, etc etc!

Then when we actually create our game entities, we can assign one of these structures to them, now our Torch game entity (which controls other properties)... can house a simple torch structure inside of it that contains everything you need to add a torch to the scene. In one command.

But we need a generic object structure. Something that holds all the information we would ever need to draw this complex object. A renderable object in the scene graph rarely is represented by one or two nodes, often they are comprised of anywhere up to 10 nodes! Imagine a Soldier model, with nodes for all animation, and nodes for every slot you could attach a piece of armor to, that could be like 30 nodes on one model!

>>We just wanna go, bam, create torch!

you have two basic options:

-You make a high level object, called 'torch' which adds the said primitives to the renderer

-You *do* make/use an editor, and a 'torch' is an entity that can be added to the map.

Some combination of the two.

Thats the idea :)

What, exactly, are you having trouble with?

Getting started lol, this is a big task to undertake :d...

BTW, getting this done would mean creating semi-complex scenes in around 2000 lines of code...

Managed scenes, not hard coded procedural crap! :o

I'm thinking an Unreal flyby scene, what do you guys think?

I just thought about something, as I was playing an Unreal tournament capture the flag tournament...

Big things, I mean big big big complex geometry, that is made up of a whole lot of geometry, take buildings for example, take the two towers in the Faces CTF map...

Imagine, building the object in an editor, (THE WHOLE TOWER!!!), and placing it with a single click!

It has lights, teleporters, walls, ambient sounds, holy cow batman!

Sure we can create a candle, buy why create 30 candle lights inside the chandeleer file when we can use a candle object we already created, 30 times, and then just add chandeleer geometry...

The possibilities are ENORMOUS..

Bob I love your commentary, but isn't there anyone else interested in this?! :)

1. Create an editor for your engine/game.
2. Pre-compute the BSP, quad tree's, bounding volumes, etc.
3. Save in file format of your choosing.
4. Load into engine at game/level start.

A scene graph can be computed w/o even touching the engine. The algo's used are geometrical algorithms based on geometric proofs.

Go get NILE from www.novalogic.com or the Unreal editor, Quake(x) editors, Black Hawk Down editors, etc, etc.....

They will give you great insight as to how this is all done.

And yes, in an editor the tower is one object that may be composed of several joined 3DS models or some other format.

In editor you click on new object, select tower, drag onto the map where you want it, set rotations, scale, etc, and plop it down.
Done.

Now this object has an ID which can be used to perform script operations on it, or other objects can test whether or not they are inside, outside, colliding with, etc, etc. the tower.

So see the script, ID's of objects assigned by the editor, 3D models and textures, editor, and engine are closely linked.

Right, I'm trying to make an editor to compute scene graphs, which will start off as a simple renderable object editor, and progress into a map editor, with a nifty renderable object editor thrown in there.

First I plan on using the editor to create a couple objects and then hard code them (in terms of doing a AddtoScene(whatever)) instead of hardcoding every aspect of the scene, just for something pretty to look at, by now I deserve it!!!!

Referring back to your torch example, wouldn't you just create a class for this entity named "torch"? Within this class you could have a create() function, which loads the torch geometry info (from a 3DS or file of you choosing), and then calls your functions that create a light and a particle emitter.

Your AddtoScene() function could, perhaps, take an int argument, specifying the type of object to be created.

Code:

---

void AddtoScene(int type)
{
  if(type==0)
      torchclass->create(args);
  else if(....)
}

---

Your editor GUI would determine which type id to pass to the AddtoScene() function.

This is just an idea; I don't really know how exactly your doing things in your engine, so this may not be any help at all.

Well that is a valid Idea psycho, but the way I want to do it in the end is to have no type switching in the add to scene function..

It will simply read the structure and add it to the scene, no mattter what it is.

No nasty if type == 0
do this
if type == 1
do this

We can just say

Do this when you get an object structure..

Kinda like an MS3D model, not all models have joints and bones, but the load function will load for them anyways..

Also creating a hard coded torch entity is an idea as well, but I think it would prove more useful to add an editor that creates a torch file, that fills out a generic objectinfo structure, for more modularity, yknow? :)

A torch model would contain:

1. Vertex/index data
2. Texture file names for all textures
3. Rendering state block(s) required
4. ID of torch as it pertains to the game system
5. Torch 'game-name' and/or torch 'object-name'
6. Position, rotation, scaling data (vector, matrix, matrix)

So in the editor stick the torch object under miscellaneous in your object tree/list, whatever, and when the map maker clicks on it, when he moves the mouse in the view window, the torch is there. You can either render in 3D using DLLs from your engine code or you can simply render an object marker in 2D.

Again go get Novalogic Interactive Level Editor for a good example of this. www.novalogic.com

Quote:

---

Imagine, building the object in an editor, (THE WHOLE TOWER!!!), and placing it with a single click!

---

You can already do this...I have used worldcraft and the quake radiant editors, these are just called prefabs (prefabrications)..

EDIT:
bubba's suggestion is the best so far, but just keep in mind it's not the *only* absolute answer. In the Quake3 engine, a torch is created with the base geometry (the actual holder) and the flame is a brush that has a special animated texture shader attached to it. I am just pointing this out because there are a million different ways of getting a 'torch' in a game. How you actually store it also depends on the level of sophistication of your renderer (i.e. how do you store a torch in which the flame can also render a refraction shader which distorts the scene behind it due to heat). Just some more food for thought.

Yes, there are a million ways to do this. However, there are also a million ways to do it wrong and code yourself into a mess.

I suggest, as before, downloading popular level editors for current game titles. This will give you great insight as to how the underlying engine works. To the normal user an editor is way to make levels, etc. To a programmer familiar with graphics techniques, algos, and structures a game editor is nearly as good as a peek at the source code. You can really tell a lot about what is going on just from how the editor arranges things and how it works.

Alright then bubba, tomorrow when I wake up I'll download one of the editors you suggested and browse around in it :)..

Okay, So I can understand this part

Code:

---

ObjectInfo
{
int ObjectID;
int NumGeometryNodes;
int NumDOFNodes;
// any other nodes we might have
}

---

But what about the more complex issues, such as, linking the nodes together properly?

I'm thinking we could have an array of integers, and we could use that in some way to just iterate through the children and link em together that way, but this is really getting too nitpicky for my programming style..

Any thoughts anyone?

Code:

---

ObjectInfo
{
int ObjectID;
int NumGeometryNodes;
int NumDOFNodes;

ObjectInfo *m_pNextNode;
ObjectInfo *m_pPrevNode;



// any other nodes we might have
};

---

Or use the STL list, vector, etc.

For example a quadtree structure:

Code:

---


struct QuadTreeNode
{
  int m_iType;    //Node or leaf?

  QuadTreeNode *m_pUL;  //Upper left child
  QuadTreeNode *m_pUR; //Upper right child
  QuadTreeNode *m_pLL; //Lower left child
  QuadTreeNode *m_pLR; //Lower right child

  D3DXVECTOR3 m_vecMin,m_vecMax;  //Bounding box

  Object *m_pObjectArray;  //Objects in this node
  int m_iNumObjects;            //Number of objects in node
};

---

Code:

---

class CTerrain
{
  QuadTreeNode *m_pRoot;      //Start of quad tree
  ....
  ....
};

---

Nice, so the final structure we pass to the add to scene function will just hold a pointer to the root node, which will point to the next node, which will point to the next node, etc etc...

Like a linked list?

Hmm, this is nifty, All I gotta do is create the stuff, and set the pointers, I can do that in the editor!

Question: Where do BSP trees come into play here?


EDIT:

Now I understand *how* the stuff is linked together, But I'm still unsure what to put in the file I create with my editor, to, well, have the program interpret it and know what to do?

The root node holds a vector of children, each child of the root holds its own vector of children. So in theory I'll be able to simply add a base node to my tree and the rest will kinda just, follow.

But lets see, if, in an editor, we set the hierarchy up, so that the truck is the base node, and has 4 children, for the 4 wheels...

How do we hold this information in a file, ready to be converted to hard code in my project? I understand how the stuff is linked together, but how do I interpret a file to create the links and link them in the right way?