Triggers & Proxy volumes that can potentially move frequently - Static or Kinematic?

[Frooxius]

Hello, I got another question if you don't mind!

One of the common uses of physics engine for my project is having colliders/bodies that either serve as triggers (there's no solver response - everything passes through, but events are relayed) or proxy volumes that serve as targets for raycasts and convex sweeps, but also do not contribute to any collision response. Many of these can also be moving every frame as well.

I'm wondering what's the best way to approach these with BEPUv2. I've looked at some Demos, I noticed the Kinematic bodies in general seem to calculate the exact speed needed to move them to the desired position. This makes sense as they can transfer their velocity to other dynamic bodies appropriately, but for triggers and proxy volumes that's unnecessary.

It seems like using Statics is more suitable in this case for those. But given that many of them will move every frame, it seems like it might not be best either? From what I found they currently use the same mechanism as dynamic bodies for broadphase, but that can be changed in the future based on the assumption that they do not move often, so I'm not sure if there's going to be some gotcha.

So my question is essentially that - is it a good idea to use Statics for Triggers and proxy volumes, with assumption that some of them (but not all) will be moving frequently (every frame) while others will remain stationary? Or would using Kinematic bodies here be better, even if I'm just updating their poses, rather than using velocities to drive them to those poses.

If so, is there also a good way to efficiently update their poses from external source? I found in FountainStressTestDemo and other places that GetDescription and ApplyDescription are used, but I'm not sure if this is most efficient, especially if I have a large batch of new poses.

From my experimenting it seems that every ApplyDescription updates the broadphase and other things and I was wondering if there's way to assign a bunch of new poses and then do one broadphase update or if doing it Static body by static body is as good.

By the way, I saw the CollisionQueryDemo too, but that one would be less efficient in my usecase I believe, since a lot of the Triggers might be idle (not moving at all) and I don't want them tested every frame explicitly.

[RossNordby]

(oops, I thought I already responded to this!)

A couple of considerations:

1. While the static optimizations haven't been pushed as far as they could be yet, it'll happen eventually, and frequently moving statics will not play well with it.
2. Statics cannot detect collisions with other statics or sleeping bodies. They exist within the same tree, and that tree is not tested against itself for collision detection.

So if you expect a trigger to move a lot, or if you want it to detect statics or inactive bodies, it should be a kinematic. Probably with its sleep threshold set to a negative value to guarantee it never sleeps, unless you are comfortable manually waking it up as needed.

The velocity can remain unchanged since it's not generating constraints, as you mentioned.

If so, is there also a good way to efficiently update their poses from external source?

You can directly set the pose. The easiest way to do that would be to make a BodyReference (Simulation.Bodies.GetBodyReference(handle)), which has a bunch of convenience properties and functions. They're mostly lookups that return direct references to the underlying memory unless otherwise noted, so they're pretty cheap. It won't update the broad phase bounds, but any active bodies will have their bounds updated in the next timestep anyway.

ApplyDescription and similar functions are heavier and useful when you want to handle certain kinds of transitions. For example, setting BodyReference.LocalInertia to all zeroes will not convert a dynamic into a kinematic by itself (or even wake the body up) since it's just a direct memory write, and there are other flags that need to be set to do the transition correctly. ApplyDescription and SetLocalInertia, by contrast, do the extra work to handle transitions when required.

By the way, I saw the CollisionQueryDemo too, but that one would be less efficient in my usecase I believe, since a lot of the Triggers might be idle (not moving at all) and I don't want them tested every frame explicitly.

If triggers spend most of their time inactive, then the query model should actually have the advantage. While having extra constraintless bodies is pretty cheap, explicit queries let you choose to do zero work on a frame where the trigger isn't needed without needing to add/remove stuff frequently.

It's hard to say which one would be more efficient ahead of time. If the queries are needed every single frame, using the kinematic listener would probably win. If the queries are needed only 1 out of 10 frames, on-demand queries would probably win. And of course if you've only got a few dozen triggers, then do whatever is easiest since it's fast enough to not matter.

[Frooxius]

Aaah thank you so much, this made a bunch more things click better! I think for my use-case I pretty much need to flip things around.

To give more context, typically there might be hundreds, maybe even thousands of Triggers. Many of them will probably be stationary (e.g. triggering events when player reaches some parts of the map), some of them will move (parts of mobile objects, vehicles and other setups).

They will usually be activated by fewer objects though - the player and some other active bodies. So in BEPU those would be the actual "triggers" that actually detect things, while the ones placed in map would be the result of the query.

It sounds the the non-moving triggers will then be best as Statics. I don't have any Trigger-Static interaction or detection, so that's ideal for this, as it will avoid generating pairs between Triggers and Statics in the first place, only to be excluded.

While the static optimizations haven't been pushed as far as they could be yet, it'll happen eventually, and frequently moving statics will not play well with it.

Ah that's what I figured! Hmm, this makes me a bit unsure what would be best approach for the moving Triggers. I can make those Kinematic and sleep them when they're not moving - I assume if another moving body intersects them, it'll wake them up? Or would I have to handle that myself?

How much overhead is there for generating pairs between bodies where I just return false from all the callbacks in INarrowPhaseCallbacks? (not including the checks themselves of course) There might be potentially lots of those that get rejected, so Statics not generating any such pair between themselves in the first place seem like might perform better, except for the movement part.

It won't update the broad phase bounds, but any active bodies will have their bounds updated in the next timestep anyway.

This makes a lot of sense! So I can update the poses directly for any active bodies and then the timestep will update the broadphase more efficiently for me?

Is there something analogous for the Statics? E.g. I move multiple statics externally and then mark them for updating in the broadphase.

[RossNordby]

I can make those Kinematic and sleep them when they're not moving - I assume if another moving body intersects them, it'll wake them up? Or would I have to handle that myself?

The kinematic won't wake up by itself, but a sleeping kinematic and an awake dynamic will still trigger the narrow phase callbacks. (If a collision constraint was allowed between the sleeping kinematic and awake dynamic, that would wake the kinematic, but that doesn't matter for triggers.)

Notably, since directly setting the pose of a kinematic doesn't wake it up or update its bounds, and sleeping bodies don't get their bounds automatically updated, and because sleeping bodies are in the same tree as statics, a sleeping kinematic is quite similar to a static. I suppose it uses a tiny bit more memory capacity than a static by virtue of having velocity and whatnot, but not bandwidth, since sleeping bodies are not enumerated.

How much overhead is there for generating pairs between bodies where I just return false from all the callbacks in INarrowPhaseCallbacks

Just the broad phase cost- it's usually a relatively small fraction of total simulation time. It could become expensive relative to other phases if there are a much larger number of pair candidates than actual tested pairs or solved constraints, but it would take a pretty big chunk of rejected candidates. Hard to say exactly how bad it would be without testing on a representative distribution.

So I can update the poses directly for any active bodies and then the timestep will update the broadphase more efficiently for me?

Yup.

Is there something analogous for the Statics? E.g. I move multiple statics externally and then mark them for updating in the broadphase.

Not exactly the same, but you can use the StaticReference.UpdateBounds to update the bounds for all the statics that you scoot, and the next timestep's refit/refine on the static tree will adapt to the changes as a part of its usual process.