(IN-92796) Global shader variables _Time and _TimeParameters appear to be wrong

According to the Unity Shader Variables documentation, the variable _Time is supposed to represent the “time since the level was loaded” or UnityEngine.Time.timeSinceLevelLoad so to speak.

The ShaderGraph Time node documentation indicates that it uses _Time.y for its time calculations. After checking the shader code, I discovered that it uses a global variable called _TimeParameters.

The issue arises in Universal Render Pipeline (URP), where _Time and _TimeParameters do not reset when a scene is loaded. As a result, _Time.y does not reflect UnityEngine.Time.timeSinceLevelLoad, it reflects Time.time instead!

It’s worth noting that _Time.y correctly represents UnityEngine.Time.timeSinceLevelLoad when using the built-in Render Pipeline.

This leads to the question: Is the documentation incorrect, or is there a problem with the implementation in Universal Render Pipeline?

1 Like

Recently someone asked “How do i reset time in shader graph” and because I was sure the time should actually reset when scene is loaded I assumed for some reason that Time.time is reset on scene load.
Actually the reason might be the fact I use Time.time and _Time to create animations in my shaders (to find time difference), but you made me realize that I have two different pictures in my head xD

The question is whatever the case, how they plan to fix it? because it’s breaking change, I would need to update all my code to use Time.timeSinceLevelLoad, so would that be fixed in all previous versions or they are going to change that for next LTS.
I think they should change it, because without reset that number most likely loses a lot of precision over time.

1 Like

Yep, that’s my stance on the issue as well :smiley:

1 Like

Hi @Peter77,

can you please log this as a bug so we can address it?

Thanks!

It’s bug-report IN-92796

1 Like

The QA team successfully reproduced the issue, which can now be found here. Thank you for your quick handling of the bug report, your efforts are greatly appreciated! :clap:

I had identified this issue back in 2019 (URP 7), but figured it was just a fluke! Glad this is being addressed :slightly_smiling_face: