Some issues and questions.

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