Performance questions regarding raycasts and static bodies

[MrOnlineCoder]

Hi, as always, greatly enjoying Jolt, and got a few generic questions, would appreciate any answers or hints.

1. I am interested in performing a raycast and getting the resulting body only, if any. I am using NarrowPhaseQuery::CastRay to do that, but I am a bit confused - as it's named "NarrowPhaseQuery" - does it skip the broadphase at all and therefore makes it an expensive operation, or it's actually using it to build the list of possible colliders for the ray and then uses the actual narrow phase structures to perform the ray cast on them?

2. Do I understand correctly that BroadphaseQuery::CastRay will ignore actual collision shapes and only consider AABBs of bodies, leveraging the quadtree? Which means that if I am only interested in finding the body which ray hits, without detecting the actual face it hits - I can use broad phase query ray casts, assuming I can ignore possible imprecisions when body is not a perfect box-like object?

3. Is there a specific reason why BroadphaseQuery::CastRay does only provide an overload with collector as an argument, without a variant of getting the RayCastResult directly like the NarrowPhaseQuery::CastRay?

4. In general, what affects the performance of raycasts and is there way to estimate my "raycast budget", aside from accounting for ray length? Does it's time complexity grows as the bodies are added to the system, or their size matters? What would be better, a hundred raycasts of short ray length or ten raycasts of longer ray lengths?

5. How do I efficiently simulate worlds with geometry rich environments, but when heightmap collision cannot be used - like multilayered dungeons or buildings with many floors and rooms? Do I create a body for every wall, floor and static object using simple collider shapes like box or sphere, or should I join them together in a 3D modelling software and make one big mesh and apply mesh/triangle shape to it? As I understand, Jolt is capable of optimizing collisions with static bodies, but is there a specific limit where I should think about splitting the geometry and using streaming or multiple physics systems?

Thanks in advance!

[jrouwe]

I am a bit confused - as it's named "NarrowPhaseQuery" - does it skip the broadphase at all and therefore makes it an expensive operation, or it's actually using it to build the list of possible colliders for the ray and then uses the actual narrow phase structures to perform the ray cast on them?

No narrow phase query does a broad phase check before a narrow phase check. I couldn't come up with a better name. There is BroadPhaseQuery which only checks against the broadphase and I found BroadAndNarrowPhaseQuery a bit long.

Do I understand correctly that BroadphaseQuery::CastRay will ignore actual collision shapes and only consider AABBs of bodies, leveraging the quadtree? Which means that if I am only interested in finding the body which ray hits, without detecting the actual face it hits - I can use broad phase query ray casts, assuming I can ignore possible imprecisions when body is not a perfect box-like object?

Correct.

Is there a specific reason why BroadphaseQuery::CastRay does only provide an overload with collector as an argument, without a variant of getting the RayCastResult directly like the NarrowPhaseQuery::CastRay?

Not really. The CastRay with RayCastResult implementation is quite limited and I'm tempted to remove it. The only reason it still exists is because it offers a faster ray vs mesh implementation (SIMD style). For the broadphase there is no such advantage.

In general, what affects the performance of raycasts and is there way to estimate my "raycast budget", aside from accounting for ray length? Does it's time complexity grows as the bodies are added to the system, or their size matters? What would be better, a hundred raycasts of short ray length or ten raycasts of longer ray lengths?

The cost of ray casts scales with the number of bodies and the number of triangles it encounters. Long rays tend to hit more bodies than short rays, so they tend to be more expensive. A ClosestHitCollisionCollector is faster than an AllHitCollisionCollector because the ray casts loosely sort bodies/triangles they visit and allow for early outs. If you take a long ray cast and divide it in 10 shorter ray casts then I would expect those short ray casts to be more expensive because you will be visiting the same body multiple times. Other than that there's not much I can say about it as it really depends on the configuration of those rays and the bodies they're hitting.

How do I efficiently simulate worlds with geometry rich environments, but when heightmap collision cannot be used - like multilayered dungeons or buildings with many floors and rooms? Do I create a body for every wall, floor and static object using simple collider shapes like box or sphere, or should I join them together in a 3D modelling software and make one big mesh and apply mesh/triangle shape to it? As I understand, Jolt is capable of optimizing collisions with static bodies, but is there a specific limit where I should think about splitting the geometry and using streaming or multiple physics systems?

In general I would say that a few bodies with a mesh shape is probably more efficient than many bodies with simple convex shapes. If you want to use simple convex shapes (e.g. because you want your walls to be solid) then combine them into static compound shapes to reduce the number of bodies to a couple of bodies per room. Again, these things really depend on what you're doing with them so you'd need to profile.

[MrOnlineCoder]

Thank you for detailed response!

[MrOnlineCoder]

A quick followup I've got after re-reading your answer.

that a few bodies with a mesh shape is probably more efficient than many bodies with simple convex shapes

Am I mistaken, but mesh shapes do have some limit of triangles it can support at once? It just seems for me counter-intuitive that one big mesh shape that takes into account individual triangles is more efficient than many primitive box or spheres. Is this really because of efficiency of mesh collision algorithm or/and because a larger amount of bodies in the system imposes bigger overhead computationally than just one single body with a complex collision shape?

[jrouwe]

Am I mistaken, but mesh shapes do have some limit of triangles it can support at once?

Yes it has but it's more than 100 million triangles, which is far more than anyone should use.

It just seems for me counter-intuitive that one big mesh shape that takes into account individual triangles is more efficient than many primitive box or spheres.

As said, you would need to measure for your particular case, but a MeshShape is a packed structure. In general this means the collision check runs in a tight loop that does less branching / cache misses than a collection of convex objects would.