09-11-2019, 08:30 AM
(This post was last modified: 09-11-2019, 08:32 AM by josemendez.)
(08-11-2019, 09:07 PM)jpalz Wrote: OK, I bought Obi Rope, created a rope at first using the ObiRopeExtrudedRenderer (made by selecting GameObject -> 3D Object -> Obi Rope fully set up).
The rope is 3m long, rendered using 52 particles, and with one pin constraint at the beginning and end particle, so the leash is connected to the human and the dog. So far, so good.
And then I hit Play...
I noticed immediately that there's a performance drop which is super noticeable. Profiling the game, I find the following:
For some reason, there are two FixedUpdates and two WaitForAllSolvers.
Changing the renderer to the ObiRopeLineRenderer improved the framerate, but there were still noticeable spikes, seeing something like this:
What can I do to improve the framerate? My guess is that it starts by changing the FixedUpdate to only one call. I've tried increasing the Fixed Timestep to 0.04, but there are still occasional hitches.
Thanks!
Hi,
Deep profiling will cause any game to run 70-80% slower than it usually would, which can (usually will) trigger death spiraling.(*) Excerpt from Unity's manual:
https://docs.unity3d.com/Manual/Profiler...-profiling
Quote:When you enable the Deep Profile setting, the Profiler profiles every part of your script code and records all function calls, including at least the first call stack depth into any Unity API. This is useful information to help you work out where your code impacts on your application’s performance, but it comes with a large overhead.
So disable the profiler entirely. If you have performance issues, profile using the normal profiler. If you still can't figure out what's happening, then use deep profiling to get a sense of relative (not absolute!) performance between function calls.
(*)This is a situation where each frame takes a lot of time to be completed, which increases the amount of time to be simulated by physics, increasing the amount of fixed updates needed per frame, which in turn causes the next frame to take even longer to complete...in a downwards spiral that ends when a frame takes less time to process than the amount of "wall-clock" time it simulates, or when you hit the maximum fixed timestep. If you're having this issue, reducing the maximum fixed timestep or increasing the timestep are viable solutions.