Wind Shader Graph Glitch

[short lark]

My wind shader graph causes sprites to jitter when the player moves near them.

This happens regardless of whether or not the camera is moving.
The only solution I’ve found is having the sprite with the wind shader and player on different layers. (I need them both on the same layer for sorting) Any help/advice would be much appreciated.

Attached is a sample of this happening, the wind shader, and my camera settings.

[granite field]

I can't see any reason the player would affect the jitter in any way.
Maybe the jitter happens regardless, and you just don't notice it when there's no player around/point of reference?

Unless the affected objects are parented to the player or move relative to it via code or something.

[hearty river]

I can imagine it has to do with atlasing and the object space, but not enitrely sure why changing the layering would fix that issue.

[short lark]

That's what I thought but the jitter doesn't happen at all unless the player has SpriteRenderers enabled and is moving, without the player moving the shadergraph works as intended with no jittering

[short lark]

They don't move with it via code either

[short lark]

I think it has to do with the object space as well but still at a bit of a loss as to how I could change that, not sure if there's a work around I can pull in the shadegraph itself or what

Through further experimenting I found that the player doesn't even need to be moving either simply existing in the world is enough for the shadergraph to break, here's some footage of that with me toggling the player on and off

[shell turtle]

Is this in Play mode?

[short lark]

Yes! I also just figured out that turning off the player's animator seems to cause the shadergraph to work as well I'm wondering if it has something to do with the squash and stretch animation I apply to the player sprite still not sure how that is impacting the shadergraph though

[shell turtle]

Which editor version

[short lark]

2022.3.42f1

[shell turtle]

That version of URP does use dynamic sprite batching, and I can't imagine what else it could be related to

[short lark]

Removing the squash and stretch animation from the player seemed to have fixed it

I have no idea how

[shell turtle]

I'd try to get per-sprite UVs without relying on object space
Cyan's methods: https://www.cyanilux.com/tutorials/sprite-local-uv/
Remy's method: <#1395161169379201115 message>

Before that could also swap to deformation using world space

If the error persists there it would point away from it being a dynamic batching issue
But then it'd be even less certain

[short lark]

Hmmm alright I'll look into these two methods thanks again for your response the second method uses the same tutorial as the one I used so hopefully I'll be able to get some headway with it!

[shell turtle]

Let me know what seems to fix it (or make it worse) if you find some more clues

[short lark]

Remy's Method #1 Object Position:
Applied the script to the affected sprites and changed the basic UV nodes to the adjusted branch they created, results are the same. (They use a custom pivot variable and when I change that from anything but 0,0 the sprites get way off balance and jitter a lot more)

Going to try their second method with world aligned local UV shortly.

[shell turtle]

In this case since we suspect object position is the issue you want to prefer the techniques that don't use it
Per-sprite UVs primary use is to get uniform sprite UVs regardless of the sprites being in a sprite sheet so they can rely on object space

As dynamic sprite batching is not used in modern URPs so there's no need to avoid object space

[short lark]

Remy's Method #2 World-Aligned Local UV:
So I was able to revert the UV's back to basic UV nodes and changed the input of the object's position to this block that was posted on Remy's tutorial. At first it seemed like it didn't work but when I changed the comparison node to "Equal" it actually seemed closer to what I was looking for (albeit sprites are now out of position and their size is wrong).

It's closer but still a bit messy. I've adjusted the comparison to every option aside from "Equal" and it seems to just make the sprites spazz out aside from "LessOrEqual"

[short lark]

And yeah that makes sense I suppose I was just curious if I went about using the object space incorrectly

[shell turtle]

Good thing to test, certainly

[short lark]

So since the shadergraph was built with object space in mind I suppose I'm a bit lost as to how I could adjust the object position/scale to match the use of the world aligned local uv position

[shell turtle]

@short lark Oh, one more thing
You're using the Time node, which keeps running while the editor/application is open, so it can run into floating point inaccuracy issues

That's what the jitter looks like, as gradient noise at very high UV values gets "crunchy"

But it typically happens when you're also multiplying the Time, and it shouldn't be related to dynamic batching

[short lark]

Hmmm so what should I change it to? I can try and mess around with it and revert the graph back to object based positioning since world based positioning seems more stable but it shrinks/moves objects out of place for some reason

[shell turtle]

Usually you want a custom time (global typically) variable that's incremented in a script, which gives you control over it
Iirc Frac node may also eliminate the accuracy error, but also causes a jump because the noise is not repeating

I'd recommend Frac as a test but I'm not sure if it actually fixes that issue so it might not be too empirical
Then again, it might fix it

[short lark]

Sure let me try using a fraction node on the time first and if that pans out with the object based pos I'll look into running a custom time variable!

Hmmm it's a bit hard to tell with how short the loop is but I think the jitter is gone while using frac, going to try and run a custom time next

[shell turtle]

Another option is to do the opposite; multiply the Time result with some values, see if the specific jitter you see gets worse

[short lark]

It looks a little worse but it might also just be because the wind effect is amplified really not sure honestly, going to try and implement the custom time now though not used to linking variables through script to shadergraphs so it might take a moment lol

[shell turtle]

Hmm, not worse enough to really confirm it

[short lark]

Success! Seems like setting a custom time was all that was needed to stop the jittering nice prediction and thank you again for your help! I noticed that it looks like it needs to be called on every object though (the bushes in the background don't have any scripts on them so they aren't effected by wind despite still having the shader) the shader is a child of a parent so I'm going to have to find a way to set it so it impacts all of them like the time node had

[shell turtle]

Oh good!
You can use global properties to have one script control it

Something like Shader.SetGlobalFloat, and the property needs to be not "exposed" in SG

[short lark]

Ohhh alright let me try and adjust that, fingers crossed I sort of have been overlooking this little visual bug would be awesome to finally be rid of it

[shell turtle]

Why the player sprite or its animation affects it defies my reason

Artstyle is nice btw

[short lark]

Thank you so much! And it looks like you hit it on the money, all the sprites are getting updated now and it only needs one call from a single fixed update script. Thank you so much for your help so glad to have this nipped for good lolol!!

[shell turtle]

Awesome!

[short lark]

IT CAME BACK I'm not sure how just was messing around and it returned weird thing is even if the time is set to 0 it still jitters I'm very confused atp

[short lark]

still not 100% but having half of the sprites update the custom time through script and having the other half rely on a global variable update seems to reduce the sprite jittering a decent amount, still pops in every now and again but not as much... going to classify this as semi-solved not perfect but satisfied enough with how it seems to have panned out