Some issues and questions.

[LogaNRV]

Hi, new Obi-suite user here.

I started doing experiments with the cloth component, adding a simple floating cloth to a test scene, where I have a lot of physics elements and a character controller mostly based on physics. Something like a mini "Fall Guys" level.
My first issue is that the moment that I add the cloth to the scene, the ILCPP build stops working, the screen stays black after the Unity logo and then crashes after some seconds.
In the editor and with normal builds all works well.
Also, with only the solver active (and the cloth disabled) the ILCPP build works correctly. Is only the moment that I enable the cloth gameobject (also when the OniCollisionWorld object appears), that it stops working.

This is a very simple cloth component, done with a blueprint from the demo assets (Cloth sheet) and all default values.
My solver is configured like this:

   

And I'm working with Unity 2019.3.15f1, Windows 7 64 bits, last Obi cloth version.

My second question would be how to configure the cloth to avoid my character going visually through it. I increased the fixed updater substeps to 4, the max depenetration to 40, avoided using interpolation and used elements "non kinematic to particles", and got a very nice cloth, without any visual glitches most of the time. I also played with anisotropy set to 1, but didn't see much difference. My characters right now are capsules and the moving elements are mostly spheres, so there are no pointy edges, but maybe you have some extra advice to configuring a cloth for this. I assume that a mesh with a lot of points also helps.

Another question.. when I enable "Substep Unity Physics" in the solver, my own code kind of breaks. For example, instead of the player correctly "attaching" to moving platforms, it now jump and stumble over them. My own "force element" scripts seems to apply more force to the player than before, like if they were called more times per second, but with the same old delta time. I was expecting that enabling this option was kind of "transparent" to the rest of the code, but I assume is not, so I would like to know what steps I should follow or how I prepare my code to use it.
Also.. I have been using the "fixed updater substeps" set to 4, without enabling "Substep Unity Physics", and all seems to work correctly.. is this ok?

Regards.

[josemendez]

Hi, new Obi-suite user here.

Hi there!

My first issue is that the moment that I add the cloth to the scene, the ILCPP build stops working, the screen stays black after the Unity logo and then crashes after some seconds.

I've been unable to reproduce this. I take it that you're using the Oni backend, right? Does this also happen if you use the Burst backend? (see: http://obi.virtualmethodstudio.com/tutor...kends.html)

In the editor and with normal builds all works well.
Also, with only the solver active (and the cloth disabled) the ILCPP build works correctly. Is only the moment that I enable the cloth gameobject (also when the OniCollisionWorld object appears), that it stops working.

Will try to reproduce this and get back to you. The Oni library comes precompiled, so using ILCPP or not should not have any impact on the build.

My second question would be how to configure the cloth to avoid my character going visually through it. [...] I also played with anisotropy set to 1, but didn't see much difference.

Anisotropy will not affect cloth particles. Currently it only affects fluid particles, in case you're using ObiFluid together with cloth. See:
http://obi.virtualmethodstudio.com/tutor...olver.html

My characters right now are capsules and the moving elements are mostly spheres, so there are no pointy edges, but maybe you have some extra advice to configuring a cloth for this. I assume that a mesh with a lot of points also helps.

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.

Another question.. when I enable "Substep Unity Physics" in the solver, my own code kind of breaks. For example, instead of the player correctly "attaching" to moving platforms, it now jump and stumble over them. My own "force element" scripts seems to apply more force to the player than before, like if they were called more times per second, but with the same old delta time.

"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.

I was expecting that enabling this option was kind of "transparent" to the rest of the code, but I assume is not, so I would like to know what steps I should follow or how I prepare my code to use it.

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

Calling Physics.Simulate does not cause FixedUpdate to be called. MonoBehaviour.FixedUpdate will still be called at the rate defined by Time.fixedDeltaTime whether automatic simulation is on or off, and regardless of when you call Physics.Simulate.

Also.. I have been using the "fixed updater substeps" set to 4, without enabling "Substep Unity Physics", and all seems to work correctly.. is this ok?

"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

Enable this when using more than 1 substep, and requiring accurate interaction with Unity rigidbodies (via collisions or dynamic attachments).

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.


Let me know if you need further help or guidance of any kind. Cloth simulation isn't easy and Obi is quite large, so it can be a bit daunting at first.

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

[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.

[josemendez]

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.

Burst, Jobs and packages in general aren't really that user friendly, so getting everything set up correctly can take a while. Getting caught up in "version nightmare" is quite common. 

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.

There's lots of settings than can affect performance heavily: fixed timestep length, substeps, constraint iterations, collisions, and a long etc. Some other pitfalls that will destroy performance are having deep profiling or/and the jobs debugger enabled. Some of these are quite "duh", some others take a bit of experience to identify and adjust properly. Using the profiler is often paramount in detecting what parts are taking most time, then you need to know what to adjust to reduce their runtime impact.

The Burst build seemed to stutter a little at the start the first time, but in subsequent runs both seems to start equally fast.

This would be asynchronous compilation doing its thing. By default, and only when running in-editor, Burst uses async JIT (just in time) code compilation: the game will start with all job code compiled as vanilla unoptimized C#. First time a job is called, Burst will kick a compilation process in the background. The job will run awfully slow until compilation finishes and the optimized, Burst compiled version of the code starts running. Subsequent runs will perform fine right from the start as the code has been already compiled.

For a standalone build, Burst code is precompiled. In editor, you can disable async compilation in the Burst menu and all Burst code will be compiled upon pressing Play (see: http://obi.virtualmethodstudio.com/tutor...kends.html)

Also, keep in mind that Burst uses asynchronous compilation in the editor by default. This means that the first few frames of simulation will be noticeably slower, as Burst is still compiling jobs while the scene runs. You can enable synchronous compilation in the Jobs->Burst menu, this will force Burst to compile all jobs before entering play mode.

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

Hope so  . I don't really want to over-hype surface collisions. As any technique, it also has its drawbacks (slightly costlier than particle collisions, slightly worse continuous collision detection) but it definitely results in collisions that feel way more robust.

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

That's it. Though I don't think you'll need to substep Unity physics (so no need to divide your delta time), see below.

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.

Should be good. "Kinematic for particles" means the object won't receive forces from particles, it will treat them as static colliders. So no Unity substepping required.

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

I was just kidding . One note though: a large gravity value will cause a large downwards acceleration, which works against convergence: the solver will have a harder time keeping cloth from stretching under gravity, so things might look stretchier than they would with lower gravity. As long as you're aware of this and know how to counterattack if needed (more distance constraint iterations and/or more substeps) all is well.

[LogaNRV]

Hi, again thanks for all the info.

About the "crash" using ILCPP and the Oni backend, I went and did the test of removing the Jobs package, and the build started crashing again.
So if at some point you want more info, at least I can reproduce it consistently. But for now I'm going to forget about it

Should be good. "Kinematic for particles" means the object won't receive forces from particles, it will treat them as static colliders. So no Unity substepping required.

Just to clarify this.. using both "Kinematic for particles" disabled and "Substep Unity physics" disabled would be good? (that is what I'm doing right now and I'm ok with the way it behaves).

One note though: a large gravity value will cause a large downwards acceleration, which works against convergence: the solver will have a harder time keeping cloth from stretching under gravity, so things might look stretchier than they would with lower gravity. As long as you're aware of this and know how to counterattack if needed (more distance constraint iterations and/or more substeps) all is well.

Oh.. that's why the cloth started looking more stretched when I changed gravity, and it looks better with 4 substeps
I will look at doing more distance constraint iterations I think.

Regards.