Softbody gets stuck inside mesh collider

[michele_lf]

Hello!

I am trying to simulate tyres being thrown at objects. The issue is that on certain meshes, possibly smaller ones (if I use a large cube set up as a wall for instance I don't seem to have this issue) the tyre gets 'stuck' inside the collider.

This only seems to happen with mesh colliders and not box colliders for instance.

I am using ObiActor.AddForce(force, ForceMode.Impulse) to imprint velocity on the tyre object in the direction I need.

   

This first happened as I was trying to make the tyre 'stiffer' and upped the 'shape matching' iterations value on the solver. If I go from 1 to 5 for instance, I thinkm I get more stiffness but my fps gets really low.

My understanding is that I have to increase the number of substeps in the obi solver to get a 'stiffer' result but again I get much lower fps.

I tried compensating b y increasing the unity fixed time step. With a value of 0.05 the tyre is really soft again and still enters the collider. With fixed time step set to 0.02 and 4 substeps the tyre bounces off fine but looks really 'soft'.

Here are my settings

               

is there a combination of settings that would give me what I want? I tried to copy the settings from the deformable barrel sample, the only difference I can see is that the barrels are low poly and have a lot less particles on them.

I have also seen this post about using distance fields. Is that what I should do? If they are better why bother with colliders in the first place? Do we need both?

[josemendez]

Hello!

I am trying to simulate tyres being thrown at objects. The issue is that on certain meshes, possibly smaller ones (if I use a large cube set up as a wall for instance I don't seem to have this issue) the tyre gets 'stuck' inside the collider.

This only seems to happen with mesh colliders and not box colliders for instance.

This is because MeshColliders are "hollow": they have no volume, once an object is pushed trough its surface it won't be projected back outside.
For this reason, Obi implements DistanceFields as a more robust, faster alternative to MeshColliders:

This first happened as I was trying to make the tyre 'stiffer' and upped the 'shape matching' iterations value on the solver. If I go from 1 to 5 for instance, I thinkm I get more stiffness but my fps gets really low.

My understanding is that I have to increase the number of substeps in the obi solver to get a 'stiffer' result but again I get much lower fps.

If you want stiffer constraints, make sure you're using sequential evaluation mode (as opposed to parallel) since that converges much faster (see "Evaluation mode" in http://obi.virtualmethodstudio.com/manua...olver.html). If constraints are not stiff enough even in sequential mode, then you can resort to using more substeps/iterations, but yes that will have an impact on performance.

I have also seen this post about using distance fields. Is that what I should do? If they are better why bother with colliders in the first place? Do we need both?

Yes, both are needed: distance fields consume more memory, cannot be scaled non-uniformly and modifying them at runtime is extremely slow, just to name a few disadvantages. However, they tend to be much more robust than MeshColliders and are also a lot faster when querying distance to a surface, which luckily is all particles need to do.

Distance fields aren't something unique to Obi, they have been used in games for decades, and coexisted with both analytic and mesh-based colliders for a lot of time. Each approach has its own strengths and weaknesses.

kind regards,

[michele_lf]

This is because MeshColliders are "hollow": they have no volume, once an object is pushed trough its surface it won't be projected back outside.
For this reason, Obi implements DistanceFields as a more robust, faster alternative to MeshColliders:


If you want stiffer constraints, make sure you're using sequential evaluation mode (as opposed to parallel) since that converges much faster (see "Evaluation mode" in http://obi.virtualmethodstudio.com/manua...olver.html). If constraints are not stiff enough even in sequential mode, then you can resort to using more substeps/iterations, but yes that will have an impact on performance.



Yes, both are needed: distance fields consume more memory, cannot be scaled non-uniformly and modifying them at runtime is extremely slow, just to name a few disadvantages. However, they tend to be much more robust than MeshColliders and are also a lot faster when querying distance to a surface, which luckily is all particles need to do.

Distance fields aren't something unique to Obi, they have been used in games for decades, and coexisted with both analytic and mesh-based colliders for a lot of time. Each approach has its own strengths and weaknesses.

kind regards,

Thank you so much for replying so quickly! It all makes sense.

Using sequential instead of parallel made the softbody a lot stiffer immediately.

I also realised I hadn't disabled the jobs debugger and the saftey checks, which improved performance.

I will try the distance fields as soon as possible. It feels like it takes a combination of parameters for the desired result.