BEPUphysics

If I have to teleport all dynamic and static objects in BEPU Physics (to avoid floating point imprecisions), will I have to be aware of certain problems? For example does teleporting create infinite forces? Will the inner state of BEPU Physics change, e.g. will previous collisions be invalid?

Directly setting entity.Position doesn't change velocity, it just immediately and discontinuously poofs the entity over to a new spot- no infinite forces to worry about.

Collisions are all relative, so they should still be valid so long as everything moves together.

Off the top of my head, the worst thing that will happen is that setting entity.Position will wake the entity up. When dealing with a few thousand sleeping objects, this could be painful for a few seconds after a teleport.

This is one of those areas where the <v2 API tries to be 'helpful' and 'automatic' but ends up getting in the way during more advanced usages. You'll probably want to bypass the Position property and either just make the internal position field public or write some other non-waking position setter.

Ah, good to know. For entities it was quite easy to add an additional method Teleport(). What about a StaticMesh instance? Would I have to set its WorldTransform property? That in turn would trigger recalculations of the BoundingBoxes for each node in its MeshBoundingBoxTree and I guess that I can't avoid that unless I rewrite the MeshBoundingBoxTree to store relative BoundingBox values, can I?
Early optimisation is the root of all evil but I can imagine this to become a real problem for my application because of several hundreds of Static Meshes that need to be teleported every now and then. I wonder how PhysX is doing that.

Will BEPU Physics v2.0 behave similarly?

It would probably be wise to use the InstancedMesh instead of the StaticMesh. The InstancedMesh's tree is stored in shape-local space, so transforming it in world space has no overhead.

InstancedMesh does, however, cost ever so slightly more in collision detection. It has to compute the bounding box of colliders in the shape local space. My guess is this probably won't be noticeable.

For v2, while it's not set in stone yet, I'm leaning towards abandoning world space hierarchies for collidables. The distinction between MobileMesh, StaticMesh, and InstancedMesh would mostly go away, and the CompoundCollidable would store its hierarchy in shape local space. That would eliminate any refit cost associated with moving the object in world space.

InstancedMesh? Aweseome! I'm curious when I will stumble upon a real limitation of your engine. So far I'm really impressed even by the design of BEPU Physics. May I ask how old you are? Did you develop other physics engines before?

Note: If you tell me that you're just 20 years old, I might get depressed.

I'm curious when I will stumble upon a real limitation of your engine.

There are definitely quite a few weird ones in there- hopefully v2 will be out before you run into them

May I ask how old you are? Did you develop other physics engines before?

28, and it depends how you count them! The v1.4.X era BEPUphysics is really the third major iteration/mostlyrewrite of the engine. Public versions of BEPUphysics before v0.16.0 were the second iteration. The first iteration was actually in java, written back in 2005-2006, and it was... not very good.

Fourth time's the charm.

28? Impressive! Keep up the good work!