Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ObiCloth performance issue
#1
I found that ObiSolver ate a lot of CPU. I have tried to disable most of the Obi script but still no luck. I think the cloth mesh is just simple coat. Any advice?

My spec:
i5-6500
GeForce GTX 970
16GB ram

Unity 2017.1.2f1
Reply
#2
(18-10-2017, 10:53 AM)stevenwan Wrote: I found that ObiSolver ate a lot of CPU. I have tried to disable most of the Obi script but still no luck. I think the cloth mesh is just simple coat. Any advice?

My spec:
i5-6500
GeForce GTX 970
16GB ram

Unity 2017.1.2f1

Hi there,

You're suffering from "death spiralling", a condition common to all physics engines that use a fixed timestep (like Unity). The profiler pic clearly shows your physics are being updated 48 (!) times per frame, when 1 should be enough. This video might help you:
https://www.youtube.com/watch?v=sUVqa-72-Ms
Reply
#3
Thank you for the reply.

I changed to LateUpdate, No V-Sync, Fixed Timestep to 0.1. It still eats quite a lot of CPU. (I have 4 ObiCloth there)
Reply
#4
(18-10-2017, 04:15 PM)stevenwan Wrote: Thank you for the reply.

I changed to LateUpdate, No V-Sync, Fixed Timestep to 0.1. It still eats quite a lot a CPU. (I have 4 ObiCloth there)

- How many pooled particles you have in each solver?

- Seems that you have one solver per cloth. While this can be useful for culling, it is usually a bit better performance wise to have 1 solver for all of them.

With your scene (very few particles) and your machine specs, this should take no longer than 1 ms to simulate. Can you share your scene/project so that i can take a look at it?

cheers,
Reply
#5
(19-10-2017, 08:07 AM)josemendez Wrote: - How many pooled particles you have in each solver?

- Seems that you have one solver per cloth. While this can be useful for culling, it is usually a bit better performance wise to have 1 solver for all of them.

With your scene (very few particles) and your machine specs, this should take no longer than 1 ms to simulate. Can you share your scene/project so that i can take a look at it?

cheers,

I saw 406 particles used in solver.

I used 1 solver for each character (since I have 4 characters in the scene), am I right?

This is the project link.
https://drive.google.com/file/d/0B75oBQY...sp=sharing

Thank you!
Reply
#6
(19-10-2017, 09:44 AM)stevenwan Wrote: I saw 406 particles used in solver.

I used 1 solver for each character (since I have 4 characters in the scene), am I right?

This is the project link.
https://drive.google.com/file/d/0B75oBQY...sp=sharing

Thank you!

Hi, 

Each solver has 3000 particles pooled. This means you're allocating 12000 particles, even though only 1500 are being simulated. This is a waste of 87.5% of your memory resources, and some of your processing power too. Try to reduce the size of the pool in each solver to about 500. This will improve performance since particle arrays will be packed tighter and improve cache accesses.

Also, your cloth mesh is thick and double-sided. Done the way you're doing it, this consumes extra performance due to the extra amount of particles and constraints and will also result in simulation artifacts, since the cloth will actually be simulated as a "bag". The space between both sides of the cloth is empty, so nothing will prevent the inner side from passing trough the outer side. It's a lose-lose situation: bad performance, bad results.

Simulated cloth should always be one-sided, if you want to simulate thick cloth then use proxies. Check out the trenchcoat sample scene, and see:
http://obi.virtualmethodstudio.com/tutor...oxies.html

cheers,
Reply
#7
(19-10-2017, 10:18 AM)josemendez Wrote: Hi, 

Each solver has 3000 particles pooled. This means you're allocating 12000 particles, even though only 1500 are being simulated. This is a waste of 87.5% of your memory resources, and some of your processing power too. Try to reduce the size of the pool in each solver to about 500. This will improve performance since particle arrays will be packed tighter and improve cache accesses.

Also, your cloth mesh is thick and double-sided. Done the way you're doing it, this consumes extra performance due to the extra amount of particles and constraints and will also result in simulation artifacts, since the cloth will actually be simulated as a "bag". The space between both sides of the cloth is empty, so nothing will prevent the inner side from passing trough the outer side. It's a lose-lose situation: bad performance, bad results.

Simulated cloth should always be one-sided, if you want to simulate thick cloth then use proxies. Check out the trenchcoat sample scene, and see:
http://obi.virtualmethodstudio.com/tutor...oxies.html

cheers,

Thank you for the advice!

I used to follow the trenchcoat sample, I have made skin map before, not sure when the script isn't there. I have added it back and now it is around 5ms. Is it the expected result?
Reply
#8
(19-10-2017, 10:53 AM)stevenwan Wrote: Thank you for the advice!

I used to follow the trenchcoat sample, I have made skin map before, not sure when the script isn't there. I have added it back and now it is around 5ms. Is it the expected result?

Yes, with 4 separate solvers 5 ms starts to sound right in your machine. In mine (Core i7) it runs at about 1.2 ms.

You could make it faster by enabling tether constraints, and reducing the amount of distance iterations to 1.

cheers,
Reply
#9
Hi! Learned a lot from this thread, thanks!
Is it ok if I hijack this thread? Ángel

We're using obicloth in our game and we're wondering about the garbage collection.
With only two lowpoly characters we're up to 0.7KB.
Is this something that will be adressed?

Dear Regards
Peter S
Reply
#10
(19-10-2017, 01:49 PM)MrBeam Wrote: Hi! Learned a lot from this thread, thanks!
Is it ok if I hijack this thread?  Ángel

We're using obicloth in our game and we're wondering about the garbage collection.
With only two lowpoly characters we're up to 0.7KB.
Is this something that will be adressed?

Dear Regards
Peter S

Hi Peter,

We will try to, however getting the bone transform list from Unity into our C++ lib inevitably incurs in some allocations each frame. We won´t be able to reach zero allocation, but I´m sure we could reduce it.

cheers,
Reply