Shader Graph Shader breaks after putting sprites into Sprite Atlas

[deep hawk]

Hi, I've been having a problem where my shader no longer works after the sprites involved were put into an Atlas. Pictured is the shader graph in question

I can take a pretty good guess at what the issue is, but what I don't understand is how to solve it. The shader gives the object a pulsing motion but in the atlas, the pivot seems to be off centre so it doesn't render correctly

I figure if I were able to access the exact location of the centre of the sprite on the atlas, I might be able to make it work, but I'm not sure if there's a way to do that?

[gaunt needle]

https://www.cyanilux.com/tutorials/sprite-local-uv/

[deep hawk]

Well my concern with this is that I'm not sure if it hurts performance or not to add a c# script onto the bullets individually

For one of the other methods, I also have a concern about this. Is it to say that I can't rotate the sprites?

Man idk why sprite atlases and shader graph work so terribly with each other to begin with, and even if I somehow get through this one I have to figure out how to make it work with different materials from the same shader

[dense kiln]

You can, but the UV coordinates don't rotate with it

[deep hawk]

What does that mean for the game? Would there be any problems caused?

Like if the pivot was off centre or something?

Though when I tried it it just showed the entire spritesheet in the centre of the screen only when a bullet was over it

[dense kiln]

The bounds are a box that encompasses the sprite mesh
That means the bounds UV will be at the middle, even if the sprite's pivot was offset
So rotation using those UVs ignores the pivot

And because it's world aligned, moving the texture for example horizontally will still move it horizontally even when the sprite rotates

[dense kiln]

That's entirely relative, but generally speaking not a problem until it's a problem
And when you have so many bullets it is a problem, you can update these properties from one script for all of them in one loop
And pool them too

[deep hawk]

Well, I do have an object pooler script so the bullets are all pooled

[dense kiln]

Because the pool keeps track of the active bullets to begin with, it makes it easier to run these methods for them in one go

[deep hawk]

That makes sense

Though that link has an equivalent solution for shader graph and when I tried that it didn't produce the result I was looking for

[dense kiln]

Hard to guess what went wrong
Note how the solutions work differently based on unity version, and what other requirements they have

[deep hawk]

I'm using version 2022.3.62f1 so some of these are later than my version

So I could add this script to my object pooler?

I apologise if I'm not interpreting these things correctly I'm just getting very very burnt out and taking in so much new information

[dense kiln]

You can, though better to test it just on one sprite first without the pools or loops, if there's any uncertainty about how or if it'll work

[deep hawk]

I just figured something like this should be easy to do or already built in

[dense kiln]

Remember the brain is functionally a muscle, even the light weights become too heavy when you've been lifting the heavy ones enough
And this stuff gets very difficult unless you're feeling keen enough to not miss any details

[dense kiln]

Sometimes very complex things are easy out of the box, and sometimes very simple things are very complicated
You never really can bet on it

[deep hawk]

That's true, but I'm sorta already behind on my own deadlines

[deep hawk]

Yeah I just don't know if it's worth it. I'm doing all this just to optimise the game enough so more people can play it hopefully

It works fine if I give each component of the bullet a simple material with no animation so my idea was to just have that be something the player can toggle on a performance mode of some kind

Since that allows the bullets to batch correctly. I just don't think I'm capable of much more than that in my current state

[dense kiln]

If you're optimizing you have to be optimizing specific measurable performance issues
Whether you're updating shader properties of the material instances of the bullets, or doing the pulsing animation by changing the bullet transform scale, as long as it's all in one loop the performance cost might not even be measurable

[deep hawk]

Yeah I understood enough from my findings to know my laptop was having trouble due to the draw calls taking 30+% of the CPU which is why I went to try and reduce the draw calls

Do you think it'd hurt performance if I changed the scale of bullets to create the pulsing animation?

I was thinking I could do it in the parent but that'd probably pull them all towards a certain point on the screen and would have other issues when I change parents for certain attacks

[dense kiln]

