Hi. I have been investigating this bug…
It seems to be a precision issue introduced when we convert the content from world space and then to local space in relation to the view bounds.
If you are using the UI source then applying the following should fix the problem:
ScrollRect.cs
In UpdateBounds
- if (delta != Vector3.zero) // Remove this line
+ if (delta.sqrMagnitude > 0.01f) // Replace with this
Once the fix is approved I’ll get it backported to 5.6.
I’m getting a similar behavior (canvas scale set to 0,0,0), except it happens when I apply prefab changes from a hierarchy object. Weirdly, it can affect seemingly unrelated canvases.
Hopefully this fix will work. Awaiting a 5.6.0 patch release.
@karl_jones do you know if this was resolved in 5.6p1? If not, do you know when it is scheduled to go out? 5.6 is a no-go for many of us without this fix and going to 2017.1 beta is absolutely not an option.
@karl_jones The fix seems to work on both the ScreenSpace-Camera Dropdowns issue and the general ScrollRect issue at least for the test project used for the bug report! We’ll try it out in our official world space canvas scrollrect scenario this week when we port to 5.6p3 and will update if anything still seems off. Thanks!
I couldn’t say if it’s related, it’s been a year since I looked at this and I’ve forgotten all about it. Does it still occur if you change from clamped mode? Can you file a bug report please.
Sorry to bump but this is where I got in late 2021 with version 2021.1.26f1. So my problem was also with getting “nan” when scrolling beyond bottom-right corner of scrollrect only on android devices. It seems that unticking “inertia” fixed this issue for me:eyes:. When I make sure it’s possible to reproduce with 100% chance I’ll file bug report. Thanks to @methos5k for pointing this:)
Just wanted to say this seems to have fixed it for me too. It would constantly jitter around until it shoots to NaN.
NaN is harder to reproduce but I can very easily reproduce that jitter by scrolling down a tiny bit and swapping to something without enough content to scroll or just a different amount then swapping back. Ticking Inertia off fixed this. Would be nice to have Inertia but having something work is better.
I’ve run into a similar problem recently with the ScrollView getting NaN values and then effectively hiding its contents.
The problem in my case is Time.unscaledDeltaTime sometimes returns 0 values. Disabling inertia might help here as well as that at least prevents a division by zero in ScrollRect.cs.
I filed a bug report today, #1413700:
There’s a bug with Unity on iOS devices (and possibly others) whereby Time.unscaledDeltaTime starts returning 0-values when OnDemandRendering.renderFrameInterval > 1.
I’ve noticed it with Unity 2020.3.24f1 and 2020.3.31f1 on iPadOS 15.2 and 15.4 using Xcode 13.2.1 and 13.3 Presumably the bug is not limited to these versions. I just haven’t tested others.
The bug reliably starts happening after starting the app and then turning off the iPad screen for some time. 2 hours seems to do it, potentially 1 hour, and maybe less. When turning on the screen again Unity’s timing values start falling apart in various ways:
Time.unscaledDeltaTime starts returning 0-values regularly. On one run I got a burst of three 0-values about once per second, while on other runs all or almost all frames get 0-values.
Time.deltaTime average becomes roughly twice as big, though all rendered frames seem to have normal deltaTimes. Not sure this happens on every run.
Time.deltaTime never becomes 0, but at least once I saw 0.00001.
Setting OnDemandRendering.renderFrameInterval = 1 stops the problem. Setting it back to 5 starts it again.
Aside from all the other problems this can cause, it also most definitely screws up the ScrollRect component as its velocity becomes NaN when scrolling while Time.unscaledDeltaTime is 0. Its velocity being NaN then also makes its position become NaN which then effectively hides its entire contents with no way of getting it back.
One problem in ScrollRect.cs is this division by zero in LateUpdate:
if (m_Dragging && m_Inertia)
{
Vector3 newVelocity = (m_Content.anchoredPosition - m_PrevPosition) / deltaTime;
m_Velocity = Vector3.Lerp(m_Velocity, newVelocity, deltaTime * 10);
}
The ScrollView becomes completely unusable with OnDemandRendering while this bug exists.
Do you have have a link to the issue report, I couldn’t find it with your number?
Interested in the status, as we also ran into this issue late last year and had to disable OnDemandRendering on iOS.
And while your repro steps have hours of waiting, in our experience the issue happens in matter of minutes on certain iOS devices.
Unfortunately, I don’t. I haven’t heard anything from Unity in the three weeks since I filed the bug report and it’s still just listed as Open in fogbugz. I’ll try to remember to post a link here if and when I finally hear back from them.
Yes, that’s unfortunate. At least that wait time doesn’t require any action though, and perhaps it’s quicker to surface on some of your machines.
Regardless, it’s a complete showstopper for OnDemandRendering with ScrollRect so it would be tremendously helpful to have it fixed.
A simple bandaid is presumably to check in ScrollRect.LateUpdate if Time.unscaledDeltaTime is 0, and then not produce the NaN if that’s the case. Seems a lot better than having the entire contents completely disappear at least.