Actor Hierarchies

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

    • Actor Hierarchies

      Hey guys,

      So I am trying to plan out how I will do my actor hierarchies, I am referring to how my actors will be in relation to one another if they are made of several different types.

      For instance, Unity seems to have there hierarchy set up through the transform component. I will try to describe what I have come up and any input or advice would be great.

      I see my Physics and Transform components as being directly in sync, if there is no physics component the only way to move is with the transform which works fine, but if there is one, it is best to use the physics component for movement, however applying to the transform will still update both (but with undesirable effects). The render component is simply the visual aspect of the actors.

      When I think of what systems will be affected by an object in a hierarchy I think of only the physics, transform and render. Each one will need to know that object B is a child of object A, which also means it's position is relative to that parent. I have thought of each system yet I still am coming up short on how I should do this properly.

      Physics - I figure that in order for the physics to understand that these objects are attached to one another I will need to apply a physics joint to attach them. This will in turn either set the object and its attached objects (by joint) to kinematic, or put them under physics control

      Transform - I also figured that the game logic will also need to know about these relations, for instance a tank actor will have a turret, the game logic will need to know this in order to fire the cannon in the orientation of the turret. The only way I can think of doing this is by making a similar scene hierarchy where transforms have children, I believe Unity does something like this

      Render - Now this is where I get confused, the scene graph is efficient for rendering, but should I have a duplicate scene graph but just for the rendering?

      Also, how do most people go about converting a 3D model into a complete actor with a heirarchy? Do they make an actor with a render component that loads the model, and then grabs all the child models in the file and creates there own actor for each one, and then links the actors together appropriately?

      Any advice or resources would be great, this is really stumping me.
      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
    • RE: Actor Hierarchies

      Generally, there is a single owner of the object's transform. In your case, it sounds like it's the physics component. If you attach two objects together by creating a physics joint, you shouldn't have to do much else. The object's world transform should be updated automatically as the parent object moves.

      I'm not 100% convinced you even need a transform component, unless you have it just proxy for the physics component. Keeping the two in sync is more trouble than it's worth.

      To bring it all together, what you really want is an object hierarchy. An actor should be able to attach to another actor, which will link them together. The attachment should know how to create the physics constraint as well as update the scene graph to attach the child's node to the parent's. This is basically what we did in Rat Race, though without the physics side since we didn't use physics in that game.

      This also depends on the end result you're after. Is this just a visual thing, or are their gameplay ramifications as well?

      In Rat Race, Tina (the main character) was actually made up of four meshes, each representing a different part of her body. This let us easily swap meshes and textures when she changed clothes. She had a special kind of rendering component, but that's it. It handled putting her together. No other system had any idea that she was a composite of multiple meshes because it had no effect on gameplay.

      -Rez
    • Hey Rez,

      Do you know of any good resources for animation systems? I am having alot of trouble finding any online info or even a book on it.

      I am looking for something that explains animation for skeletal meshes and morph target meshes(I think thats what they are called). I have found some basic info explaining them, and I understand the basic structures. But I am having trouble piecing together how it would be done in a component based object system. I have come up with this so far.

      I would need two new components for the skinned mesh type

      - Skeletal Component
      - Mesh Component

      The skeleton component would describe the bones of a specific game object which would be a copy of the original bone data, this component would also hold all the animations to do with the skeleton.

      The mesh Component would interface with a skinned mesh render node which would grab the skeletal component of the actor in question, query for it's current matrix palette (Which would be produced after all the animations and such are set for that frame), and then it would make a temporary copy of the mesh that is attached to the skeleton and modify all of it's vertices to be positioned properly.

      Is this a good way of doing animation, is there some common practices I would be better off going with? I am also questioning whether I should be making a copy of the mesh and modifying it, as I assume there is a different way of doing this. Could you maybe even give me a quick run down of the process of when a command is sent to the game logic from a view to move an actor, and how the animation is triggered, I feel like I grasp the concept of skinned meshes, but right when I feel like I have got it and sit down to code I don't get beyond my basic data structures.
      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
    • Originally posted by mholley519
      Do you know of any good resources for animation systems? I am having alot of trouble finding any online info or even a book on it.

      I am looking for something that explains animation for skeletal meshes and morph target meshes(I think thats what they are called). I have found some basic info explaining them, and I understand the basic structures. But I am having trouble piecing together how it would be done in a component based object system.

      Not really. Animation is one of those dark arts in game programming that doesn't have a huge amount of information. Mostly I'll see a chapter or two in a book talking about it. Most of my animation experience is with really simple systems, like the one we used on Drawn to Life. There wasn't anything fancy there, we just played the animation on the character at the appropriate time. I don't think we even did much (if any) blending. I'll ask around and see if anyone has any recommendations for good books.


      I have come up with this so far.

      I would need two new components for the skinned mesh type

      - Skeletal Component
      - Mesh Component

      This seems fine, assuming that non-animating characters only have the mesh component.


      The skeleton component would describe the bones of a specific game object which would be a copy of the original bone data, this component would also hold all the animations to do with the skeleton.

      The mesh Component would interface with a skinned mesh render node which would grab the skeletal component of the actor in question, query for it's current matrix palette (Which would be produced after all the animations and such are set for that frame), and then it would make a temporary copy of the mesh that is attached to the skeleton and modify all of it's vertices to be positioned properly.

      Is this a good way of doing animation, is there some common practices I would be better off going with? I am also questioning whether I should be making a copy of the mesh and modifying it, as I assume there is a different way of doing this. Could you maybe even give me a quick run down of the process of when a command is sent to the game logic from a view to move an actor, and how the animation is triggered, I feel like I grasp the concept of skinned meshes, but right when I feel like I have got it and sit down to code I don't get beyond my basic data structures.

      Making a copy of the transformed mesh seems bad. Why not just have a reference pointing back to the transformed mesh instead of directly copying it? Other than that, this system seems reasonable, although very simple. You'll need a lot of bells & whistles before you can really use it. For example, animation often takes a long time. Recomputing all that vertex information is expensive and you only want to do it when the character is actually on screen. If the object is culled from the renderer, you shouldn't do a full animation. When it comes back in view, you recompute where it is as if it had never been off screen.

      A real animation is usually a LOT more complex just transforming a bunch of vertices based on weighted bones. Many games treat their animation system as a state machine and game objects can often be in multiple states. For example, we have full-body animations, upper-body animations, and lower-body animations here on The Sims. Some animations looks great when blended with sit postures and some don't, so they're tagged appropriately. In a game like The Sims, we have an incredibly complex animation graph that determines how a Sim can go from one animation to another. If a Sim is sitting on the couch reading a newspaper, there are a number of transitional animations that need to happen before the Sim can successfully be hugging another Sim. They have to put their object down, go to a stand position, route to the other Sim, then go into a hug animation. We use dijkstra's to traverse that graph and find the shorted path.

      This is a small sample of the complexity of our system. The point is, every animation system I've used has been written specifically for that style of game. It's hard to really spell out how it should work. The Sims has a very complex set of operations that are run when you click on another Sim and choose Hug. An FPS will have a very different set of requirements.

      Usually, actions are set up as blocks of functionality. For example, in The Sims, taking a shower might look like this:

      1) Route to shower slot
      2) Spin out of clothes and set up censor grid
      3) Run get-in-shower animation
      4) Run take-shower looping animation until done
      5) Run get-out-of-shower animation
      6) Spin into outfit and remove censor grid
      7) Done; sim is now at shower slot

      Each of those are basically sub actions that can have side effects, such as causing the Hygiene motive to rise as the sim loops the take-shower animation. You'll likely need something like that.

      To answer your question in a general sense, here's what I would expect for the extremely simple case of an actor waving his hand.

      1) Wave command comes in from View.
      2) Wave action is pushed onto the actor
      3) Wave action applies the wave animation that was tuned on the action by calling SetAnimation() on the animation component (or skeletal component, in your case)
      4) This deforms the mesh according to bone weights, etc.
      5) Every frame, the current state of the mesh is pushed to a scene node as a pointer
      6) When your scene is rendered, it dereferences the pointer to find the actual, deformed mesh to draw

      Does that make sense?

      -Rez
    • Yeah that makes good sense, I am coming to see that animation is going to be a big hurdle to learn.
      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
    • On The Sims, we have an entire team of four or five engineers dedicated to animation programming. That's not particularly common, but animation is a huge part of our game so it makes sense for us.

      -Rez