Kinematic mobile mesh vs instanced mesh

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
Frooxius
Posts: 8
Joined: Tue Aug 16, 2016 4:01 am

Kinematic mobile mesh vs instanced mesh

Post by Frooxius » Fri Feb 10, 2017 9:46 am

Hello!

I have another question. I have a scenario where I'm using a simple entity (like a box or sphere) as a trigger for detecting other objects that enter it (firing a collision event). All of them are kinematic, there's no dynamics involved in this.

This works fine when I move another simple entity into its volume, but not when I position an InstancedMesh into it. However it works the other way around, if I move the trigger into InstancedMesh, it fires the collision event.

What would be the best way to make it work both ways? Should I use mobile mesh instead (keeping it kinematic and setting a group rule so it only solves overlaps with entities in the "trigger" group and not with each other) or is there a simpler way to trigger the update when moving the InstancedMesh?

Are there any overheads of kinematic mobile mesh (with collision rule enabling it selectively with a few other collidables) that I should be aware of compared to using InstancedMesh?

Norbo
Site Admin
Posts: 4424
Joined: Tue Jul 04, 2006 4:45 am

Re: Kinematic mobile mesh vs instanced mesh

Post by Norbo » Fri Feb 10, 2017 9:03 pm

The lack of event on instanced mesh movement is likely caused by the trigger object being inactive. Since static objects like the InstancedMesh are always 'inactive', the broadphase sees both objects as inactive and no pair is emitted.

One quick workaround for this is to just set the triggerEntity.ActivityInformation.IsAlwaysActive = true, though this will pay the price of that object being updated every frame of course. A slightly more tedious workaround would be to query the broadphase for nearby entities and wake them all up manually when the InstancedMesh is moved.

Using mobile meshes is indeed another option, since teleporting them results in temporary activity. (Any velocity will make them active too.) Given identical collision modes, instanced and mobile meshes should perform very similarly. The only significant difference is that mobile meshes create a set of hull vertices around the mesh that are used to calculate the bounding box when it is active. For objects that have a lot of concavity, the bounding box update for a mobile mesh will tend to be faster. If these meshes are moved very frequently, mobile meshes might be the right option. If they tend to stay static almost always, InstancedMesh might be a better fit since they don't clutter the entity listings with an almost-always-inactive object.

Frooxius
Posts: 8
Joined: Tue Aug 16, 2016 4:01 am

Re: Kinematic mobile mesh vs instanced mesh

Post by Frooxius » Thu Feb 16, 2017 11:40 am

Thank you very much, this helps me understand it a lot better. I was wondering if there was any kind of event which triggered the recalculation before, but couldn't find it.

What I ended up doing for now is making the IsActive flag assignable for InstancedMesh and I set it to true anytime the entity is moved (it's always moved by the same "glue" code, so I don't have to worry about someone moving it and not setting the flag) and clearing afterwards.

The instanced meshes won't usually be used anyway, since they're performance hog for most things, but I wanted the behavior to be consistent (so it doesn't matter which one of them is moved).

It's also good to know about the hull vertices used for bounding box recalculation for the mobile meshes.

Thanks again!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests