Help with ScrollRect script and scaling (causing NaN) values on Content portion

Does anyone have any suggestions or help / ideas on how to resolve the ScrollRect (script) from causing the content [panel/portion] to get NaN values when scaling?

I have tried my own scaling + positioning script, as well as Unity's 'scale by screensize' component.
Both cause this to ruin the Content portion of the Scrollview (setup of things).
Took me a while before I tried, but just disabling the scroll rect script prevents the problem from occuring, so I am fairly confident that the issue lies there.
I am stumped.

I'd appreciate any help

 

I'm having this exact same issue.

My project in Unity 5.5 had some scrolling content using ScrollRect that was working flawlessly, unfortunately now in 5.6 it is running into this NaN issue that you mentioned.

I did some digging on the forums and it seems like a number of people are having this issue. Maybe it's a Unity 5.6 bug?

 

Edited my previous response that said I thought I had it fixed.
I have further tracked the bug down, it seems that using "Clamped" as the movement type will produce the NaN issue every time. Unrestricted (which I only tested for a few moments) seemed to work, as well as Elastic.
I would really prefer the clamped option, because I think it looks and feels better, but I can't have the ScrollRect messing up, either
I'm going to investigate & test more.
If all goes well, I may try to implement a shift to Clamped when scrolling begins and revert when it ends until if / when this bug is resolved (provided this fix continues to work, as I test)..

Small update: It seems I can even set elasticity to 0 (zero) and it works, without errors. Which is both amazing and hillarious.
Will keep testing. =)

*Edit: Tested many times with all sorts of scaling and everything continues to work properly!

 

Thanks for the response, setting the ScrollRect to anything but Clamped seems to be helping. I'm not longer getting NaN values for my content. Now I just have to figure out this error:

NullReferenceException: (null)
UnityEditor.SerializedObject..ctor (UnityEngine.Object[] objs, UnityEngine.Object context) (at C:/buildslave/unity/build/artifacts/generated/common/editor/SerializedPropertyBindings.gen.cs:87)
UnityEditor.Editor.GetSerializedObjectInternal () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:193)
UnityEditor.Editor.get_serializedObject () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:185)
UnityEditor.MaterialEditor.OnEnable () (at C:/buildslave/unity/build/Editor/Mono/Inspector/MaterialEditor.cs:1773)

From what I've read on other posts, this error is in the Editor itself. It seems to only trigger on one specific game object (the content in the ScrollRect I mentioned above), so I'm trying to see if I can rebuild it in a way that the error doesn't trigger.

I'll report back, thanks again.

 

Hey, cool, glad you got yours working , also. I haven't done much more since earlier, but I am happy to have a sort of fix for now, until if/when 'Clamped' gets patched
As for your error, unrelated I think to the original problem.. but I am getting that, too! hahaha. Really have no idea what it means, but it doesn't seem to be really, really bothering me
Would be happy to hear if you ever find a fix, though

 

Thanks I'll definitely keep you posted. My actual scroll bar doesn't seem to be working anymore either, so what I'm going to try next is disabling my current objects and rebuilding my scrollable space (ScrollRect, Mask, Content Panel, etc.) to see if I can avoid the error. If rebuilding it avoids the error, depending on the complexity it may be the better way to go. x.x

Mine isn't super complex so I'll rebuild it and get back to you.

Small Update: Just realized I still had NaN values in both my scroll bar and handle for my scroll bar, those have now been fixed. It seems like the scroll bar is now working (with the ScrollRect). I'll update again once I've played it with a bit more.

 

Oh no! Sorry it stopped working. I hate when I think I have something figured out, and it breaks down.. Though I did do a number of mini tests with my scroll rect. How did yours fail you, if you don't mind my asking?
For me, the error is just a mild nuisance right now; my entire scene is just that + 1 resizable panel lol. I like building things like that, in an empty scene/project

 

After I removed all of the NaN values I didn't notice at first, it looks like everything is working! I'm not seeing that other error anymore either, although I guess it could come back haha.

Yeah I'm not a huge fan of having it set to Elastic but it'll do for now, I'm just glad it's not broken anymore.

