AddObjectToScene(torch); Yay, more scene graph stuff... To sum it up, Creating Complex Entities
Author
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.
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?
Author
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
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.
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 EmIt 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.
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.
For non-models, I suggest you define entities using a recursive format like XML, and make the hierarchy part of the XML format.
Author
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?
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?
Erm, no?
Turns into :
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?
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?
Author
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.
The wheels, all 4 of them, are relative to the truck body. And I'm pretty sure thats what my little diagram shows.
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.
If you're doing it in a correct and proper way, order shouldn't matter.
Author
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement