Noob questions

[MasterDrake]

Hi, I'm very new to physics system and while I was searching for some middleware I found this, alongside bullet and PhysX.
I have some general and specific questions.
Hope that somebody will have my same doubts and reading this discussion will help him as well.

Well, my doubts are:

1. Who's in charge? The GameLogic/InputSystem, the physics system, or the rendering system?
   What happens when I press WASD, should I add a force/impulse F = dir * speed * deltaTime to my body and see what happens?
   That means that I no longer need to have positions and such from my game logic, but I have to grab them from their body's settings?

2. How do I synchronize the physics system and rendering system, especially when it comes to animations?
   A simple example would be Spiderman's Dr.Octopus. Let's say that mouse buttons control his robotic arms, how can I synchronize the animation of a punch and the physics system in order to stop if the arms touch another body and apply force to it?
   Same for my moving, jumping, shooting, and crouching character. How can a bullet fly past me if I'm not in bind pose?

3. Speaking of characters, after reading the docs, integration example and samples, I'm confused about what I should use, between a game Character and Ragdoll. A game Character seems the default choice for games and (main) players because of the fast collision checks but it's not as accurate as Ragdoll, which can't even stand on its own so It makes me think it's only for (post)death animation.
   Which is a shame because it's kinda exactly what I'm looking for :/. Knowing exactly which part of the body was hit is super helpful.

4. I assume CollisionCollectors are the way you query the scene in Jolt, right? Using NarrowPhaseQuery ? I can't see a collideBody(playerBodyID), am I thinking this backward/wrong?

5. About userdata, I was thinking about attaching a flecs entityID(which is an int in the end) to the Body and I only found: uint64 mUserData = 0;.
   I'm used to void* userdata, so I was wondering if this is another way to do the same or if I'm wrong.
   uint64 should ring me some bells, like a pointer size in x64, right?

6. About Body, I noticed that there's no const char* debugName for it, so I was wondering if it's useless adding it because you didn't have the need to add it.

Thanks and sorry to bother you with such questions!

[jrouwe]

Hello,

(1) This is a huge subject and not easy to give a short answer to. The easy part of the answer is that the rendering engine is not responsible for any movement at all (it renders stuff wherever it is). The rest of the responsibility is mixed between the game logic and the physics engine:

• Anything that needs to bounce is a Dynamic body and you'd read the position of the body every frame and put it in your game object (so yes it's ok to store the positions 2x, there will be many game objects that don't have a physics body).
• Anything that needs very tight game logic control (e.g. an elevator) you would handle in your game object, and if that game object needs presence in the physics world so that other bodies can bounce off, you'd create a Kinematic body and move it in the update of the game object using BodyInterface::MoveKinematic.

You almost never move an object around by applying forces/impulses.

I'd suggest reading a book about it like Game Engine Architecture (note I haven't read this myself but the TOC suggests that the subject of integrating a physics engine is covered and it seems to be a popular book).

(2) If something is controlled by an animation, you'd normally use a Kinematic object as mentioned above to ensure that the physics body follows the animation exactly (see sample KinematicRigTest). If you want the arm to stop when it hits collision, you could make a part of the arm driven by motors (see sample PoweredRigTest). Finally, you can make your arm consist of normal Dynamic bodies and still use BodyInterface::MoveKinematic to make it follow the animation, this gets you a mix: less physically correct but following the animation better. If you do this last thing, make sure gravity doesn't affect the body by SetGravityFactor(0).

(3) You normally use both a Ragdoll and a CharacterVirtual (Character is the cheap version, I'd recommend using CharacterVirtual for the player). The Ragdoll can also be active if the player is alive and at that time it can be driven as described in (2). Ragdolls usually have very simplified collision volumes so that the simulation is fast. For bullets, this representation is sometimes not accurate enough, which is why some games have a 3rd set of collision volumes that is only used for hit detection and not for simulation (if no dynamic objects can collide with a body, you can make it Static and update the positions using BodyInterface::SetPosition). The layer system (see Layer.h for an example) allows you to decide what collides with what, so you can make your CharacterVirtual collide with the world but not with the Ragdoll or the high detail collision volumes of the same character. Only your bullet raycasts would collide with the high detail collision volumes.

(4) The CharacterVirtual class internally handles all collision detection for your player, so you don't need to write the low level collision detection code. In Jolt you don't collide a body against the world, you collide a shape (the collision volume) against the world. You need a shape and a transform matrix, conveniently combined in Body::GetTransformedShape(). From that you can use NarrowPhaseQuery::CollideShape providing the shape and center of mass transform from your TransformedShape.

(5) uint64 = unsigned 64-bit integer = same size as a pointer. If you need a pointer do reinterpret_cast<void *>(mUserData).

(6) If you need a debug name I'd suggest putting it in mUserData (as a char *) or putting it in the object that mUserData points to. I recently took the debug name out because it was eating too much memory.

Regards,

Jorrit.