Bug / Crash Cloth lagging behind based on depth in higherarchy

[zagoalie]

Hi, I'm not sure if this is a bug, or something I am doing wrong. but in the video below but when i move the solver up one step in the hierarchy the cloth begins to displace. 

The cloth material itself is on "cloth skeletal hand" and if I place the solvers on "SS player" it works perfectly (first part of the video) but when I move the solvers one step up in the hierarchy to the Obi Solver level, then the cloth starts dragging behind the hand (the second part of the video)



Video: https://i.gyazo.com/be5d21c5dda70ed0195b...03ae80.mp4

The reason I wanted to do this is that there can be multiple player cursors on the screen (in coop) and I wanted all of them to use the same solver as I'm guessing there would be some performance penalty if every single cloth material had its own solver? (there are also some objects I spawn with cloth which are throne around the scene, and I wanted to be able to spawn them inside of the OBI solver in the hierarchy so each one does not need a static parent.)

[josemendez]

Looks like the object being moved around as the player moves the cursor is SSPlayer, correct? So you're moving the solver around, and injecting 50% of its world-space movement to the cloth simulation (as you have linear/angular inertia scaled set to 0.5 in the solver).

By moving the solver up the hierarchy, you're accomplishing two things:

- The solver is now static, so the cursor moves around within the solver's local space. No inertial effects will take place as the solver itself isn't moving, but the cloth is. You can notice this as in the second part of the video, cloth movement is much more lively/aggressive. Instead of injecting 50% of the solver movement to the otherwise static cloth, you're moving the cloth directly so 100% of its movement will be applied to particles.

- Cloth now relies on whichever attachment you're using being updated at the correct moment, relative to the cursor. If the attachment is updated before the cursor, you'll get a delay.

Depending on what you're after, you should either go with the world-space approach (leaving the solver up the hierarchy, and moving the cursor "within" it) or local-space approach (the cursor is the solver, you move the solver around, and inject back inertial forces). It's two completely different setups.

Also, keep in mind that you have solver interpolation enabled, and this will add a one-frame delay to visuals as explained in the manual. If you're not using slow-motion/bullet-time effects, it's best to disable it.
http://obi.virtualmethodstudio.com/tutor...olver.html

Interpolate will introduce a 1-frame delay between the actual physical location of particles and the position they're rendered at. Keep this in mind when using interpolation around other objects in the scene.

[zagoalie]

Both the SS player and the Obi solver are static objects, the object which moves is the "cursor" which is under the SS player.

I'm trying to go for the world space approach you mention, which is why both the SS player and Obi solvers are 100% static. but for some reason, I get different results depending on which one the solver is on.

Here yu can see both Obi solver and the SS player are compleatly static in world space, but if the solvers on the SS player it works fine, but not higher up the higherarchy on the obi solver. https://i.gyazo.com/53e973b194ab85fad974...4d8010.mp4

[josemendez]

In that case, there must be something else going on. I'm unable to reproduce this on a simple test scene, actors pick up their solver using Unity's GetComponentInParent() which returns the first component of a given type up the hierarchy. It should not matter how far up the hierarchy the solver is (except if you move the solver instead of the actors inside it, as I assumed you were doing)

Would it be possible for you to share a minimal repro project? send it to support(at)virtualmethodstudio.com.

thanks!

[zagoalie]

I did just find something interesting, if I have it in the none working position, then I turn the obi late updated off and on again, it starts working fine. 

https://i.gyazo.com/8e5024e0997a0f9e0df6...981716.mp4

the ss player does not start the scene inside the obi solver, it is spawned into it at runtime, could that be effecting it somehow? is their a particular presidure needed to make sure the solver connects to the cloth when adding a cloth to a solver at run time?

[josemendez]

I did just find something interesting, if I have it in the none working position, then I turn the obi late updated off and on again, it starts working fine. 

https://i.gyazo.com/8e5024e0997a0f9e0df6...981716.mp4

the ss player does not start the scene inside the obi solver, it is spawned into it at runtime, could that be effecting it somehow? is their a particular presidure needed to make sure the solver connects to the cloth when adding a cloth to a solver at run time?

Actors look for and connect to the first solver up their hierarchy when:

- The actor's OnEnable() is called.
- The actor's OnTransformParentChanged() is called (reparented to a new transform).
- The actor's blueprint is re-generated.

Actors won't look for a solver every frame as that would not be performant. If you remove/destroy a solver and then add a new solver up the hierarchy, the actor will lose its reference to its former solver. Only once you reparent/re-enable/re-generate the actor, it will connect to the new solver, if any.

As long as the "ssplayer" has its OnEnable() method called when spawned, or you re-parent it under a solver after spawning it, there should be no problem.