Physics Completely Authorative?

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

    • Physics Completely Authorative?

      Hey Guys,

      So I have been wondering what the best way is to go about with Physics-Transform synchronization, my issue is
      this, if an Actor has a physics component, should the transform be allowed to do anything? The first way I had it hooked up was that if there was a physics component and I tried to move using the transform, there would be a slight gitter, the physics would then resend it's transform and return the transform component to match the physics, but what if I have a physics component, and I wish to override the position of the actor as defined in the actor file, the physics will simply reject the transformation.

      I then set it up so that the transform would update the physics as well, not thinking about the cyclic issue of the transform updating physics, then the physics updating the transform.

      Should I be able to move the actor using transform if a physics is present? If so what should be the best approach (rules set in place), and if not, should I be using a specific event that is only sent at actor creation to position the physics component?
      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
    • Hey mholley,

      Can you not make the physics object and the transform the same? Either through wrapping your transform object in something the physics engine will take, or by creating an interface for your transforms, and then making a physics wrapper that conforms to it (that way non-physics objects can just use a different transform type).

      James
    • I don't know how I would make that work, as all of the physics systems I have used have there own internal transform for their rigid bodies, which I need to sync with my own.
      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
    • Every game needs the ability to teleport game objects, so you definitely need to be able to update your transform. You could certainly do as James suggests and merge the two. You would probably have two different types of physics objects, one that actually went through the physics system and one that didn't. We went down this road while developing the GCC engine but ultimately decided to keep them separate. It muddies up the API for those objects where you just want a simple transform to define where they are. Most of the API functions in PhysicsComponent.h wouldn't apply.

      The final solution was to make the physics system authoritative (it pretty much has to be) and have it sync up with the transform. The transform component doesn't know anything about the physics component, so setting the transform on the transform component of a physical object would cause the snapping you described. Instead, you need to set the transform on the physics component. So your teleport function would probably look like this:

      Source Code

      1. void Teleport(WeakActorPtr pActor, const Vec3& pos)
      2. {
      3. StrongActorPtr pStrongActor = MakeStrongPtr(pActor);
      4. shared_ptr<PhysicsComponent> pPhysicsComponent = MakeStrongPtr(pStrongActor->GetComponent<PhysicsComponent>(PhysicsComponent::g_Name));
      5. if (pPhysicsComponent)
      6. {
      7. pPhysicsComponent->SetPosition(pos);
      8. }
      9. else
      10. {
      11. shared_ptr<TransformComponent> pTransform = MakeStrongPtr(pStrongActor->GetComponent<TransformComponent>(TransformComponent::g_Name));
      12. if (pTransform)
      13. {
      14. pTransform->SetPosition(pos);
      15. }
      16. else
      17. {
      18. GCC_ERROR("No transform?");
      19. return;
      20. }
      21. }
      22. }
      Display All


      It's not totally ideal to search through two components, but since it's really only happen in one place, it's not a big deal. Anything that moves will be driven by the physics system, so you're really just handling the teleportation case.

      -Rez