Bug / Crash Obi7 | Ropes make fluid sim from 3ms to 30ms

[spikebor]

As shown in the video:
20 softbodies + pool = 5ms.
but 2 ropes + pool = 30ms 
So I think this is a bug.
package: https://drive.google.com/file/d/120oZvq9...sp=sharing
Note that I do not pack the [Graphy] into the package.
scene: Assets/Spike/Scenes/Test OBI.unity

This maybe because I enabled all the constraints there is in the solver, making the simulation more complex than needed.
I know there is a recommend on the website that you should disable all the constraints you don't use to save performance, but to make use of
all the Obi actors, let them interact with each other, shouldn't we have to have a Solver with all the constraints On?
I plan to make a game world with only one Solver, and as my Player run around, I'll add / remove actors into that one Solver as they go into near Player range.
Is this a good setup?
If there is more good practices to setup game world with Obi world, pls tell me, thanks!

[josemendez]

This is likely due to your ropes having surface collisions enabled. Surface collisions are considerably costlier than regular, particle-based collisions as they require an iterative convex optimization problem per contact, and if submerged in fluid then the cost will skyrocket due to the amount of contacts.

Reduce the amount of surface collision iterations in the ObiSolver, that might help a bit. However for the case of ropes submerged in fluid, the preferred solution would be to disable surface collisions entirely and increase rope resolution instead.

I know there is a recommend on the website that you should disable all the constraints you don't use to save performance, but to make use of
all the Obi actors, let them interact with each other, shouldn't we have to have a Solver with all the constraints On?

If you have actors of all types (ropes, rods, bones, cloth, softbodies, fluid) and they all collide with each other and colliders, then you need to enable all constraint types, there’s no way around that.

[spikebor]

This is likely due to your ropes having surface collisions enabled. Surface collisions are considerably costlier than regular, particle-based collisions as they require an iterative convex optimization problem per contact, and if submerged in fluid then the cost will skyrocket due to the amount of contacts.

Reduce the amount of surface collision iterations in the ObiSolver, that might help a bit. However for the case of ropes submerged in fluid, the preferred solution would be to disable surface collisions entirely and increase rope resolution instead.


If you have actors of all types (ropes, rods, bones, cloth, softbodies, fluid) and they all collide with each other and colliders, then you need to enable all constraint types, there’s no way around that.

Ahhh, the surface collisions look so good on paper, but are problematic in a chaotic game world where anything can happen like ropes dropping into water.
Anyway, are we close for the next batch of new updates? I wanna try that triplanar mapping for lava hehe.

[josemendez]

Ahhh, the surface collisions look so good on paper, but are problematic in a chaotic game world where anything can happen like ropes dropping into water.
Anyway, are we close for the next batch of new updates? I wanna try that triplanar mapping for lava hehe.

Surface collisions are meant to reduce the amount of particles while keeping good collision detection. However a GPU can just go crazy on the amount of particles, so surface collisions are less useful there compared to a CPU. Also, they’re an iterative process, and GPUs tend to have less powerful cores - although they have *a lot more* cores than a CPU. They still have some use cases on a GPU, but yours is certainly not a good fit for them.

Triplanar mapping advection is available since Monday, I haven’t announced it yet since I havent had time to write documentation for it. If you redownload the assets using the same links you already have, you’ll see new parameters in ObiSolver and ObiFluidRenderingPass, related to texture advection.

Will hopefully be able to document it before the end of this week