To answer your question, the NaN values were causing a bunch of stuff to not work (scroll bar, scroll bar handle, mask, etc.)

All fixed now though! Thanks again for posting this.

 

Ahh okay, awesome That's good to hear.
As for elastic .. setting it to zero and disabling inertia is very close to the clamped act & feel. I, too, would prefer Clamped, but we do what we have to do for now
No problem, btw.. it started out as my own problem that ended up helping us both lol

 

Yep it sure did haha. It's close enough to Clamped that it's not a big deal at the moment.

 

I believe the problem is only with a Canvas using an orthographic camera for "Screen Space - Camera".

Steps to Reproduce:
1. In new scene, create a TMPro Dropdown.
2. Create a new camera
3. Set new Camera Projection to Orthographic
4. Set Canvas Render Mode to Screen Space - Camera, linking to new camera
5. Press Play and see the NaN bug on the Dropdown Content transform.

What's weird is this bug doesn't happen if you do the above steps but instead of making a new camera, you change the Main Camera to Orthographic and link that.

So the workaround for me is to change my UI Camera to Perspective. This way I don't have to fiddle with the clamped scrollbar stuff.

Update: Okay never mind, toggling Perspective/Orthographic only fixes one of my dropdowns. Another seemingly identical one can only be fixed by changing Clamped to Elastic??

 

That sounds partially related, maybe. I believe my setup was : orthographic and screen space overlay.
I was only using the scene to work on a couple of UI items; so I never really thought of the rest of the setup as part of the issue.
Did Elastic solve it for you, as well?

 

Same problem here, except I do not make changes to the scale of any object.
I rebuilt an empty scene with a scrollrect + container and two children images.

Issue only arises with the following conditions :

• Canvas Render Mode : Screen Space - Camera
• ScrollRect Movement Type : Clamped

As per my tests, it doesn't matter whether the Camera is set to Orthographic or Perspective.
As soon as I change the ScrollRect to Clamped, the Container RectTransform's Position goes nuts (aka NaN everywhere).

I tested every other combination and those are always working for me :

• Screen Space - Camera & Elastic or Unrestricted
• Screen Space - Overlay & Any ScrollRect Movement Type
• World Space & Any ScrollRect Movement Type

Tested on Unity 5.6.0f3 on Mac OSX 10.11.6, iOS Platform

I can't think of any way to fix this, can't afford to change Canvas Render Mode or ScrollRect on my project so switching to Unity 5.5.3 until it is fixed by UT.

Edit : added precisions about the issue not being related to scale in my case.

 

