Initial Positioning of Actors

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

    • Initial Positioning of Actors

      Hey Guys,

      So I just got my code going for loading level files, and I was trying to figure out which component I should be changing to initially position my actor after it is created, my idea was that in my Actor xml file, the initial position would almost alway's be 0, kind of like defining a template for an actor that can be duplicated multiple times, then once created, the level file would hold a position for the actor to be moved to.

      I decided that I would let the PhysicsComponent interface with Bullet Physics to move the object with the
      btRigidBody->SetWorldTransform method. This did move the btRigidBody, but I had assumed that it would also update the motion state for that actor, which would propagate to the TransformComponent and the RenderComponent through an event. Updating everything. However it didn't do this, so I added in a MotionState->setWorldTransform to manually update this.

      I noticed that this isn't the same as in the GCC source. Should I be doing it this way? It does work however I noticed that now my object's debug physics outline is red instead of green. Is that because of the DISABLE_DEACTIVATION? What is the purpose of that?
      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: Initial Positioning of Actors

      This is a very good question.

      There are two ways most games use to position and move actors around the game world.

      The first is via physics control. When you move an actor, you apply forces to get it to translate or rotate, and the physics system does all the heavy lifting. The second way is via kinematic control, which is just a fancy word for saying that some game code is going to set position and rotation explicitly, and the physics system will only watch the actor and if needed it will push other objects around as they collide with it.

      In GCC4, the AI teapots are actually moved kinematically through calls to the PhysicsComponent::RotateY() and PhysicsComponent::SetPosition() methods. The cannonballs (spout balls?) are moved under regular physics via calls to ApplyForce() after they have been created. The player's teapot is moved under physics control as well - applying forces when the game logic sees input commands from the mouse and keyboard.

      So why choose one over the other? For Rez, moving the AI teapots kinematically was easier for him since he wanted a fine degree of control over where they moved and how they turned to aim. The players teapot and the cannonballs were much easier to code with the physics system in complete control. It was also so readers could see both examples.

      Many games do something similar, since it can be beneficial to have a fine degree of control over actor movement so that animations can synch up perfectly with the environment. A great example of this is when a player actor in a 3rd person game climbs a ladder. The game is just running an animation of the player climbing, and the physics system is just being informed where the player is during the climb. This allows the players hands and feet to be in perfect contact with the ladder.

      If you tried to do something like that under perfect physics control, it wouldn't work - the player actor would like be moving slightly all the time as the game code attempted to perfectly balance the forces acting to move the player up or down and keep them right on the ladder. And forget it if something gets dropped on the players head from above!

      The DISABLE_DEACTIVATION flag is a Bullet Physics thing that must be set when an object is under kinematic control - this just tells the physics system to keep the object in scope for all physics and dynamics calculations. Since you are moving it every frame and positioning it exactly, Bullet can't know when the object is still "in motion" so to speak because you could change it any time.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Thanks again Mike that answered my question perfectly
      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
    • You are very welcome.
      Mr.Mike
      Author, Programmer, Brewer, Patriot