Understand Body and BodyInterface logic

[amerkoleci]

Hi,
I'm integrating Jolt into my engine (https://github.com/amerkoleci/alimer/blob/main/Source/Alimer/Physics/Jolt/JoltPhysicsBackend.cpp) and I was wondering I can call method directly on Body (SetAngularVelocity, AddForce etc) or when should I go throught BodyInterface?

I saw there is also GetBodyInterfaceNoLock, GetBodyLockInterface.

Can you help me understand how to proceed?

Sorry if the question was already asked, I tried to search the "Discusssions" but didn't find anything related to this question

Thank you for your time
Amer

[jrouwe]

Using BodyInterface is the safe way and will always work but using functions on Body directly can be faster as it saves the lookup from BodyID to Body.

The thing to keep in mind is that Body doesn't know which PhysicsSystem it is part of, which means it cannot wake up if it is sleeping and it cannot notify the broad phase of changes to the bounding box.

So e.g. calling Body::SetLinearVelocity(some non zero vector) while the body is sleeping, you end up with a sleeping body that has velocity. This is illegal (and should assert during the sim). If you search through Body.h for BodyInterface, I think I have documented all calls on Body that have gotchas that make it better to use the BodyInterface version instead.

[jrouwe]

And about this one:

I saw there is also GetBodyInterfaceNoLock, GetBodyLockInterface.

If you use Jolt from multiple threads at the same time, always use GetBodyLockInterface. If you access Jolt from only a single thread then use GetBodyInterfaceNoLock (it's faster).

[AnuraDev]

just to clarify

If you access Jolt from only a single thread
this means the thread from which the simulation is ticked (Update function on PhysicsSystem is called)?

the point of question is, if i do my logic inside the simulation thread i can use no lock interface but if have some code which runs in another thread i will use the lock interface. this is the correct way to interact with the engine? OR if there is ANY cases of interacting with jolt from multiple threads (even a rare one) you should always (and everywhere) use the locked interface even in the same thread from which jolt is run?

[jrouwe]

the point of question is, if i do my logic inside the simulation thread i can use no lock interface but if have some code which runs in another thread i will use the lock interface.

Correct, if one thread can be reading while another one is writing you always need to use the locking interface on both threads.

You can see the locking interface as a single read/write mutex. It's not implemented that way but as a mental model to decide when you should use the locking/non-locking versions it should work. E.g.:

BodyInterface::SetPosition(...)
{
  if (locking interface) lock physics mutex for write
  set body position
  if (locking interface) unlock physics mutex for write
}

NarrowPhaseQuery::CastRay(...)
{
  if (locking interface) lock physics mutex for read
  do ray cast
  if (locking interface) unlock physics mutex for read
}

PhysicsSystem::Update(...)
{
  // unconditional lock
  lock physics mutex for write
  simulate the world
  unlock physics mutex for write
}

So if you call SetPosition on one thread with the locking interface while calling CastRay with the non-locking interface on another thread, you have a race condition as the position could be halfway updated when the raycast reads the body. The only way to make it safe is to use a locking version on both threads.

If you call CastRay on 2 threads with the non-locking interface, it is safe because a ray cast only reads and doesn't write.

If you call CastRay with the non-locking interface and it can overlap with Update then again we have a race condition as Update modifies bodies that CastRay may be reading from.

If you call SetPosition from 2 threads both with the locking interface, it is safe as both calls lock the mutex, so the operation is serialized.

OR if there is ANY cases of interacting with jolt from multiple threads (even a rare one) you should always (and everywhere) use the locked interface even in the same thread from which jolt is run?

I don't really see the difference between the first statement.

[AnuraDev]

ok thanks for the good explanation! so basically you keep it all in single thread (you may build your own constructs on top to allow operations from multiple threads) or you need to use the locking interface in all cases (with nuances, but it becomes error prone)
overall makes sense.

btw another theoretical question about memory alignment/writing/tearing how do vectors (Vec3/4) behave usually or it's undefined behavior? in the sense most processors nowadays are able to write atomically 64bits, so technically Vec3 could be updated in 2 atomic operations (in case of floats) xy and zw. but in case of jolt it's kind a not really good cause y is height (usually) if xy would be horizontal plane it would be better (but you could do everything "rotated" as suggested to make z the up axis). and also good thing about physics is, it always move in small increments so even the tearing of vec3 wouldn't be too problematic usually. but i guess it's "undefined behavior" due to various optimizations and code/algorithms are not being tailored for that (cause it's basically an overhead to keep all the writes in that ordered way)

[jrouwe]

btw another theoretical question about memory alignment/writing/tearing how do vectors (Vec3/4) behave usually or it's undefined behavior?

I don't know the rules, but I'd say it's platform specific and it's unlikely that you'll get a consistent position. The broadphase is making the assumption that the individual floats are read atomically. Operations on bounding boxes will only ever make the box bigger, so it doesn't matter in which order x y z and w get updated / read.