Before seeing some posts talking about different camera options, I had not ever tried those.
On a couple of quick tests, perspective/orthographic made no difference to me.
One difference between your tests @ErwanB and mine is that Screen space overlay and movement Clamped always gives me issues (to clarify, by always I mean if I scale it down. This problem doesn't happen at all sizes/scales to begin with).
It's all good and working in Unity 5.5.3 for you? That's good, at least.

 

To be honest, I missed the part about scaling. All my ScrollRects are at nominal scale and I do not change their scale at anytime. Still they broke all the same. I've edited my previous post to make that clear.

Concerning 5.5.3 :

• Upgraded from 5.5.0f3 > 5.6.0f3 : broke everything
• Upgraded from 5.5.0f3 > 5.5.3f1: all good

About scaling, I'm not sure I get what exactly it is that you're doing and that is causing the problem even with SS-Overlay. Updating scrollrect's scale at runtime ? Changing Game view resolution ?

 

Yeah, that was my personal issue when I began this thread before I knew the whole problem/work-around.
I was building a ScrollView/Rect inside a panel that can resize; and whether through my own script or the canvas scaler option, at a certain point the Content portion of my ScrollView would get those NaN errors.. At full scale it didn't happen, at least one the size I was using, etc.. If that makes sense.

 

Hey everyone, I've been harping on this issue since it was introduced in Unity 5.6 beta 2. Here are some of the bug's i've submitted, help vote them up so they are addressed quickly.

https://issuetracker.unity3d.com/is...d-via-script-and-canvas-is-scaled-to-0-dot-01

https://issuetracker.unity3d.com/is...freezes-game-view-when-using-fixed-resolution

https://issuetracker.unity3d.com/is...en-changing-scroll-rect-position-can-not-undo

The first one is not related to things being created by script, I was reproducing it regular way and that way but the creation-by-script helped show there wasn't any carry-over meta information from the game objects.

The dropdowns freezing in screen space camera is directly related to the scroll rect content NaN issue

The last one someone else filed with the scroll rect viewport getting NaNs, they claim it's fixed, but I don't think its in the official release, could also not be related.

Hopefully it'll be addressed sooner now that more people are having issues with 5.6 being live.

 

Good! Upvoted open issues!

Unfortunately I don't have much time to investigate more on this, just want to share another case I've tested :

I created a new canvas/panel/scrollrect with Screen Space Ovelay and Clamped => Works fine when scaling the panel that contains the ScrollRect.
Then I switch Canvas to Screen Space Camera => Breaks ScrollRect's container's transform
Switching back to Screen Space Overlay => Still broken.

So if using Screen Space Camera, I guess you could switch Render Mode on your canvas before upgrading your project to 5.6 to avoid it breaking your transforms. That is if you are OK with using Screen Space Overlay or World Space until it's fixed by UT.

 

I found if you set up the dropdown on a canvas where the Render mode is NOT set to Screen Space - Camera, you can adjust it, set it up, then switch Render Mode to Screen Space Camera and it works.

 

Really messes up our UI in 5.6f3

 

@karl_jones glad to hear! Please push for this to get patched out asap!

Are you able to confirm if this will also solve the screen-space-camera Dropdown's scrollrect's NaN issues (Bug case 893585)?

 

Very cool.

 

The King!! We'll test it asap

 

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!

 

Code (CSharp):

1.  
2. NullReferenceException: (null)
3. UnityEditor.SerializedObject..ctor (UnityEngine.Object[] objs, UnityEngine.Object context) (at C:/buildslave/unity/build/artifacts/generated/common/editor/SerializedPropertyBindings.gen.cs:87)
4. UnityEditor.Editor.GetSerializedObjectInternal () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:193)
5. UnityEditor.Editor.get_serializedObject () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:185)
6. UnityEditor.MaterialEditor.OnEnable () (at C:/buildslave/unity/build/Editor/Mono/Inspector/MaterialEditor.cs:1776)
7.  

Perhaps I am missing something obvious.
Changing the overlay render space didn't fix it
Changing the elasticity had no effect

I don't see anything blindingly obvious around https://github.com/Unity-Technologi...Editor/Mono/Inspector/MaterialEditor.cs#L1921 so I am wondering @karl_jones if this is the same error?

 

@karl_jones

It sadly does do it in clamped and elastic.
Okay then, thanks.
BUG 1060776

 

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. 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.

Thank you for your attention.

 

I haven't as I'd already spent enough time debugging the problem and creating the minimal test project and bug report at that point and just wanted something that would let me move on without requiring more work and maintenance.

So I disabled ODR while a ScrollView is showing, which was not a serious drawback in that app. It presumably will be for another app I'm working on though, so maybe I'll have a reason to revisit it.

Or more likely I'll just disable ODR completely on iOS until I hear the problem is fixed. But yes, it would be great to not have to do that as I love the intended functionality. It's just not very reliable yet.

I just noticed another ODR bug I filed back in August 2020 is now finally fixed in Unity 2022.2.X, https://issuetracker.unity3d.com/is...t-renderframeinterval-value-causes-flickering. As it's not mentioned in the issuetracker, I'm guessing this fix will not be arriving in 2020.3 or 2021.3?

Anyway, I'm hoping the more serious nature of the current bug accelerates the arrival of a fix.

 

Good news everyone!
I've gotten feedback on this bug report now.
https://issuetracker.unity3d.com/is...ing-ondemandrendering-dot-renderframeinterval

They've already fixed the bug in 2021LTS, and will now be trying to backport it to 2020LTS as well.

Likewise for the other ODR bug they fixed in 2022.2.X. That one is now "Planned for 2020.3.X, 2021.3.X, 2022.1.X" as well. What a joy!