Every Job.Worker thread is "Idle"

[cubrman]

Hi,

Your project isn't using Burst or multithreading at all as clearly stated by the warning in your ObiSolver component inspector (otherwise the warning wouldn’t appear). This is because the ObiSolver script file has been moved to Utilities/Obi/Scripts, outside of Obi's folder (located in Assets/Obi) and its assembly. Since packages check each other's assemblies to determine what's installed and what's not but the solver is not part of any assembly, it's not detecting any of the other installed packages.

As explained in the manual you should not take apart the asset's folder structure or modify its contents in any way, as this will break it:
http://obi.virtualmethodstudio.com/manua...setup.html


The solution in your case is simply to delete Assets/Obi and Assets/Utilities/Obi and perform a fresh reinstall of the asset. Then if you want to move your Obi installation to another place in your project, do so as you would any other package: by moving the entire /Obi folder instead of some subfolders/files only.

Unrelated to this issue: in your scene's ObiSolver, relaxation is set to 0.1 (10%) on all constraint types but substeps are set to 4 and iterations to 2 or sometimes 3. This is a huge waste of resources as you're doing the same work a lot of times but only at 10% intensity each time. Set relaxation to 1 (100%) then reduce the amount of substeps/iterations as needed.

Let me know if you need further help,

kind regards

I did everything you told me but only gained around 2x performance boost, which, given that before the game ran on 1 FPS, raised it to 2. Job threads are now filled with tasks, although they are usually 55-70% Idle. If I may, I want to ask you to have another look at the project, just in case I missed something. Because having 2 FPS with only 14 2k models on the screen does not seem right:
https://drive.google.com/file/d/1OOqbNX2...sp=sharing

[josemendez]

I did everything you told me but only gained around 2x performance boost, which, given that before the game ran on 1 FPS, raised it to 2. Job threads are now filled with tasks, although they are usually 55-70% Idle. If I may, I want to ask you to have another look at the project, just in case I missed something. Because having 2 FPS with only 14 2k models on the screen does not seem right:
https://drive.google.com/file/d/1OOqbNX2...sp=sharing

Upon closer inspection, there’s tons of other issues with the project:

Deep profiling reveals most of the frame’s time (close to 80%) is spent on re-sorting and re-building all cloth constraints in the scene. This happens in the main thread and it's why most of the time your worker threads are idle. The script responsible for this is RealtimeInflation.cs, which is setting constraint parameters every single frame (UpdatePressureVariables() method, which sets pressure, stretchingScale and maxCompression). This forces the solver to regenerate all constraints every frame which takes an inordinate amount of time.

Another big chunk of time is spent on re-generating MeshColliders. This is done in CreateCovexMesh() in RealtimeInflation.cs, which triggers a re-generation of all internal MeshCollider spatial structures every single frame.

This finding leads us to the MeshColliders themselves: All ObiCloth components also have Rigidbody and MeshCollider components. This doesn’t make any sense, an object can either be a deformable body such as cloth or a rigid body but not both at once. As a result, things like gravity, collision detection or inertia will be applied twice (once by ObiCloth, a second time by Rigidbody) leading to undesired simulation results. Worse still, the cloth will be calculating collisions against the MeshColliders which is yet another large waste of processing time as it doesn't serve any purpose.

A lot of the remaining time is spent calculating particle-particle collisions. This is due to all softbodies having surface collisions enabled, while also being very high-resolution. This also takes up a considerable amount of time and is specifically warned against in the manual:
http://obi.virtualmethodstudio.com/manua...sions.html

Finally, according to the profiler FixedUpdate() is being called 16 times per frame so all physics are being updated 16 times when they should be updated once per frame at most. This is because your project’s max fixed timestep is set 16 times larger than your fixed timestep. Set it to a small multiple of it, eg. if your fixed timestep is 0.02 set your max time step to 0.04-0.06. After the above issues have been corrected this might not be necessary though, as the time taken by a single FixedUpdate() might not trigger more than one physics update per frame anymore.

Wrapping up:
- Don’t add Rigidbody and Collider components to cloth, since this will simulate the object twice: as deformable and as rigid. Cloth already has inertia/gravity/mass, and already collides with other objects.
- Do not attempt to set the sharedMesh of a MeshColliders every frame as that's extremely costly.
- Don’t use surface collisions if your cloth actors are such high resolution, it is not of any use and will obliterate performance.
- Don’t assign constraint parameters every frame unless necessary.
- Fix the project's time settings.

