Heirarchic Actor's

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Heirarchic Actor's

      Hey Guys,

      I asked this question quite a while back, and I don't think I ever quite grasped it or got an answer that really satisfied the question, it would be really nice to get this figured out and I hope that someone has an answer.

      Here is the situation I will use as a model;

      - I have an empty scene
      - I wish to add a 2D car to the scene
      - The car has 3 components, the chassis, and two wheels.

      Here is where I get messed up

      Approach A
      -----------------
      - The car is a single actor, with a single central transform
      - The actor has 3 rigid body/collision shape sets to describe the physical nature of the car
      - The actor has 3 sprite components with their associated sprite nodes, these need to follow the rigid bodies position and rotation

      What is the relationship between the single transform, the 3 rigid bodies, and the 3 sprite components? How do they all maintain position?

      Approach B
      ------------------
      - There are 3 actors, one for each part of the car
      - The actors have there own rigid body and sprite components

      My current engine supports this, however now how do I keep track of my car when it is in several different actors? I have it figured out how to do it with approach B, but It seems hacky and I don't know if it is the
      right way to go, I am afraid that if I try anything complicated with objects that exist beyond a single component (Tanks, Cars, Helicopters), that I don't quite know how to do this.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Approach C:
      You create four actors. One represents the car and lives on the scene. This has a transform for the car's position as well as any components necessary for gameplay (stuff that's "global" to the car). The other three actors are attached to this car as children. They have transforms which are relative to the parent car actor as well as rigid body components, sprite components, and anything else that's specific to that part of the car.

      There's nothing really hacky about this. The gameplay systems probably don't even know about the children actors and just go through the parent for everything. It's really only physics and rendering that have to know about the children, and even they don't need to know about the hierarchy. Everything is nice and encapsulated.

      Approach D:
      You have a single actor that represents the object. You have the concept of compound physics and sprite objects that allow for parenting. So your physics component could have three physical objects contained in one compound object that conforms to the same interface. This is sort of what we're doing with the scene nodes in GCC, though not quite.

      We used approach D in Ratrace. It worked well because we didn't end up using physics at all, so we really just had a bunch of meshes that needed to play nicely together. Tina, for example, was four different meshes that we could independently update. This was used for mixing and matching clothes. It becomes more annoying if you have multiple components that are attached to other sub-components.

      Approach C is used in engines like Unity and it works extremely well, but you have to solve the actor hierarchy problem and make sure all your components play nicely together with parents & children. I generally prefer this method because you can attach different functionality to specific components (like the wheels) rather than the object as a whole. So you could have a collision event that occurs when the player runs over a nail, but if it goes between the wheels, no event occurs.

      -Rez
    • So with approach C, my actor list would essentially remain the same, however my actor class would be implemented like an N*ary tree, where it has a list of child actors, and a parent actor? I had thought about doing this, than I wondered about having essentially two trees, one for rendering and one for logic.

      Do you think having multiple trees like this is bad, or would the render tree essentially be for render optimizations?

      I am planning on using OGRE 3D in my 2nd engine which is in development at the moment on the side (until our game is finished), and I imagine this setup would be forced on me with OGRE's internal scene manager, and my 'actor' scene manager.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Having both is perfectly valid. I have a strict separation of logic & rendering in my engine so some amount of data gets duplicated. I also have a separate thread for rendering. The render thread is always one frame behind, rendering the scene that the logic just built up. It's possible for the child/parent links to be broken in the logic thread before the render thread has gotten to that object. Thus, having this separation is very useful.

      I don't know quite how Ogre handles this situation, but if you're plan is to migrate to it, I would check out what they do and conform to that environment.

      -Rez
    • Pretty awesome how I keep running into problems / situations that you guys bring up a couple days before hand.

      I really like approach C here as it seems to provide the most decoupling of components. I want to make sure though that when you guys talk about "hierarchy" you're talking about composition as opposed to inheritance correct? Or am I missing something...
      -bullgoose
    • Yes, we are talking about composition in this case, the hierarchy in question is really just building an N*ary tree into the existing actor system, I am sure it will be much more complicated than that once I get to it, but essentially your actor class can have a list of 'child' actors, which each have a pointer back to the parent. This will basically set up a tree of actors, almost exactly the way the scene manager is set up.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz