SoftBody Perfoprmace Hit

[majestik666]

I was playing around with soft bodies today and noticed a quite severe performance hit
on certain occasions, the situations is the following:

- 20 soft body ropes connected together
- some rigid bodies falling on top of them
- the simulation is running inside maya

The first time I play the simulation, the performance is quite slow on certain frames,
I do get stepTime in the order of 300ms.
If I let the simulation play , reset it, and play again, then the stepTime is back to
what I would expect , in the order of 15-20ms.
I did some investigation using the profiler and figured out that the soft body SDF
is where the time is spent (or 95% of it) on these slow frames.

Has anyone noticed this phenomenon ?
I'm wondering if it's related to an array being resized when I have new collisions
(like an slow std::vector resize) which is not reseted to 0 when I rewind hence
having much better performance on the next iterations ?

Here's an extract of the profiler log :
.........Profiling: performDiscreteCollisionDetection (total running time: 238.757 ms) ---
.........0 -- dispatchAllCollisionPairs (99.91 %) :: 238.533 ms / frame (10 calls)
.........1 -- calculateOverlappingPairs (0.01 %) :: 0.019 ms / frame (10 calls)
.........2 -- updateAabbs (0.09 %) :: 0.203 ms / frame (10 calls)
.........Unaccounted: (0.001 %) :: 0.002 ms
............----------------------------------
............Profiling: dispatchAllCollisionPairs (total running time: 238.533 ms) ---
............0 -- processAllOverlappingPairs (100.00 %) :: 238.529 ms / frame (10 calls)
............Unaccounted: (0.002 %) :: 0.004 ms
...............----------------------------------
...............Profiling: processAllOverlappingPairs (total running time: 238.529 ms) ---
...............0 -- btCollisionPairCallback::processOverlap (99.91 %) :: 238.305 ms / frame (3920 calls)
...............Unaccounted: (0.094 %) :: 0.224 ms
..................----------------------------------
..................Profiling: btCollisionPairCallback::processOverlap (total running time: 238.305 ms) ---
..................0 -- btSoftBody::defaultCollisionHandler (99.84 %) :: 237.931 ms / frame (240 calls)
..................Unaccounted: (0.157 %) :: 0.374 ms
.....................----------------------------------
.....................Profiling: btSoftBody::defaultCollisionHandler (total running time: 237.931 ms) ---
.....................0 -- Process (99.88 %) :: 237.646 ms / frame (2142 calls)
.....................Unaccounted: (0.120 %) :: 0.285 ms
........................----------------------------------
........................Profiling: Process (total running time: 237.646 ms) ---
........................0 -- CollideSDF_RS::DoNode (99.90 %) :: 237.418 ms / frame (2142 calls)
........................Unaccounted: (0.096 %) :: 0.228 ms
...........................----------------------------------
...........................Profiling: CollideSDF_RS::DoNode (total running time: 237.418 ms) ---
...........................0 -- SignedDistance (99.35 %) :: 235.881 ms / frame (12800 calls)
...........................Unaccounted: (0.648 %) :: 1.537 ms
..............................----------------------------------
..............................Profiling: SignedDistance (total running time: 235.881 ms) ---
..............................0 -- GJK::Evaluate() (76.35 %) :: 180.086 ms / frame (12800 calls)
..............................Unaccounted: (23.654 %) :: 55.795 ms

The names might not be the exact function names but it gives a good indication of
where time is spent.
I also noticed that the number of overlapping pairs is increasing over time , and it does not
seem to be resized / cleaned when I reset the solver (btHashedOverlappingPairCache::m_overlappingPairArray)
I haven't seen anything special about the handling of it but I wonder if it could be the culprit ?

Cheers !
Francois

[Erwin Coumans]

The performance spike could be due to the garbage collection in the signed distance map.

Are you calling m_softBodyWorldInfo.m_sparsesdf.GarbageCollect(); after each stepSimulation call?
And m_softBodyWorldInfo.m_sparsesdf when resetting the simulation?

Thanks,
Erwin

[majestik666]

hmm didn't know about these

will add that and see if the issue goes away !

Thanks for the info!
Francois

[majestik666]

Finally got around adding the garbage collect and reset of the sparseSDF, but didn't get better results.
Actually now , every time I reset I get the same performance spike which makes me believe more
and more that the sparseSDF grows over time and gets faster as the bodies are contained into
an already allocated sdf...

Will try and take a deeper look into the sdf

Cheers
F