+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Cloth (https://obi.virtualmethodstudio.com/forum/forum-2.html)
+--- Thread: Help ObiCloth local space documentation is outdated? (/thread-4119.html)
ObiCloth local space documentation is outdated? - CptnFabulous - 28-02-2024
Hi!
I have an object with an ObiSolver attached, with several ObiCloth shapes as children. The parent object needs to be moved and teleported, but this causes the rendered cloth to behave like it’s simply moving at high speeds, causing it to glitch out and behave in unnatural ways. To solve this, I’m trying to make the cloth simulation happen in the solver’s local space instead of world space, so that the parent’s movements don’t affect the cloth simulation. Not 100% realistic, but good enough for my purposes.
I've looked in the forum but haven't found a clear answer. In some posts I’ve seen people say that the simulations always occur in the local space of the solver itself, but that should mean the cloth is already operating in local space, which isn’t happening. I also found values for determining how much the local space values are affected by world space movement, but those are both set to zero.
I’m trying to make the cloth render in the solver’s local space instead of world space, and am looking at this documentation to try and figure it out: https://obi.virtualmethodstudio.com/manual/4.X/localspace.html
I’m currently using ObiCloth version 6.5.4, in the Unity Editor 2021.3.3f1, but the only detailed version of the documentation is for an older version. The later versions are marked red as incomplete and can’t be selected.
The documentation shows that in ObiSolver there’s a bool to enable local space simulation, but when I look at the script (both in the Inspector and at the code itself), no option exists. The two options I mentioned for determining world space influence both have comments that reference a ‘simulateInLocalSpace’ option, but returns no results when I use FindAll across the entire solution (aside from those two comments). I’ve got two images here to show how different the ObiSolver is in the inspector.
The image shown in the documentation:
![[Image: local_space_inspector.png]](https://obi.virtualmethodstudio.com/manual/images/localspace/local_space_inspector.png)
The way it appears in my project:
![[Image: PgaTuWH.png]](https://i.imgur.com/PgaTuWH.png)
So in the version I’m using, what do I need to do to ensure the cloth simulates in local space? I presume the feature must have been refactored and moved to a different section of the code, as I refuse to believe such an important feature would be outright removed.
Thanks!
RE: ObiCloth local space documentation is outdated? - josemendez - 28-02-2024
Hi there!
From ObiSolver's current version documentation:
https://obi.virtualmethodstudio.com/manual/6.3/obisolver.html
Quote:Solvers always perform the simulation in local space. This means that translating, rotating or scaling the solver will rigidly transform the simulation as a whole.
You can inject a percentage of the solver linear/rotational movement back into the simulation, in the form of inertial forces. For instance, you might want to control how much of the overall character movement will affect the clothing simulation. For this purpose, solvers expose two parameters to independently control linear and rotational inertial forces (see below).
(28-02-2024, 07:54 AM)CptnFabulous Wrote: The parent object needs to be moved and teleported, but this causes the rendered cloth to behave like it’s simply moving at high speeds, causing it to glitch out and behave in unnatural ways.
Double check that both the linear and angular inertia scale parameters in the solver are set to zero - you mention this already, but the behavior you describe really sounds like they aren't. By default, moving the solver around will not affect the simulation in any way - even when teleported. Simulation is always performed in local space (also all particle and constraint related data exposed by the API is expressed in the solver's local space).
Note that if you have kinematic rigidbodies close to the cloth that also get teleported together with it and you're using continuous collision detection, cloth will take into account their velocity vector upon teleporting and might respond to them as if they were launched towards the cloth at high speeds - since the world space velocity vector of the rigidbodies is not zero. In these cases, temporarily setting continuous collision detection to zero before teleporting is the typical workaround.
kind regards,
RE: ObiCloth local space documentation is outdated? - CptnFabulous - 03-03-2024
Alright I've been doing some more checking. I realised there are multiple kinematic rigidbodies that are also children of the same object that the solver is parented to.
I'm not sure if I can get rid of them, as they're attached to colliders that the cloth needs to collide with. Those colliders need to have ObiColliders attached, which automatically attach an ObiRigidbody to the closest parent Rigidbody.
I'm looking at the documentation and am trying to figure out - does an ObiCollider have to have a rigidbody somewhere in its transform hierarchy in order to function at all and collide with particles? If not, I should be able to remove all of the rigidbodies. Even if it does, I should still be able to include just one kinematic rigidbody at the very root (I don't have any need for the colliders to have realistic physics, only for them to collide with the cloth particles), maybe that will prevent those glitches from occurring since the child colliders won't technically have rigidbodies on them?
Thanks!
RE: ObiCloth local space documentation is outdated? - josemendez - 11-03-2024
(03-03-2024, 10:35 AM)CptnFabulous Wrote: I'm looking at the documentation and am trying to figure out - does an ObiCollider have to have a rigidbody somewhere in its transform hierarchy in order to function at all and collide with particles?
Nope, just like in Unity. Colliders are for collision, Rigidbodies are for dynamics. They're completely independent from each other, you can have just a collider without a rigidbody.
(03-03-2024, 10:35 AM)CptnFabulous Wrote: If not, I should be able to remove all of the rigidbodies. Even if it does, I should still be able to include just one kinematic rigidbody at the very root (I don't have any need for the colliders to have realistic physics, only for them to collide with the cloth particles), maybe that will prevent those glitches from occurring since the child colliders won't technically have rigidbodies on them?
Correct: a Collider without a Rigidbody has no velocity, hence no continuous collision detection will be calculated for it.