18-12-2018, 05:58 PM
Hi all!
First off, I want to say that ObiCloth is an amazing and very affordable product that is far superior to Unity's built-in cloth system. Kudos to the team for providing such a performant and well-documented/programmed system.
First off, I've noticed that there are pretty obvious differences in simulation quality between FixedUpdate and LateUpdate, which is to be expected, especially when the FPS is low. For instance, it seems much more likely that the cloth will clip through colliders with LateUpdate and, in general, it seems to 'crumple' more. Ideally, we'd like for the cloth's simulation order to be FixedUpdate.
Our character movement is driven by root motion, which is applied to the character during its OnAnimatorMove function--IE, we translate the character directly from within this function. This allows us to have incredibly smooth/accurate motion and, to my knowledge, is commonly done in many video games. Our character does not use physics and only has a rigidbody (set to kinematic) because Obi requires one. All movement is driven by transform.Translate and not velocity or AddForce updates. Furthermore, our Animator update mode is set to Normal and not AnimatePhysics since we are not using physics. I should also add that our camera tracks the main character from within LateUpdate (and not Update or FixedUpdate, nor will it ever--aka, changing the update mode of the camera is not an acceptable solution for us.) Perhaps you see where I'm going with this...
The problem, then, is that, for whatever reason, setting the Simulation order to "FixedUpdate" changes the delta times received by the OnAnimatorMove function. It seems to, instead of using a DT that represents the current framerate (say, 0.016 at 60 FPS), we receive a DT of 0.02, which is the default (and ours) Unity fixed time step. I have no idea how the Obi controller code is able to 'hijack' this, but nevertheless, this introduces a problem for us where there is obvious and noticeable stutter--this is because the character movement is slightly 'off' from where the camera expects it to be if it were driven by the correct deltaTime.
Hopefully this problem makes sense, and I'm wondering if there is a way to have cloth that still works with FixedUpdate, without that simulation order altering our update rate, or if there is some code change we can make that can enable this behavior. To recap, our game does not use physics at all and nothing happens in FixedUpdate, nor do we want it to. The only thing that we 'need' it for would be the cloth, unless there's some way to achieve a more accurate/stable simulation in LateUpdate.
First off, I want to say that ObiCloth is an amazing and very affordable product that is far superior to Unity's built-in cloth system. Kudos to the team for providing such a performant and well-documented/programmed system.
First off, I've noticed that there are pretty obvious differences in simulation quality between FixedUpdate and LateUpdate, which is to be expected, especially when the FPS is low. For instance, it seems much more likely that the cloth will clip through colliders with LateUpdate and, in general, it seems to 'crumple' more. Ideally, we'd like for the cloth's simulation order to be FixedUpdate.
Our character movement is driven by root motion, which is applied to the character during its OnAnimatorMove function--IE, we translate the character directly from within this function. This allows us to have incredibly smooth/accurate motion and, to my knowledge, is commonly done in many video games. Our character does not use physics and only has a rigidbody (set to kinematic) because Obi requires one. All movement is driven by transform.Translate and not velocity or AddForce updates. Furthermore, our Animator update mode is set to Normal and not AnimatePhysics since we are not using physics. I should also add that our camera tracks the main character from within LateUpdate (and not Update or FixedUpdate, nor will it ever--aka, changing the update mode of the camera is not an acceptable solution for us.) Perhaps you see where I'm going with this...
The problem, then, is that, for whatever reason, setting the Simulation order to "FixedUpdate" changes the delta times received by the OnAnimatorMove function. It seems to, instead of using a DT that represents the current framerate (say, 0.016 at 60 FPS), we receive a DT of 0.02, which is the default (and ours) Unity fixed time step. I have no idea how the Obi controller code is able to 'hijack' this, but nevertheless, this introduces a problem for us where there is obvious and noticeable stutter--this is because the character movement is slightly 'off' from where the camera expects it to be if it were driven by the correct deltaTime.
Hopefully this problem makes sense, and I'm wondering if there is a way to have cloth that still works with FixedUpdate, without that simulation order altering our update rate, or if there is some code change we can make that can enable this behavior. To recap, our game does not use physics at all and nothing happens in FixedUpdate, nor do we want it to. The only thing that we 'need' it for would be the cloth, unless there's some way to achieve a more accurate/stable simulation in LateUpdate.