I am trying to add various dynamic objects of different shapes. For that I am using the MobileMesh Class right now, which makes a lot of problems. I have read a lot of forum threads, that talk about the rubustness of this Meshclass and that the scale is a factor. After increasing the scale of the scene, the result is better, but still not optimal and since it needs a lot of Scaleupdating in various parts, the work is not worth the result.
While simple primitives and compounds of simple primitives are more robust than a MobileMesh, a MobileMesh is still quite robust. If you're experiencing significant problems, it's likely that there's a core problem that needs to be addressed. Scale is indeed one possible factor. Note that you can modify the engine's interpretation of scale- check out
the development fork BEPUphysicsDemos ConfigurationHelper.ApplyScale method to see an example. It's still best to stick within the default scale as that avoids some other oddities and numerical issues, but the engine can handle a big range.
It's important to handle these core issues directly, because simply switching from a MobileMesh to ConvexHulls or something will not truly solve the problem. It might hide it a bit, but it still might crop up here and there.
It might also be that the mesh is confusing the MobileMesh solidity initialization system. Sometimes, numerical issues can make it choose the wrong sidedness when solidity is enabled. Try using another solidity state- Counterclockwise or Clockwise preferably- to see if it improves. It will no longer have a solid volume, but it will run faster (and more robustly if the initializer is getting confused).
Still though, unless a MobileMesh is truly necessary, switching to a simpler representation after addressing any core issues is advisable.
So my Question is, if and how to use convex Hull Shapes or any other solution that might give better results. Is there something like automatic fitting of compound primitive shapes?
ConvexHullShapes will provide a convex wrapping around the mesh's vertices, and if that is sufficient, it's a good option. Simplifying the mesh is a good idea as well because the cost of collision detection with convex hulls is proportional to the number of vertices on the surface of the hull. A single ConvexHull can be an order of magnitude faster than a MobileMesh depending on the data.
Compound shapes can be used to bundle multiple shapes, like convex hull shapes or box shapes, into a single rigid object. There is no automatic primitive fitting for compound shapes. However, if the mesh is split into pieces and each one of those pieces is used to create a convex hull, the resulting compound will be very well fit. An algorithm like
HACD would be great to automate this (I'd like to implement it some time, I just haven't had the time yet- if anyone reading this wants to contribute an implementation, that would be great

).
If possible, using even simpler primitives like boxes and spheres will be even faster. Compounds of these simple shapes will be faster than compounds created from convex hulls created from tons of vertex data.
Here's a general ranking of shapes:
(Most expensive and best fitting)
-MobileMeshShape
-CompoundShape of ConvexHullShapes
-CompoundShape of exotic shapes like WrappedShapes, MinkowskiSumShapes, or TransformableShapes.
-CompoundShape of simple shapes like BoxShape, SphereShape, CylinderShape, etc.
-Single ConvexHullShape
-A single exotic shape like a WrappedShape, MinkowskiSumShape, or TransformableShape.
-Single simple shape like BoxShape, SphereShape, CylinderShape, etc.
(Least expensive and worst fitting)
When the Amount of objects (its the MobileMesh ones) reach a certain amount, the caracter controler out of the characterPlaygroundDemo sample starts to bug around. It starts to feel very laggy like in onlinegames where you get reset to previous positions and set forward because of the latency. Does this have anything to do with me using the multithreaded approach and the character controler not accessing the bufferd states?
If you are using asynchronous updating, that might contribute a little jitter- or even the occasional corrupted state- but that wouldn't explain warping around in a small area. Note that asynchronous updating is a separate concept from internal multithreading. When using asynchronous updating, the engine is running in parallel to other logic which uses information computed by the engine. Internal multithreading means the engine is capable of using threads to speed up computation. If you aren't doing asynchronous access and you aren't doing illegal actions from within immediate events executed on the internal threads, threading is not the source.
The CharacterController itself runs within the engine, so even if it was asynchronously updating, the CharacterController doesn't know or care as all of its actions take place within the physics thread(s). External control over movement commands would still need to be properly synchronized, of course.
In the absence of any threading oddities, my guess would be some bad initialization in the mobile meshes. If the mesh has bad geometry or just manages to confuse the solidity sidedness computation, things could get weird. Inconsistent contact generation could produce the mentioned effects. Setting a nonsolid sidedness as mentioned earlier in this post would be a good diagnostic. Scale issues can also cause some inconsistencies, but probably not of this particular kind.
However, scale/solidity issues should be just as bad with a single object as they are with 500 objects; they are not based on performance. If the problem seems to truly be linked to performance to the object count, something stranger might be going on.
if the CharacterControler falls too fast, it manages to break through static meshes. Any solution?
The CharacterController body should have its PositionUpdateMode set to Continuous by default by the constructor, so it shouldn't be able to fly through objects. I suspect this is related to the previous issues (sidedness confusion or scale issues are probable).
At last I just wanted to say how much I like the engine: A LOT!
