Argh both those warnings should be harmless but I'll fix them up!

I wrote them all myself, I tried to follow how Unity's own shaders handle lighting plus also tried to keep them easy to read - mostly to remind myself of how everything works! (Haven't had too much experience with shaders and went in circles a couple of times with different vector spaces etc).

I was planning on putting them up on the asset store for free, they should be usable with any sprites not just Spines.
Definitely could add to them though - having an optional ramp texture would make sense and be easy to do so you can have toon shading, might try sticking it in

Hey no one knows a way of disabling passes in a unity shader using defines / tags or something do they? That what's currently stopping it being a single .shader file.

Ok I've updated the shaders in the first post to fix those pesky warnings and also chucked in an optional ramp texture for diffuse lighting (untested!).

Yeah its annoying about per pixel lighting, but to be honest if you use actual meshes for your Spine sprites with a decent amount of verts, vertex lighting doesn't look bad at all, especially with some decent normal maps. My bad with the zSpacing recommendation - my games units are pretty big for some stupid reason.

With regards to disabling shader Passes, I've looked around on the Unity forums and found 3 people asking the same thing.. and none of them got replies. Its weird would've thought it would be easy for Unity to support as it fits in with there 'one uber shader' thing. Behind the scenes multiple cg shaders are being generated anyways so its more just cosmetic ie in the unity editor you'd only seeing one sprite shader instead of the three.

Yeah theres not much documentaion for the in build shader stuff unity uses behind the scenes - the only way I found stuff was by digging through the source files for there own shaders which are hidden on the Unity site somewhere, it's pretty messy though!

I've since updated them locally to allow you to use sorting layers which is super usefull with sprites, I will share it once I've tidied it a bit.

I'm still not happy there's a few 'if' statements in the shaders which I remember a graphics programmer dude I worked with saying is bad for performance (although unity seem to use them themselves) but glad they're helpfull - can definetly nab bits if you wanted to make bump map support build in to the Spine Unity runtime or whatevs.

Cheers for fixing those tangents bugs btw!

Hmm thats really weird! Is that with vertex or pixel lighting?
Its not the tangents being the wrong way round is it? Actaully nah that would effect all lights. Huh. I did try and copy most of that stuff from Unity's standard shader, I'll have another look to see what could be wrong!

Yeah vertex lighting does no if statements in the fragment so should be ok. The pixel lighting does but I think there's a way of multiplying out each branch instead if you know what I mean? Def more stuff that could be looked into!

Yeah for some reason the forum doesn't allow you to post .unitypackages as attachments so I zipped it up

With zSpacing, the mesh parts needs to be spaced apart enough to to stop z fighting but not too much to be visually noticeable, its worth playing round with values as it depends on your game scale, the value I said originally is prob way to big.

@Pharan - I've noticed the point light bug only happens when you don't have a normal map, with one its fine :/
I'll investigate a bit more!

02 Mar 2016, 16:23

Ok think I know whats the light z problem is! The problem comes from the fact the shaders have culling turned off so you can see both side of the mesh (meaning you can easily just rotate the sprite 180° to have them walk the two directions with a single animation).
However! Even though the sprite is rendered on two sides, there's only one set of normal's which are only valid when the sprite is facing forward. Hence lights only working on the correct side.

I've turned on back culling on the lit shaders which means you shouldn't be able to to have meshes with incorrect normals / lit wrong. This obviously means looking at a sprite from the back wont work but you should be able to flip the x scale instead to mirror animations etc.

I've also added a slider for render queue so you force sprites to render in a particular order! (Both are in the updates zip file in the first post)

Yep its the vert winding order is what makes a face front or back facing.
The trouble being a vert can only obv have one normal so when if you're not culling the back face your in essence using the same vert twice for the two faces, even though they're only one normal which is only going to be pointing out from one of the faces, so the back on will be lit incorrectly.

Because of that all Verts in Sprites should always be winded in the correct way so the triangles are front facing (in Unity I think its clockwise) and with the normals pointing towards you when you look at the triangle.

Hey am I right in thinking the verts are rebuilt every frame for a Spin Skeleton in Unity?
Cos I think ideally you wouldnt ever use a negative scale or rotation to flip an animation, but rather generate the vert positions flipped on an axis somehow, maybe with a flag?
So like you could just set a flag on the SkeletonRenderer component to tell it to generate verts flipped horizontally or vertically? Would that make sense?

Ah that's awesome! Yeah sorry I'm still very new to the API, been mostly learning editor stuff.
I guess I assumed there wasn't a flag already just because there no way of setting it in the editor / on the component. I need to place flipped sprites in the scene view hence flipping them using a negative scale. Can write a wrapper or expose it easily enough though..

Anyways to answer your question!
No I think as long as the normals are correct then it should be ok. From what I saw when looking at the shader code, its only the vertex and normal that matter when lighting, so if they're right should all be good.
Its a bit confusing having normals not matching the winding order of the faces they're for, or having a mixture of different winding orders in the model, but yep should be lit fine (I think!)