+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: General (https://obi.virtualmethodstudio.com/forum/forum-5.html)
+--- Thread: Performance issue. Could you help? (/thread-722.html)
Performance issue. Could you help? - mmortall - 19-10-2018
Hello.
We have a performance issue and we found this lines in profiler.
It seems like this operations leads to a huge performance drop. Can it be optimized in some way? Thanks.
This happens when we drop the soft body and it is simulated.
![[Image: CJf2JVB.png]](https://i.imgur.com/CJf2JVB.png)
RE: Performance issue. Could you help? - josemendez - 19-10-2018
(19-10-2018, 06:39 PM)mmortall Wrote: Hello.
We have a performance issue and we found this lines in profiler.
It seems like this operations leads to a huge performance drop. Can it be optimized in some way? Thanks.
This happens when we drop the soft body and it is simulated.
WaitForAllTasks() is being called 6 times per frame. This means physics is being executed a lot of times each frame, no wonder it takes a lot of time. All contacts in the scene are being copied between C++ and C# multiple times, so you're paying the cost of struct marshaling, x6. (Also, make sure that you absolutely need to use contact callbacks, you might not need to pay even x1).
Make sure you're not running into death spiralling. If you are, reduce Unity's "max physics timestep" parameter. See:
https://www.youtube.com/watch?v=sUVqa-72-Ms
Also remember than deep profiling adds a 60-70% overhead, so things will be much much faster with profiling disabled.
RE: Performance issue. Could you help? - mmortall - 22-10-2018
(19-10-2018, 09:35 PM)josemendez Wrote: WaitForAllTasks() is being called 6 times per frame. This means physics is being executed a lot of times each frame, no wonder it takes a lot of time. All contacts in the scene are being copied between C++ and C# multiple times, so you're paying the cost of struct marshaling, x6. (Also, make sure that you absolutely need to use contact callbacks, you might not need to pay even x1).
Make sure you're not running into death spiralling. If you are, reduce Unity's "max physics timestep" parameter. See:
https://www.youtube.com/watch?v=sUVqa-72-Ms
Also remember than deep profiling adds a 60-70% overhead, so things will be much much faster with profiling disabled.
Thanks for help.
I am currently using handler for Solver.OnCollision
and each frame I call Oni.GetParticleVelocities to find out that all particles are in the sleep state to detect that simulation is done.
This probably triggers marshaling, is it? Is there a way to detect that all particles are in sleep without using marshaling? Maybe do it in C++ side.
RE: Performance issue. Could you help? - josemendez - 22-10-2018
(22-10-2018, 10:58 AM)mmortall Wrote: Thanks for help.
I am currently using handler for Solver.OnCollision
and each frame I call Oni.GetParticleVelocities to find out that all particles are in the sleep state to detect that simulation is done.
This probably triggers marshaling, is it? Is there a way to detect that all particles are in sleep without using marshaling? Maybe do it in C++ side.
If you don't need to get per-contact collision information, do not subscribe to OnCollision. Each contact is a fairly large struct that needs to be marshaled, whereas velocities are blittable types and won't trigger marshaling.
Simply use GetParticleVelocities during LateUpdate, that should be enough to detect if particles are asleep.
In the upcoming Obi 4.0, all solver buffers are memory mapped so there's no need to call Get/Set methods for particle properties. All values are directly accessible from the C# side of things.
RE: Performance issue. Could you help? - mmortall - 22-10-2018
(22-10-2018, 11:25 AM)josemendez Wrote: If you don't need to get per-contact collision information, do not subscribe to OnCollision. Each contact is a fairly large struct that needs to be marshaled, whereas velocities are blittable types and won't trigger marshaling.
Simply use GetParticleVelocities during LateUpdate, that should be enough to detect if particles are asleep.
In the upcoming Obi 4.0, all solver buffers are memory mapped so there's no need to call Get/Set methods for particle properties. All values are directly accessible from the C# side of things.
Ok thanks. And GetParticleVelocities also use marshaling internally or no ?
RE: Performance issue. Could you help? - josemendez - 23-10-2018
(22-10-2018, 06:22 PM)mmortall Wrote: Ok thanks. And GetParticleVelocities also use marshaling internally or no ?
No, as velocities are a blittable type. They're pinned instead of marshaled.