WaitForAllTasks spent a lot of time!

[sunyifeng83]

I have encountered a performance problem. When i simulate a faucet emitter with 1000 particles limit, the fps will drop obiviously with the particle nums adding. Finally the fps will dropped to less than 10fps. I have attached my configurations and the function WaitForAllTasks spent time. How can i get over the problem. Any help will be appreciated!

[josemendez]

I have encountered a performance problem. When i simulate a faucet emitter with  1000 particles limit, the fps will drop obiviously with the particle nums adding. Finally the fps will dropped to less than 10fps. I have attached my configurations and the function WaitForAllTasks spent time. How can i get over the problem. Any help will be appreciated!

Hi!

Take a look at this video, it treats exactly the problem you're having:
https://www.youtube.com/watch?v=sUVqa-72-Ms

Basically, reduce the Max Physics Timestep setting (ProjectSettings->Time) in Unity to avoid your physics being updated 12 (!) times each frame -as the profiler shows in your screenshots-. They should not update more than 2-3 times frame.

FYI, "WaitForAllTasks" waits for all parallel Obi tasks to end, since they're spawned and done in multiple threads. So this function actually waits for all the simulation work to be done by the engine. 

Edit: If you need some approximate settings to start with, use a Fixed Timestep of 0.02 and a Maximum Allowed Timestep of 0.06.

cheers!

[sunyifeng83]

Hi!

Take a look at this video, it treats exactly the problem you're having:
https://www.youtube.com/watch?v=sUVqa-72-Ms

Basically, reduce the Max Physics Timestep setting (ProjectSettings->Time) in Unity to avoid your physics being updated 12 (!) times each frame -as the profiler shows in your screenshots-. They should not update more than 2-3 times frame.

FYI, "WaitForAllTasks" waits for all parallel Obi tasks to end, since they're spawned and done in multiple threads. So this function actually waits for all the simulation work to be done by the engine. 

Edit: If you need some approximate settings to start with, use a Fixed Timestep of 0.02 and a Maximum Allowed Timestep of 0.06.

cheers!

Hi jose,

Thanks for you reply. I modified the Fixed Timestep to 0.02 and a Maximum Allowed Timestep to 0.06. And now they update 3 times per frame. But it still spent a lot of time(see my attachment). Is there any way to get more performance?

[josemendez]

Hi jose,

Thanks for you reply. I modified the Fixed Timestep to 0.02 and a Maximum Allowed Timestep to 0.06. And now they update 3 times per frame. But it still spent a lot of time(see my attachment). Is there any way to get more performance?

What are your ObiSolver settings? You could try reducing the amount of constraint iterations. If you're not piling a lot of fluid (inside a container for instance) 2 density iterations should be enough.

You can add the ObiProfiler component to your solver and you'll get a very detailed on-screen graph of the core usage in your CPU when you run the scene, and how much time each internal Obi function is taking up. If you could take a screenshot of it I could tell you more. 50 ms/frame is definitely not normal for just 1000 particles, unless you're using a huge/lots of MeshColliders or something similar.

As a reference, the FluidViscosity test scene with 3000 particles takes about 6-8 ms/frame in my computer (a pretty modest 4-core cpu).

[sunyifeng83]

What are your ObiSolver settings? You could try reducing the amount of constraint iterations. If you're not piling a lot of fluid (inside a container for instance) 2 density iterations should be enough.

You can add the ObiProfiler component to your solver and you'll get a very detailed on-screen graph of the core usage in your CPU when you run the scene, and how much time each internal Obi function is taking up. If you could take a screenshot of it I could tell you more. 50 ms/frame is definitely not normal for just 1000 particles, unless you're using a huge/lots of MeshColliders or something similar.

As a reference, the FluidViscosity test scene with 3000 particles takes about 6-8 ms/frame in my computer (a pretty modest 4-core cpu).

Hi jose,

I attach my configuration of the solver and the profiler image. It seems the collision processing takes much time. But in my scene i used just 5 mesh colliders (4 mesh colliders used for 4 walls in the room). It's definitely not normal.

[josemendez]

Hi jose,

I attach my configuration of the solver and the profiler image. It seems the collision processing takes much time. But in my scene i used just 5 mesh colliders (4 mesh colliders used for 4 walls in the room). It's definitely not normal.

Hi!

The settings seem ok, the problem is definitely collision detection. How complex are your colliders, and how big are their bounding boxes?

MeshColliders are extremely costly to collide against (since each triangle in them costs roughly the same as a primitive collider) and are better avoided unless it's not possible. Now, if the bounding box of your colliders is big enough to enclose the entire room, it means each particle in the fluid is being tested for collisions against every triangle in all walls every frame. This would explain your low performance. Say your walls have 1000 triangles each, and you have 4 of them. If their bounding boxes enclose the emitter, then you're performing 1000x4000 = 4 million sphere/triangle intersection tests every frame.

A solution would be to switch to primitive colliders (which are much cheaper), or if the problem is the bounding boxes, try to split your meshes so that the bounding box is tighter and the fluid only checks for collision against a wall when very close to it.

A screenie of your whole scene, with the colliders selected would allow me to give more info.

[sunyifeng83]

Hi!

The settings seem ok, the problem is definitely collision detection. How complex are your colliders, and how big are their bounding boxes?

MeshColliders are extremely costly to collide against (since each triangle in them costs roughly the same as a primitive collider) and are better avoided unless it's not possible. Now, if the bounding box of your colliders is big enough to enclose the entire room, it means each particle in the fluid is being tested for collisions against every triangle in all walls every frame. This would explain your low performance. Say your walls have 1000 triangles each, and you have 4 of them. If their bounding boxes enclose the emitter, then you're performing 1000x4000 = 4 million sphere/triangle intersection tests every frame.

A solution would be to switch to primitive colliders (which are much cheaper), or if the problem is the bounding boxes, try to split your meshes so that the bounding box is tighter and the fluid only checks for collision against a wall when very close to it.

A screenie of your whole scene, with the colliders selected would allow me to give more info.

Hi jose,

I attached the colliders setting image here. The 4 walls using meshcolliders. others use primitive colliders. I'll try remove the meshcolliders.

---

Hi jose,

I found I have many small mesh colliders in the classroom also. Maybe they will cause the problem. I will remove them and testing again.

---

Hi jose,

I have removed the redundent mesh colliders for small objects. The wall's colliders also removed. But the collision processing still have a big impact on the performance. Now the WaitForAllTasks spent 30ms. It's still not normal.

[josemendez]

Hi jose,

I attached the colliders setting image here. The 4 walls using meshcolliders. others use primitive colliders. I'll try remove the meshcolliders.

---

Hi jose,

I found I have many small mesh colliders in the classroom also. Maybe they will cause the problem. I will remove them and testing again.

---

Hi jose,

I have removed the redundent mesh colliders for small objects. The wall's colliders also removed. But the collision processing still have a big impact on the performance. Now the WaitForAllTasks spent 30ms. It's still not normal.

Hi!

Would it possible for me to take a look at your project? Maybe you could export a unity package with the scene so that I can open it? This way I can debug it for you faster.

[sunyifeng83]

Hi!

Would it possible for me to take a look at your project? Maybe you could export a unity package with the scene so that I can open it? This way I can debug it for you faster.

Hi jose,

Okay. I will send my test project to you by email. Its too huge to send by email. 90mb, how can i send to you?

[lidiamartinez]

You can use WeTransfer website. Then send us a link. Please, write to support@virtualmethodstudio.com Note this email is only for private queries like this.