This doesn't necessarily tell you why the draw calls are taking a lot of time nor if there are more of them than expected
And if draw calls are the issue, setting material instance properties is unlikely to help because without sprite SRP batching (which your editor version doesn't support iirc) that would split all your sprites into separate draw calls

[deep hawk]

Is that so? Because at first the pattern I was testing on was hitting around 700-800 draw calls but after sorting it it went down to under 170

[dense kiln]

The sprites probably are using (or attempting to use) dynamic batching, or similar

[dense kiln]

"Sorting it"?

[deep hawk]

Oh, yeah I forget which reason it gave for why two of the three components of the bullet wouldn't batch

[dense kiln]

Modifying the transforms will not affect draw calls or rendering for better or worse

[deep hawk]

It was something I got help with a few days ago on the server

I see

So if I added to the bullet pooler to change each transform based on a sine wave would that not be so bad for performance?

[dense kiln]

Typically batching of draw calls is prevented by having a differing shader or material

[deep hawk]

Yeah I ended up only getting it to work when I set all the materials to the same and put them on an atlas

[dense kiln]

Likely fine
Beyond a single loop there's ways to optimize that too, but unlikely going to be needed
The performance issues to optimize are the performance issues you have

[deep hawk]

That RenderLoop.Draw was over 30% with a lot of calls

I have other ideas already written down for what needs to be optimised

Such as another object which could very easily be pooled

[dense kiln]

When modifying the transform for animation purposes, you typically want to modify a parent transform or a child transform so you can separate the animated motion from everything else the gameobject needs to do
That relationship also allows you to basically give it another pivot by offsetting them

So if now you have a gameobject with a sprite component, which you might need to reparent or modify its transform for gameplay purposes, so you don't want to override the same transform for animation
You might instead move the sprite to a child transform and animate that

So whatever gameplay related transform modification you do on the parent happens entirely separately from the child transform motion which has the sprite

[deep hawk]

Hmmm I see, so with this, these are the three components of each bullet which is 3 sprite renderers

Are you suggesting making all 3 of these objects the child of another?

[dense kiln]

Yes, either moving the sprite renderer of the XBullet to a third child gameobject
Or that but also parent the two to the new third
However you want the transform's motion to be inherited

[deep hawk]

I'm just worried bc that would increase the amount of objects associated with bullets by 33%

[dense kiln]

Transforms are incredibly cheap

[deep hawk]

Though I'm sorta thinking it through in my head rn but maybe I could still make it work without having to do that, though it might be janky

Yeah but entire game objects?

[dense kiln]

A gameobject is just a transform + optionally whatever else components

[deep hawk]

Although tbf it's good to hear that transforms are cheap. This being my first Unity game I have no idea what is and is not expensive

I was just wondering though if the XBullet has a multiplier on the pulse intensity, I could maybe set a negative value for the other two objects to hopefully still make the animation work

Which could eliminate the need for an additional object

If that makes sense

[dense kiln]

Transforms are likely to be the absolute smallest of your worries
So not even worth thinking about before you've measured the difference

[deep hawk]

Hmmm alright

[dense kiln]

If you've got a thousand of those bullets then I expect it might be tangible
But then you've got bigger performance concerns from the actual components on them

[deep hawk]

I guess this might be more of a question only I can answer maybe but bullets come in different sizes so that intensity value might need to change depending on the size of the bullet too

[deep hawk]

Yeah they max out at 2000

Couple moments in the game break 1000

[dense kiln]

With those numbers I think the performance of monobehaviours doesn't scale all that well
So it helps to understand how they really are managed in memory and otherwise
And how the renderer batching methods precisely work

For doing a lot of operations and having a lot of objects, Burst and DOTS are tools designed to help
Though I'm not familiar enough with them to say outright which situations calls for them

[deep hawk]

I see. I'm not sure I've heard of those

Well, I thank you a lot for your insight and your suggestions. They helped a lot. I think I'll do the transformation thing instead of the shader

It might be too late for me to look into extra tools so far into the game