Fixing these gets me around 80 FPS on a Core i7 CPU, even with leak detection and debugging enabled. PM'd you a short video.

As a side note most settings on the ObiCloth components are really strange, almost random. For instance volume compliance is set to 90 which will make volume constraints really ineffective: compliance is a measure of the  constraints strength -their Young modulus-, a compliance of 0 means constraints will be as strong as possible -which is the default setting-, higher compliances up to around 1 mean less strength. A compliance of 90 will force you to use huge pressure values to get volume constraints to do anything at all.

There’s also a stretch scale of 75% (which will make objects crumple to 75% of their initial size), and max bending and plastic yield/creep of 0.1 which also don’t make any sense in the context of the scene. None of these have a direct impact on performance, but they aren't sensible choices and will lead to strange behavior.

kind regards,

[cubrman]

Upon closer inspection, there’s tons of other issues with the project:

Deep profiling reveals most of the frame’s time (close to 80%) is spent on re-sorting and re-building all cloth constraints in the scene. This happens in the main thread and it's why most of the time your worker threads are idle. The script responsible for this is RealtimeInflation.cs, which is setting constraint parameters every single frame (UpdatePressureVariables() method, which sets pressure, stretchingScale and maxCompression). This forces the solver to regenerate all constraints every frame which takes an inordinate amount of time.

Another big chunk of time is spent on re-generating MeshColliders. This is done in CreateCovexMesh() in RealtimeInflation.cs, which triggers a re-generation of all internal MeshCollider spatial structures every single frame.

This finding leads us to the MeshColliders themselves: All ObiCloth components also have Rigidbody and MeshCollider components. This doesn’t make any sense, an object can either be a deformable body such as cloth or a rigid body but not both at once. As a result, things like gravity, collision detection or inertia will be applied twice (once by ObiCloth, a second time by Rigidbody) leading to undesired simulation results. Worse still, the cloth will be calculating collisions against the MeshColliders which is yet another large waste of processing time as it doesn't serve any purpose.

A lot of the remaining time is spent calculating particle-particle collisions. This is due to all softbodies having surface collisions enabled, while also being very high-resolution. This also takes up a considerable amount of time and is specifically warned against in the manual:
http://obi.virtualmethodstudio.com/manua...sions.html

Finally, according to the profiler FixedUpdate() is being called 16 times per frame so all physics are being updated 16 times when they should be updated once per frame at most. This is because your project’s max fixed timestep is set 16 times larger than your fixed timestep. Set it to a small multiple of it, eg. if your fixed timestep is 0.02 set your max time step to 0.04-0.06. After the above issues have been corrected this might not be necessary though, as the time taken by a single FixedUpdate() might not trigger more than one physics update per frame anymore.

Wrapping up:
- Don’t add Rigidbody and Collider components to cloth, since this will simulate the object twice: as deformable and as rigid. Cloth already has inertia/gravity/mass, and already collides with other objects.
- Do not attempt to set the sharedMesh of a MeshColliders every frame as that's extremely costly.
- Don’t use surface collisions if your cloth actors are such high resolution, it is not of any use and will obliterate performance.
- Don’t assign constraint parameters every frame unless necessary.
- Fix the project's time settings.

Fixing these gets me around 80 FPS on a Core i7 CPU, even with leak detection and debugging enabled. PM'd you a short video.

As a side note most settings on the ObiCloth components are really strange, almost random. For instance volume compliance is set to 90 which will make volume constraints really ineffective: compliance is a measure of the  constraints strength -their Young modulus-, a compliance of 0 means constraints will be as strong as possible -which is the default setting-, higher compliances up to around 1 mean less strength. A compliance of 90 will force you to use huge pressure values to get volume constraints to do anything at all.

There’s also a stretch scale of 75% (which will make objects crumple to 75% of their initial size), and max bending and plastic yield/creep of 0.1 which also don’t make any sense in the context of the scene. None of these have a direct impact on performance, but they aren't sensible choices and will lead to strange behavior.

kind regards,

Thanks, will try these.