Seeming disconnect between material and shader properties

[sinful mist]

Okay, so, I'm working on an invisibility shader right now, and I have a simple distortion effect that is animated over time. It is controlled by time and a speed property. When I set the speed to 0 in the shader itself, in the preview the shader stops as expected; however, when I apply the shader to a material, and then change that same value in the material, it doesn't control anything. Weirdly enough, the other properties changed in the material do have an effect on things, but this specific one doesn't. What could this be caused by? The player uses the shared material, so it shouldn't be some kind of instance issue. And no, its not supposed to jitter that hard, thats why I need the speed to work properly xd

In the videos you can see how changing the shader variable works as expected, but in the material it does not, but changing a different one works fine

Could it have something to do with the preview being a static sprite and the game version being an idle animation?

[sly adder]

Show all nodes and the renderer component of the character

[sinful mist]

the graph to png thingy died a bit but Ill send the broken part separately in a sec

[sly adder]

The most obvious thing could be that since you're using the Time node, it counts up forever when the editor is open and can overflow and become glitchy, especially if the result is multiplied

[sinful mist]

does that mean that it can happen in-game too after a while? xd

[sly adder]

Yes

Restarting the editor should reveal if that's the only contributing factor

[sinful mist]

alas, doesnt seem to be it xd

fresh restart and the same thing happened

[sly adder]

Using custom time variables (or one global) from a script avoids overflow issues and is more controllable

Another potential issue is the use of sprite renderers and objects space
The shader graph preview is on a 1-unit quad, but your sprite renderer could be of any size depending on PPU or inherited transform scales

Sprite batching additionally may change object space entirely, erratically

Because it's shared between batched sprites

[sinful mist]

dont think its an overflow, I tried linking to time.time directly through code and it still did the same thing, even though the values look fine

[sinful mist]

probably this one? I tested the sprite size and it affected other aspects of the shader but this issue peristed regardless

Is there something I could do to mitigate the issue with batching?

update: it is in fact the animation/sprite batching issue

turning off the animator makes the shader work fine, but as soon as its on it breaks down xd

uhhh not sure what I could even do there xddd

[sly adder]

Are your animations from a sprite sheet?

[sinful mist]

yeah

[sly adder]

Your distortion is also using texture UVs, which jump around when the sprite is swapped because it's on a different position on the sheet

If the noise is applied on the sheet, the noise will be different for each sprite on it

[sinful mist]

oooohhhh

💡

[sly adder]

So that suggests object space is not an issue
If you're using URP I believe it might use SRP batching instead of sprite batching so object spaces are not rearranged after all

If so, you could use two of object position axes (or of world position) to sample the noise texture instead

Or alternatively use one of the methods to get a per-sprite local texture UV
https://www.cyanilux.com/tutorials/sprite-local-uv/

[sinful mist]

eh, I tried switching the two position nodes here to the second method from the link (tried the first and had a weird offset issue phh) and the issue still persists

nvm, forgot to plug it in one extra spot

it finally works

thank you Spazi youre on that king/queen/uhhh enbeen? grind