ToddRivers, maybe you could use GitHub or even a Gist? Then we'd have a history of your changes, which would help us keep the runtime copy up to date.
Sprite Shaders for Unity
Although, worst case scenario: I just need to make a blank Unity project, version control that somewhere, and just check the resulting changes every time I update to ToddRivers' latest package.
Yeah let me stick them in a GitHub depot quickly, that makes the best sense and it's something I should've done ages ago (I've just been checking them in my games own git depot).
14 Nov 2016, 14:04
Ok here you go: https://github.com/traggett/UnitySpriteShaders/tree/master/SpriteShaders
I'll put a link to it in the first post too.
I also realised the pixel lit shader wasn't calculating non important vertex lights in its base pass! I never use them so never noticed but thats now fixed
ToddRivers wroteI also realised the pixel lit shader wasn't calculating non important vertex lights in its base pass! I never use them so never noticed but thats now fixed
I'm going to use them a lot with bump mapping instead!
A thing that could be missing would be a normal map intensity multiplier, to better fine tune the bump, or to create effects like transitioning to 3d-like to fully flat texture.
I'd do that myself, but would end up with having to make that change on every update, would it be possible to have this feature in the next shader versions?
I think a multiplier (or a color where applicable) could be handy to fine tune the influence amount of other textures in the shader.
Of course, to give some artistic freedom, there wouldn't be any need to clam or limit the value, so a simple float(also including negative values) would be more than welcome
@[deleted]
Can I ask how you create your normal maps for your spine animated art? I'm looking at using Sprite Illuminator and am looking for any tips / guidance in regards to creating normal maps for a spine animated character. Are you just painting the normal of the packed texture that Spine exports?
rxmarcus wrote@[deleted]
Can I ask how you create your normal maps for your spine animated art? I'm looking at using Sprite Illuminator and am looking for any tips / guidance in regards to creating normal maps for a spine animated character. Are you just painting the normal of the packed texture that Spine exports?
I was using the same tool (trial edition) but I think I'll be using this http://www.2deegameart.com/p/sprite-dlight.html
Hey is anyone using the Unity 5.5 beta?
I'm trying it at the mo and for some reason with these shaders the Fixed View Space Normal now needs to be flipped in Z (so (0,0,1) instead of (0,0,-1).
No idea why this would be the case :S
17 Nov 2016, 16:49
Ok looking at the upgrade guide it seems Unity has flipped the Z Buffer direction (so 1 is at the camera and 0 is furtherest away).
https://docs.unity3d.com/550/Documentation/Manual/UpgradeGuide55.html
and this is causing it.
Is #if defined(UNITY_REVERSED_Z)
a Cg directive?
Ooh thanks, I hadnt heard of that define but using it did the job!
Default directx mode must've changed in 5.5 so now UNITY_REVERSED_Z is true.
Will check in a fix for that in github!
I'm trying to make the Spine version defaults Spine-friendly.
I'm mostly done.
But how do I make it so that "use mesh normals" is false by default?
I saw the conditionals and I got super confused. :p
@[deleted]
ToddRivers wroteHmm thats weird. The spike is happening when its first setting that shader for use I think. It could be caused by the Unity running out of shader keywords (the defines used to turn shader features on and off, these shaders now have a fair few of them to allow you to switch all the feature on/off).
At the mo I think theres a 64 keyword limit but its going up to 256 in Unity 5.5 so that might fix it!I've uploaded new shaders that improve the fake spherical harmonics in vertex lighting mode. Should be a lot faster and look a bit better too
Thanks man you're awesome! Been busy recently, so haven't had time to play in Unity, but will let you know how it goes when I do. :beer:
@Pharan Sorry for the delay. I've just checked in an update to the shaders that cleans up a few editor things and it also adds a new function called 'SetDefaultSpriteKeywords'.
All you need to do is uncomment out the line that says //SetKeyword(material, "_FIXED_NORMALS", true)
Hi @ToddRivers,
I'm using the shaders of about a week ago and I'm facing a few issues when the sprite gets exposed to Spotlights with Intensity of 4:
Normal:
Lit by a spotlight with an intensity of 4 (using HDR doesn't change anything)
This is the material I'm using:
Note that even changing the blending mode to premultiplied alpha I get the same results.
It's like the sprite is getting... transparent, you can see through it like it was made of veils.
Note how selecting Pixel Lit the inspector still shows Vertex Lit.
Also, sometimes when switching between shaders the shader crashes and shows a pink/error material. Selecting again the shader from the list solves the issue.
Hey! Sorry that was my bad, I forgot to change the code when I changed the shaders names so the shaders weren't switching. I actually fixed it just before you posted, if you grab latest the problem will disappear
I've also been messing around with post effects in my project and noticed if you generate a DepthNormals texture for a camera then the normals would be random for any sprites that use a FixedNormal.
I made a new RenderType for sprites with fixed normals and then made a custom shader for creating a DepthNormals texture which renders Sprites properly.
Its prob not of interest for most peops but if you want to use SSAO or a similaur effect that needs the scenes normals then it might be usefull, its on the github anyways
ToddRivers wroteHey! Sorry that was my bad, I forgot to change the code when I changed the shaders names so the shaders weren't switching. I actually fixed it just before you posted, if you grab latest the problem will disappear
I've also been messing around with post effects in my project and noticed if you generate a DepthNormals texture for a camera then the normals would be random for any sprites that use a FixedNormal.
I made a new RenderType for sprites with fixed normals and then made a custom shader for creating a DepthNormals texture which renders Sprites properly.
Its prob not of interest for most peops but if you want to use SSAO or a similaur effect that needs the scenes normals then it might be usefull, its on the github anyways
Nice, the new shaders don't crash anymore!
Do you have any clue about the PixelLit shader becoming transparent as per picture?
Yeah so Pixel/Forward lighting is done over multiple passes (1 pass for each light) meaning bits of the sprite lit by additional lights will draw over the top of each other and give that effect as there is no depth test being performed.
To use pixel lighting you need to turn on depth writing, however as you cant write a translucent depth value you need to use a hard clipped alpha rather than having a nice smooth faded alpha.
Vertex lighting is done in one pass meaning you wont get that translucent overdraw and can have fully faded alpha but isn't as accurate (although if your sprite has enough verts you won't notice).
It depends on the project / sprite what mode works best. I'd recommend vertex lighting most of the time though but have a play with the two modes and turning write to depth on/off as well as adjusting the alpha depth cutoff value.
ToddRivers wroteYeah so Pixel/Forward lighting is done over multiple passes (1 pass for each light) meaning bits of the sprite lit by additional lights will draw over the top of each other and give that effect as there is no depth test being performed.
To use pixel lighting you need to turn on depth writing, however as you cant write a translucent depth value you need to use a hard clipped alpha rather than having a nice smooth faded alpha.
Vertex lighting is done in one pass meaning you wont get that translucent overdraw and can have fully faded alpha but isn't as accurate (although if your sprite has enough verts you won't notice).It depends on the project / sprite what mode works best. I'd recommend vertex lighting most of the time though but have a play with the two modes and turning write to depth on/off as well as adjusting the alpha depth cutoff value.
Thanks for the explanation!
I kind of managed to make it work, even if I had to ramp up the lights to obtain the same overbright effect.
Z write on, premultiplied apha, and Z spacing < 0.
The lighting still cumulates when different instances of the characters on the same Sorting Layer and Layer Order overlap.
Should I fix this by assigning an incremental value to the layer index, by offsetting sprites randomly on the Z axis, or is there any other shader-based solution available?
(2 final notes: I can't seem to be able to illuminate vertex lit sprites, and I can't choose "Solid" blend from the shader's dropdown menu anymore)
Ok I've fixed the Solid dropdown bug. Not sure whats going on with vertex lighting for you, what's your setup? Are you using mesh normals or fixed normals, is the sprite flipped or has it got negative scale?
Vertex lights working fine for me.
Yeah you'll want to shift them along the z axis if your using write to depth and pixel lighting otherwise you'll get Z fighting.
ToddRivers wroteOk I've fixed the Solid dropdown bug. Not sure whats going on with vertex lighting for you, what's your setup? Are you using mesh normals or fixed normals, is the sprite flipped or has it got negative scale?
Vertex lights working fine for me.Yeah you'll want to shift them along the z axis if your using write to depth and pixel lighting otherwise you'll get Z fighting.
Solved, I thought some basic normals were calculated. I checked "calculate normals" and used mesh normals and all is running fine
Thanks for fixing the issues so quickly!
Yet, it would have been nice to have both alpha blended sprites and proper lighting together on mobile - I had hand painted characters and having sharp crisp cutout edges somehow ruined the "painted" effect. I'm not sure if using deferred rendering is going to be good on mobile...
Hi!, I'm new using this shader and I have this problem and I don't know how to fix it.
Loading Image
Whenever I choose one of your shaders the Spine skeleton is rendered this way.
This are the settings for the atlas texture:
Loading Image
Also I'm exporting from Spine as pre-multiplied alpha. Straight alpha doesn't work too.
Help?
Thanks!
The inspector looks broken too. Are you importing ToddRivers' unitypackage?
If you're using the latest spine-unity unitypackage, the shader should already be included under Modules.
The shader path looks like `Spine\Sprite\
`
I think if you have both, the cginc files might have code collision problems which may turn the shaders pink.
Is the console empty?
We imported both Spine unitypackage and Todd's unitypackage. Reading the other answers I deleted both, Todd River's and Spine spine-csharp folder and spine-unity, then I closed unity to have a clean console report, and then re-imported only Spine official unity package. The problem persists and this message appeared on console:
Image removed due to the lack of support for HTTPS. | Show Anyway
28 Nov 2016, 11:44
@MattouBattou solution is working for us, but I don't know why the Spine unitypackage and todd's shader unitypackage doesn't work alone.
Hi, I'm just trying to use the awesome shader package and ran into an issue where nothing would work.
I had an error showing up in the inspector panel for all shaders in Game>Shaders>Sprites saying "undeclared identifier 'unity_ObjectToWorld' d3d11 ShaderShared.cginc:15".
I'm stuck on Unity 5.3.4p6 for target platform reasons. I basically changed the line in ShaderShared.cginc from:
/* line:15 */ return mul(unity_ObjectToWorld, vertex);
to
return mul(_Object2World, vertex);
And everything now works.
Just thought it was worth mentioning for anyone else stuck on this!mentioning for anyone else stuck on this!
28 Nov 2016, 11:48
In our ShaderShared.cginc file we had to edit line 12 though.
Same here, using Todd's latest version:
Unity v5.4.2f2 (building for Android), Win7 Ultimate 64bit
Previous ones didn't trigger any error.
I already left the issue on the git. https://github.com/traggett/UnitySpriteShaders/issues/1
It's a Unity 5.5 define.
The shader bundled with spine-unity should be fine.
Amazing!!, it's always so nice to have great support. Definitely loving everything related Spine!
Thanks again!
Hey sorry for the late response, yeah I've been on the 5.5 beta so stuck some 5.5 only shader stuff in there by mistake.
5.5 is now out properly so I guess I'll leave it in so the shaders are correct for the latest version of Unity.
I guess most people will be grabbing the shaders via the spine runtimes now anyhow though, don't know what version of Unity they're targeting but might need to change some of the Unity variables to match it
- Edited
Hi @ToddRivers,
Great progress as always! And also very much appreciated for all your hard work and continued support on this tool! I hope the Spine guys are compensating your excellent addition, to an already awesome animation tool.... maybe some free licenses or something if you aren't accepting cash ? :party:
I also have a question about normal intensity, maybe I'm doing something wrong? I can't seem to get the same level of "normal" map bump using your tool compared to Unity's normal "Standard" shader. Any idea on what I'm doing wrong? (The left mario is using the Standard Shader, right is your sprite shader)
Thanks again!
Image removed due to the lack of support for HTTPS. | Show Anyway
Pls find the settings below. Image removed due to the lack of support for HTTPS. | Show Anyway
AlaNintendo wroteHi @ToddRivers,
Great progress as always! And also very much appreciated for all your hard work and continued support on this tool! I hope the Spine guys are compensating your excellent addition, to an already awesome animation tool.... maybe some free licenses or something if you aren't accepting cash ? :party:
I also have a question about normal intensity, maybe I'm doing something wrong? I can't seem to get the same level of "normal" map bump using your tool compared to Unity's normal "Standard" shader. Any idea on what I'm doing wrong? (The left mario is using the Standard Shader, right is your sprite shader)
Thanks again!
Image removed due to the lack of support for HTTPS. | Show Anyway
+1 for normal intensity float multiplier in the shader
@[deleted]
Does your mesh have tangents?
On top of that, it looks like the Standard shader is adding speculars which ToddRivers' shaders current doesn't do.
Is it possible that the shader (Pixel Lit) not running on mobile? If I use a Spine object its works. When I use a normale sprite it does not render on mobile. This worked weeks ago without any problem. Maybe this shader will not work without Spine object now?
Edit: Maybe something to do with this warning?
Hi!, I wanted to post a bug I think.
Why whenever my Spine character gets near a point light with Pixel Lit shader it looks like this?
Image removed due to the lack of support for HTTPS. | Show Anyway
The normals are set to X= 0, Y = 0, Z = 1 (If I use normals -1 it's not lit), the same with use mesh normals by the way.
If I use Vertex Lit the problem fades away but is not accurate in terms of lighting so I want to use Pixel Lit.
The light is behind the character, if it's in front it doesn't get lit.
Also another question. Why in Vertex Lit mode everything needs to be lit from the front, and in Pixel Lit everything has to be lit from back? I have to manually change normals in the shader to not have to change every light Z position.
1) This is just how pixel lighting in Unity works.
The same thing will happen with any pixel lit shader in Unity that doesn't write to depth and sprites on the same batched pass.
To fix it, write to depth, and add z-spacing.
This will cause other artifacts related to alpha-blended things that write to depth. This is an extensive topic in graphics programming and in any engine.
Again, here, this is just how pixel lighting in Unity works.
2) Normals should be (0, 0, -1). If the light direction acts incorrectly despite using that normals value, that's where the bug is.
@AlaNintendo, yeah like Pharan says what you're seeing is just the specular from the standard shader. The shader doen't support specular (yet!) so a better comparison would be to compare it with the 'Legacy Shaders/Bumped Diffuse' shader which doesn't have specular.
Its something I'll prob add at somepoint, along with a specular map as don't think it makes sense for the whole sprite to be shiny but bits like armour etc would look cool
@Pharan so NeatWolf pointed out a bug with vertex lighting a while ago which meant he had to set the normal to (0,0,1). I fixed it in my github a while ago but not sure if you guys have kept up to date with the shaders in your runtimes?
@alcyongames As Pharan says pixel lighting will always cause overdraw unless you write to depth. Pixel lighting is split into multiple passes for each light. The only way a pass wont draw on top of a previous one is using a depth test. For that to work you need to write to depth (which means a hard alpha edge).
If you're art style has hard edges anyways that's not a problem, use pixel lighting just turn on write to depth.
If it doesn't (ie you've got faded edges) then use vertex lighting and increase the number of verts used in your spine animation (ie use mesh attachments instead of just quads) to make it more accurate.
With a decent number of verts you'll struggle to notice the difference between vertex and pixel lighting most of the time, and vertex lighting is faster (though increased number of verts is slightly more CPU intensive, vertex lighting is less GPU intensive).
, yeah like Pharan says what you're seeing is just the specular from the standard shader. The shader doen't support specular (yet!) so a better comparison would be to compare it with the 'Legacy Shaders/Bumped Diffuse' shader which doesn't have specular.
Its something I'll prob add at somepoint, along with a specular map as don't think it makes sense for the whole sprite to be shiny but bits like armour etc would look cool
@ToddRivers @Pharan Ahh that would explain the difference in appearance. 8)
Ok crossing fingers , you or the Spine team can get around adding a specular map option :happy: :happy:
@ToddRivers should be up to date until Nov 24. I think that includes the normals fix.
ToddRivers wrote@Pharan so NeatWolf pointed out a bug with vertex lighting a while ago which meant he had to set the normal to (0,0,1). I fixed it in my github a while ago but not sure if you guys have kept up to date with the shaders in your runtimes?
I updated them yesterday as well, but I still have to set them to (0,0,1) for Vertex Lit to work. If I switch to Pixel lit, -1 is ok.
Unity v5.4.2f2
@NeatWolf Yeah me too! "Use Mesh Normals" doesn't work, I have to manually set the normals for Pixel Lit to Z = -1. It works in other things though (I use Todd's Rivers shader in other assets like Ferr2D) and if I use pixel lit with "Use Mesh Normals" It works haha. Well it's not a problem though, I just have to set it up manually that's all.
Hey sorry for the delay. OK had another look at the vertex lighting macro's and think I found a bug! (I was using the view matrix instead of the inverse view matrix). I've checked in a fix to github so might be worth grabbing latest and seeing if it helps.
I also made the material editor work with multiple materials at the same time (i.e. multi-edit).
Another think to look out for is it might be worth trying to 'reset' the material (by clicking on the cog in the top right corner of the material editor) and then reapplying any settings.
Unity materials tend to accumilate loads of flags/defines/values whilst your editing them and switching shaders, which can potentially cause things to break.
I've hopely cleaned up the sprite material editor so it always sets and resets things properly but worth trying too if the fix doesn't help!
was my post ignored? or it isn't a problem?
dothem wroteIs it possible that the shader (Pixel Lit) not running on mobile? If I use a Spine object its works. When I use a normale sprite it does not render on mobile. This worked weeks ago without any problem. Maybe this shader will not work without Spine object now?
Edit: Maybe something to do with this warning?
ToddRivers wroteHey sorry for the delay. OK had another look at the vertex lighting macro's and think I found a bug! (I was using the view matrix instead of the inverse view matrix). I've checked in a fix to github so might be worth grabbing latest and seeing if it helps.
I also made the material editor work with multiple materials at the same time (i.e. multi-edit).Another think to look out for is it might be worth trying to 'reset' the material (by clicking on the cog in the top right corner of the material editor) and then reapplying any settings.
Unity materials tend to accumilate loads of flags/defines/values whilst your editing them and switching shaders, which can potentially cause things to break.
I've hopely cleaned up the sprite material editor so it always sets and resets things properly but worth trying too if the fix doesn't help!
I tried to import these latest shaders but I got a compiler error (targeting Android, Unity v5.4.2f2):
Shader error in 'Hidden/Internal-SpriteDepthNormalsTexture': unrecognized identifier 'UNITY_VERTEX_INPUT_INSTANCE_ID' at line 213 (on d3d11)
Compiling Vertex program
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING
in UnitySpriteShaders-master\SpriteShaders\SpriteDepthNormalsTexture.shader