Some issues and questions.

[LogaNRV]

Hi, thanks for the fast answers.

So, I was thinking that I have tried the Burst backend, but in reality I didn't have it correctly configured (I kind of missed the warning in the solver).
I was missing the Jobs preview package. The Collections preview was there but hidden by the package manager (so it wasn't showing me any preview package).
I compiled a build with ILCPP and Burst and it worked!
But after that I created a build with Oni and ILCPP and it also worked
So I assume that installing the Jobs package did the trick.. don't know if the idea was to have it installed also for the Oni backend?
The other small thing that I changed between yesterday and today, is that I disabled safety checks in the Unity Burst menu.

Performance seems to be equal using both backends, the build runs at constant 144 FPS, but is just one cloth and the scene is not that complex.
The Burst build seemed to stutter a little at the start the first time, but in subsequent runs both seems to start equally fast.

Increasing cloth particle radius, and/or collider thickness (see: http://obi.virtualmethodstudio.com/tutor...sions.html) can fix this most of the time. Keep in mind that mesh resolution is what it is, and that triangles can't be bent, so triangles might clip trough each other if cloth resolution is coarse enough.

I will try playing with the particle radius (i was already using the collider thickness), but it also seems your next update is going to solve most of these problems

"Substep Unity physics" does exactly what the label says: it calls Physics.Simulate() more than once per Fixed Update(). Substepping is implemented in many physics engines to increase simulation accuracy. So if you have time-dependent logic in your game code, you should take this into account.

It's generally not transparent. Unity will call FixedUpdate() as usual regardless of anyone calling Physics.Simulate() to substep physics, so you should take this into account and adjust your Time.fixedDeltaTime accordingly. How to do this depends on what exactly you're doing. Unity's support for substepping is unfortunately not great (actually the entire engine seems to lack basic functionality), so there's not much we can do to improve in this department. See: https://docs.unity3d.com/ScriptReference...ulate.html

Ok, sounds that at least I should divide my delta time, in the fixed updates, by the number of substeps.

"Substep Unity physics" is only required if your cloth requires two-way coupling (interaction) with rigidbodies: collisions or dynamic attachments, where the rigidbody is supposed to react to the cloth. Quote from the manual:

http://obi.virtualmethodstudio.com/tutor...aters.html

An example of two-way coupling would be a soccer net, where the ball needs to be "catched" by the net. With no two-way coupling, the net would still react to the ball, but the ball would continue moving as if there was no net stopping it, because it is unaware of the net simulation (looks quite weird, this is what Unity's own cloth component does). When two-way coupling is used, we need Unity to update the ball's rigidbody physics in sync with Obi's physics, so that both the net and the ball can accurately measure velocities (and forces) for each other. This is what "substep Unity physics" does: it steps both engines in unison, to ensure accurate force exchanges between rigidbodies and cloth.

If you're only using simple colliders or you don't care about rigidbodies reacting to the cloth, there is no need at all to substep Unity's physics. You will also save quite some performance by disabling it.

Well I don't require (yet) a rigidbody attached to a cloth. But without enabling "Substep Unity physics" I am using "non kinematic to particles" characters and game elements (like balls).
And they react to the cloth (slowing down or been destabilized by the cloth), maybe this is not physically correct, but from a gameplay viewpoint is good enough
Would like to know your opinion about this..

PD: your gravity is -16 m/s2 (!) does your game take place in Jupiter?

Hehe I like more arcade like physics and feelings in my gameplay, more than going the true simulation way.
Think more of Mario like platformers, than Little Big Planet floaty jumps.
I wouldn't be surprised that something like Fall Guys use a gravity of 15 or greater, to be honest

Regards.