Why is the Time node affecting the UV’s in such a strange way, when setting up this simple panner:
It looks like the time node has scaled and lowered the resolution of the UV’s.
In my mind this setup should work, but it doesn’t. Can anyone tell me why?
Thanks for reading! 
Unless there is something I am not aware of, this is most likely caused by loss of precision.
With passing time, the Time node will produce higher and higher values and because of floating precision, when gradient is calculated there will be missing precision and at will look more pixelated.
If you are not familiar how it works, then simple explanation: you have some memory space to describe the number and if you need to store 0.00001, then you use all this space to store decimal places (number after dot), but if you need to do the same with 9999.00001, then you take some “space” to store 9999 and there is less memory to describe the latter, so high number lose precision.
So does that mean I can never use the time node again in this project? Is there a way around this?
Thanks for the answer.
It really depends on your use case. Normally you would need to wait at least few hours to get number big enough to affect the look, but it probably depends on noise scale too.
Personally I have never encountered this problem and I am not sure how to properly deal with it, but assuming precision cased this and it is visible after few minutes of play, then maybe wrap the time with modulo?
Find the maximum acceptable value and mod by it - something like mod(uv + time, 9999), so it “go back” to 0. There would be seam when that happens, but once per hour - I don’t think someone would notice. I recommend to research the problem in google.
PS. Not sure if Time node gets time from the start of the editor, but assuming it does, if you work in unity for few hours or even days, it might cause shader graph to look like this, but in real scenario game starts from 0.
I don’t know you found a solution but if you want to panning your texture, you should use “Tiling and Offset” node like here:
And I think if you connect time output directly to UV input of noise texture, you will control both of offset and tiling. So that’s why it is looking strange.
OP didn’t do anything wrong, Tiling and Offset node is just extra node for better readability and does literally this:
Out = UV * Tiling + Offset;
Additionaly your example adds UV twice, so you should omit ‘add node’ and connect time (Vector4) directly to the offset.
Uhh, OK, I see. I didn’t know this before. Looks like I’m continue learning new things So, tiling and offset node is useless in this case except if you won’t want to tile anything.
Some more on this topic:
No, it does not mean you can never use the Time node. But there are big caveats when using that node that you should be mindful of.
As @Qriva guessed, yes, the value the Time value the Shader Graph preview uses is going to generally be much, much larger than is likely to be seen in a real game session. The time used by the editor is the unscaled real time since the last level load, where as the time in the game is the scaled game time since last level load. This means opening a new scene restarts the time both in the editor and in game. Note: additively loading a scene does not restart the time.
As with most things in shaders, the precision is limited to a 32 bit float. 32 bit floats have a very wide range of values it can represent, but the larger the number gets the less precision it has to represent that number. This article is excellent at letting you get an idea of what kind of precision you should expect.
https://blog.demofox.org/2017/11/21/floating-point-precision/
A single day has 86,400 seconds. If we look at the graph in that link, that’s between 65536 and 131072, which means the Time is now represented by a value with a precision of 0.0078125. That might look like a fairly small number still, but that means it only has 128 steps between each integer value. That’s still double 60fps, so that doesn’t seem like it should be a problem for smooth motion, and indeed that doesn’t become an issue until just over 3 days have passed. But if you add that number to a 0.0 - 1.0 range UV, it only has 128 steps to represent the entire visible range of the UV!
And really it only takes just around 2 hours before the precision loss is enough to start seeing problems when using this for something like a screen space UV or on a texture that’s 1024x1024, potentially less for anything driving some kind of procedural effect like the noise node if you get close enough to the surface.
The usual solution to this is to use a frac(), or Fraction node, on the time so it loops between 0.0 and 1.0, and only offset the UV by that much. For something like the Noise node that doesn’t repeat you may need to fade between two sets of noise that are offset in time.
Thanks so much for the replies. This certainly cleared up things for me!