• 12
• 12
• 9
• 10
• 13

# Yay, more scene graph stuff... To sum it up, Creating Complex Entities

This topic is 4397 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Alrighty, I'll use a torch object for an example, what is this thing made out of? 1. Torch stick geometry 2. Particle Emitter 3. Light 4. Maybe even an ambient sound generator (crackling) Now, What I want to do ultimately, is be able to do something nifty like this.
 AddObjectToScene(torch);
Looks overly simple doesn't it? Well it is! But there are a few unforseen issues... We need the add object function to create nodes required for the object it is being passed, the torch I passed it will be of type ObjectInfo.. I need to create a generic object that can contain the information required for creating scene nodes for a complex object. That is the easy part. The hard part is this, properly linking all these nodes once created, in the correct tree structure!!! We can't have a light and then a geometry and then a particle emitter.. We need a geometry, a particle emitter, and a light, do you see what I mean? So in a structure, ObjectInfo, we need to contain the order, from top to bottom, of the complex object's nodes. Something like, level 1 is a transformation node, it has one child, level 2 is a geometry node, which has 3 children, level 3 is a this and a this and a this, and has no children, end. How can I go about accomplishing this?

##### Share on other sites
Quote:
 We can't have a light and then a geometry and then a particle emitter.. We need a geometry, a particle emitter, and a light, do you see what I mean?

No, not at all. Short of doing something like putting the light into the torch model, why would the order matter?

Standard faire composite pattern with factories.

You do Factory(torch), which does Factory(model torch) [which might make other Factory calls to assemble the model], Factory(emitter fire), Factory(light fire)... and makes them children of the torch object with the proper orientation. It then returns a generic torch object which either you work with or is used by a 'higher' factory.

The actual factory definition method can vary. XML definitions are not uncommon, direct hardcoding isn't too uncommon though impractical for art-heavy games. Personally, I've found that almost empty constructors/factory parameters really help here. Focus on building the object; let the caller care about positioning, orientation, coloring...

Or perhaps I am just misunderstanding?

##### Share on other sites
Hmmm,

It does matter, for when we add Transformation into the equation..

Lets use a truck model now

We have:

A Dof(transformation), for each node
A truck body geometry, 4 wheel geometries
Attached to the truck as well, is a particle emitter, for exhaust or something

So thats 6 DOF nodes scattered all in between this complex object

It needs to be in this hierarchy

DOF NODE (Transformation)||------Truck Body           |           |           ---- DOF, DOF, DOF, DOF, DOF                  |    |    |    |    |                  |    |    |    |    |              Wheel Wheel WheelWheel Particle Em

It has to be set up that way, or else we'll have some real goofy transformation issues, The wheel's and the particle emitter's location are relative to the truck body. The truck body is probably relative to terrain, or a race track..

Straight up, it has to go in this order, or it just won't work.

##### Share on other sites
For models, the hierarchy will be part of the model file format.

For non-models, I suggest you define entities using a recursive format like XML, and make the hierarchy part of the XML format.

##### Share on other sites
Hmm, what would a non model be?

Like, the truck model with the extra particle emitter thrown on top?

Or the torch with the ambient sound and particles thrown on the top?

##### Share on other sites
Erm, no?

truck  |       \----\-----\-----  wheel wheel wheel wheel

Turns into :
Identity  -> push truck matrix ->    render truck -> push WheelA matrix -> render Wheel                 <-  pop WheelA matrix <-                 -> push WheelB matrix -> render Wheel                       [and so on]     <-NOT:Identity -> push truck matrix ->         render truck -> push WheelA matrix -> render Wheel                 -> push WheelB relative to WheelA matrix -> render Wheel                 -> push WheelC relative to WheelB matrix...

Entity geometry is based off of parent, not neighbor. The wheels [or really any object] can be in any order, since the matrix state on call is the Truck's. Right?

##### Share on other sites
You're not understanding

The wheels, all 4 of them, are relative to the truck body. And I'm pretty sure thats what my little diagram shows.

##### Share on other sites
I've seen engines that run AAA games written by so-called "brilliant" folks that are compelte crap and don't even use any type of hierarchael systems, so kudos for trying to get this to work. However, I suspect that at this point you have a serious issue with your system if the sibling nodes are order dependent in order to get a specific effect. :D

If you're doing it in a correct and proper way, order shouldn't matter.

##### Share on other sites
Okay, please don't post if you don't know what you are talking about.

Okay, on the wheeled truck

DOF
Truck
DOF
Wheel

After the second dof node, NO, it doesn't matter in what order each wheel comes.

Now lets add three more wheels

DOF NODE - parent of truck
TRUCK - parent of 4 dof's
DOF, DOF, DOF, DOF - each dof is a parent of a wheel
WHEEL, WHEEL, WHEEL, WHEEL - each wheel is a leaf

the first dof must come first
the truck must come next
the four wheel dofs must come next
the 4 wheels are on the next level

I'm sorry if I'm getting short, but I'm putting my question out there plain and simple and it is being ignored..

How do I store this information in a structure, or in a file?

EDIT:

I can draw a picture if I'm still not coming across, I did not mean for there to be confusion with "siblings being relative to each other", that is not the case, and how it came off to look that way I'm not quite sure of.

##### Share on other sites
You will assume the DOFs are all part of a higher DOF. Basically collections to the parent. If every object in the tree is a collection of aggregates(inherited from a common base class). All parts added to each objects collection become that objects child. This is where UML shines by allowing you to define relationships, collections, actors, entities etc. The base clase should also have an overable pure virtual function to identify the object via two methods. One static and one dynamic. The static defines the concrete form of the class such as Wheel. The dynamic one is the dynamic property such as "Truck Wheel", "Bicycle Wheel". From these methods the classes can be persisted with the named parent to rebuild the tree on load. You may want to store movable objects as loose collections with the position and state of the object. Store the world and it's objects states in another. This avoids unnecessary complexity of the storage model.

Your truck justs owns four wheels, if it looses one then one is removed from the list and cardinality reduces to 3. By calling Truck->AddWheel( pWheel) the parent will call Identify() for that wheel and if it is not a truck wheel then reject it else add it to it's tree. It's up to the parent node to call it's children to render, evolve, rotate, update state, force state etc. Remember the tree is a dynamic entity. Where each child is a branch with children unless it is a leaf node. This is why you have to know what the child is for when you persist the tree are need to query the objects for specific objects. A query may occur then the game requires confiscation such as take away all the matches or check all wheels for grease.

This subject gets more involved with all the available patterns which takes time to learn and master.