Closed GoogleCodeExporter closed 8 years ago
Ok, so it seems the performance issues are due to Debug.Log calls lingering in
the code. This should be easy to fix:
DOTween/Plugins/Core/PathCore/Path.cs:66
DOTween/Plugins/Core/PathCore/Path.cs:55
Original comment by gustavo....@gmail.com
on 8 Mar 2015 at 11:12
Hi Gustavo,
I apologize, I created those logs recently while testing stuff, but leaving
them around in a release build was completely idiotic of me. Grab this version
in the meantime which fixes it, and I'll release it publicly later, with a few
more additions I'm working on.
Original comment by daniele....@gmail.com
on 8 Mar 2015 at 3:42
Attachments:
Good day Daniele,
Thanks for the quick response. I have tested the fix and the CPU spikes are
greatly reduced but they are not completely gone. With the same setup described
above the CPU spikes have been reduced to around 31ms on the PC build, on
Android the spikes last around 87ms. I'm attaching a screenshot of the PC build
Unity profiler.
I think there is still some issue lingering there. Not sure if this helps but
the problem seems to happen when an object finishes a path (each object is set
to Loop the path).
Original comment by gustavo....@gmail.com
on 8 Mar 2015 at 7:19
Attachments:
Ok, I have confirmed the issue happens when an object finishes traveling the
path and it returns to the beginning again. Unfortunately I can't share you a
project with my scene setup but I created a simple one to describe you the
problem. See attached screenshot, let me know if I can help further.
Original comment by gustavo....@gmail.com
on 8 Mar 2015 at 7:47
Attachments:
Good day to you Gustavo, and thanks for the detailed reports.
Could you share with me another screenshot, but with the Profiler set to "deep
profile", and its hierarchy expanded to see what internal
DOTweenComponent.Update part is using most of the resources during the spike?
Also, are you moving a rigidbody by any chance (in which case the spike might
be caused by Unity translating it over a wider distance during restart, and
thus needing more physics calculations)?
Thanks!
Original comment by daniele....@gmail.com
on 8 Mar 2015 at 8:33
Original comment by daniele....@gmail.com
on 8 Mar 2015 at 8:33
Hi Daniele,
Find attached a screenshot with the Deep Profile option enabled. From the data
it seems most of the time is spent in CatmullRomDecoder.GetPoint(), the
function CatmullRomDecoder.SetWaypointsLength() calls it so many times it just
doesn't seem right (51170 times). Another red flag is
CatmullRomDecoder.SetTimeToLengthTable() calling it 731 times.
On the test scene each path follower has a non-static collider and a rigidbody
indeed, however I have no evidence this is the cause of the performance problem.
Regards,
Gus
Original comment by gustavo....@gmail.com
on 9 Mar 2015 at 1:30
Attachments:
Hiya,
the only reason why GetPoint is called so many times when the tween starts
(both when called by SetWaypointsLength and SetTimeToLengthTable) is that the
path subdivisions-x-segment are set to some massively high value. In your case,
with 8 waypoints, that would be a value of 6396, while the recommended value is
5, or 10 if you want high resolution. Anything more than that is useless.
Are you setting the path subdivisions manually or is SWS setting them
automatically (in which case I'll contact Baroni)?
Original comment by daniele....@gmail.com
on 9 Mar 2015 at 11:02
P.S. I investigated around your report more, and while the previous issue I
mentioned remains, I also optimized some internal calls. This update will call
GetPoint a lot less times (but still too many, so the previous issues remains).
Original comment by daniele....@gmail.com
on 9 Mar 2015 at 11:22
Attachments:
P.P.S. I contacted Baroni in the meantime to check if the path's resolution is
set automatically by SWS, and eventually fix it on his side.
Original comment by daniele....@gmail.com
on 9 Mar 2015 at 12:18
Hi Daniele,
I found the code in SWS that starts the tween and sets the resolution (default
to 10):
tween = transform.DOPath(wpPos, originSpeed, pathType, pathMode)
.SetAs(parms)
.SetOptions(false, lockPosition, lockRotation)
.SetLookAt(lookAhead);
I inspected the API and the resolution is 10 if no argument is given for that
parameter. I tried different values from 5 to 0 and the CPU spikes decreased
dramatically. Zero gave me an almost unnoticeable CPU spike (not gone thought).
tween = transform.DOPath(wpPos, originSpeed, pathType, pathMode, 0)
.SetAs(parms)
.SetOptions(false, lockPosition, lockRotation)
.SetLookAt(lookAhead);
Attached is the screenshot when 0 resolution is used.
CatmullRomDecoder.GetPoint() is still being called plenty of times though (5180
+74). I noticed setting the resolution to 0 didn't change change the quality of
the Tween animations, this suggests possibly there is something wrong in the
way the resolution is handled in the code?
Regards,
Gus
Original comment by gustavo....@gmail.com
on 10 Mar 2015 at 5:51
Attachments:
Hi again Daniele,
I have good news! I used the DOTween version 1.0.280 attached above by you and
by setting the resolution to zero the issue is completely gone, no CPU spikes
at all and my 10 tweens on two different paths are silky smooth. The
DOTweenComponent.Update() takes from 0.8ms to 0.23ms on my PC and takes 0.33ms
to 0.63ms on my target Android device. Thanks a lot for your help :)
I'm looking forward for the public update.
Regards,
Gus
Original comment by gustavo....@gmail.com
on 10 Mar 2015 at 6:10
Great! :) Baroni told me he fixed his side of the issue already, so this should
be up very quickly
Original comment by daniele....@gmail.com
on 11 Mar 2015 at 10:35
Original issue reported on code.google.com by
gustavo....@gmail.com
on 8 Mar 2015 at 10:27Attachments: