Animate physics Lags my other animations

[jeremy2132]

In order to make the cloth simulation not lag behind the animation I need the Update Mode in the animator be set to animate physics. This makes all my character animations choppy and laggy as a result. Is there any that my character animations can be smooth like they are in the normal update mode wiithout making the physics lag one frame behind the animation simulation?

[josemendez]

In order to make the cloth simulation not lag behind the animation I need the Update Mode in the animator be set to animate physics. This makes all my character animations choppy and laggy as a result. Is there any that my character animations can be smooth like they are in the normal update mode wiithout making the physics lag one frame behind the animation simulation?

Yes, use an ObiLateUpdater component instead of the default ObiFixedUpdater. This will update cloth after animation has taken place in the animator’s normal update mode. See:

http://obi.virtualmethodstudio.com/manua...aters.html

[jeremy2132]

Yes, use an ObiLateUpdater component instead of the default ObiFixedUpdater. This will update cloth after animation has taken place in the animator’s normal update mode. See:

http://obi.virtualmethodstudio.com/manua...aters.html

this seems to be more costly on performance, is there any way to optimize this to run well with multiple characters with cloth simulations in a single scene?

[josemendez]

this seems to be more costly on performance, is there any way to optimize this to run well with multiple characters with cloth simulations in a single scene?

Theoretically it should be considerably cheaper, since FixedUpdate() can be called multiple times per frame, but LateUpdate() is guaranteed to be called only once. I can’t think of any reason why it would be slower than the fixed updater.

Optimization really depends on what your bottleneck is. To determine that, profiling is the only way.
Use Unity’s profiler to check what is time being spent on. Once you know what’s more costly, you can reduce the amount of substeps, iterations, etc. If you want I can help with interpreting profiler data.

[jeremy2132]

Theoretically it should be considerably cheaper, since FixedUpdate() can be called multiple times per frame, but LateUpdate() is guaranteed to be called only once. I can’t think of any reason why it would be slower than the fixed updater.

Optimization really depends on what your bottleneck is. To determine that, profiling is the only way.
Use Unity’s profiler to check what is time being spent on. Once you know what’s more costly, you can reduce the amount of substeps, iterations, etc. If you want I can help with interpreting profiler data.

When i use obi cloth to create a cape my frames per second go from 280 to 70 in a scene with nothing but the player model. When I have three clothes in one scene my fps is down to 40. Do I have have too  many vertices on my cape that make the blueprint too complex? Here is my profiler data of the scene with the Player.

[josemendez]

When i use obi cloth to create a cape my frames per second go from 280 to 70 in a scene with nothing but the player model. When I have three clothes in one scene my fps is down to 40. Do I have have too  many vertices on my cape that make the blueprint too complex? Here is my profiler data of the scene with the Player.

Hi!

I can't see any profiler screenshot, but down to 70 fps from 280 (10 ms/frame) for a single character sounds way too much. Tip: never ever measure performance in fps, as it's not linear (eg: a performance hit that causes fps to drop from 60 to 30 would not cause fps to drop from 200 to 100, but to 50). Always use ms/frame, as you can compare them regardless of fps, making it much easier to reason about and compare performances.

Some general tips on performance:

- If using the Burst backend (which is recommended for performance, you should basically never use Oni as it's just a fallback), make sure you've disabled the jobs debugger and safety checks. These will very negatively affect performance in-editor. See: http://obi.virtualmethodstudio.com/manua...kends.html

- Make sure you're not using deep profiling. This also affects performance very negatively.

- Use as few substeps as you can get away with. Performance scales roughly linearly with the amount of substeps, so 4 substeps will be 4 times as slow as 1 substep.

- Use as few constraint iterations as you can. For an in-depth explanation of how the simulation works and how iterations/substeps affect it, see:
http://obi.virtualmethodstudio.com/manua...gence.html

- Disable any constraints you're not using.

- Use the simplest cloth rendering mode possible. If not using normal maps, this usually means CopyNormalsFromSimulation. See:
http://obi.virtualmethodstudio.com/manua...modes.html

- For character cloth, more than 1000 vertices on a single character is probably too much (unless there's only one of them on-screen). If you need very complex clothing, don't simulate it directly: use proxies to transfer simulation.

There's lots of other settings (both in Obi and Unity) that greatly affect performance, most of them are common sense but still it's best to use the profiler as your guide when optimizing. Otherwise you'd be just turning knobs at random .

[jeremy2132]

Hi!

I can't see any profiler screenshot, but down to 70 fps from 280 (10 ms/frame) for a single character sounds way too much. Tip: never ever measure performance in fps, as it's not linear (eg: a performance hit that causes fps to drop from 60 to 30 would not cause fps to drop from 200 to 100, but to 50). Always use ms/frame, as you can compare them regardless of fps, making it much easier to reason about and compare performances.

Some general tips on performance:

- If using the Burst backend (which is recommended for performance, you should basically never use Oni as it's just a fallback), make sure you've disabled the jobs debugger and safety checks. These will very negatively affect performance in-editor. See: http://obi.virtualmethodstudio.com/manua...kends.html

- Make sure you're not using deep profiling. This also affects performance very negatively.

- Use as few substeps as you can get away with. Performance scales roughly linearly with the amount of substeps, so 4 substeps will be 4 times as slow as 1 substep.

- Use as few constraint iterations as you can. For an in-depth explanation of how the simulation works and how iterations/substeps affect it, see:
http://obi.virtualmethodstudio.com/manua...gence.html

- Disable any constraints you're not using.

- Use the simplest cloth rendering mode possible. If not using normal maps, this usually means CopyNormalsFromSimulation. See:
http://obi.virtualmethodstudio.com/manua...modes.html

- For character cloth, more than 1000 vertices on a single character is probably too much (unless there's only one of them on-screen). If you need very complex clothing, don't simulate it directly: use proxies to transfer simulation.

There's lots of other settings (both in Obi and Unity) that greatly affect performance, most of them are common sense but still it's best to use the profiler as your guide when optimizing. Otherwise you'd be just turning knobs at random .

After lowering the poly count, changing render mode, and disabling certain constraints I was able to get the frame rate up to 200 and the ms to be around 5. My only question is that for some reason burst doesn't seem to be better or worse than oni when I switch between them? Even after I disable safety checks, Job debugger and leak detection they are basically the same. Am i doing something wrong with burst or does burst make a larger difference with mobile than pc?

[josemendez]

After lowering the poly count, changing render mode, and disabling certain constraints I was able to get the frame rate up to 200 and the ms to be around 5. My only question is that for some reason burst doesn't seem to be better or worse than oni when I switch between them? Even after I disable safety checks, Job debugger and leak detection they are basically the same. Am i doing something wrong with burst or does burst make a larger difference with mobile than pc?

Both Oni and Burst use the same underlying principles, but they implement them differently: both make use of multithreading and vectorization, but Oni implements it natively (C/C++) and Burst uses Unity's Job system and Burst compiler.

In desktop platforms, they run pretty much equally fast. Burst does have a slight edge in our tests, so still you should prefer it. However on mobile platforms Burst is clearly faster. In addition to that, Burst supports a wider variety of platforms. That's why using Burst is recommended.

From the manual:
http://obi.virtualmethodstudio.com/manua...kends.html

Like Oni, Burst is fully CPU-based, and makes heavy use of multithreading and SIMD (thanks to the job system and Burst, respectively). Performance on most platforms -specially mobile devices- is slightly better when using Burst. For this reason, Burst should be preferred over Oni when possible.