@[cancellato]
Is this related? Spine-Unity Runtime Documentation: Setting Material Properties Per Instance
Sprite Shaders for Unity
Pharan ha scritto@[cancellato]
Is this related? Spine-Unity Runtime Documentation: Setting Material Properties Per Instance
Totally! It's 100% my case. I didn't know MaterialPropertyBlocks existed, I think all my apps are going to be a little more optimized from now, thank you a lot! :nod:
5 giorni dopo
Hey everyone, happy new year!
I've, just checked in some updates to how fixed normals work - you can now specify them either in camera space or model space and adjusting for lighting back faces now works correctly (there were a couple of bugs with it).
However correct back face lighting now requires mesh normals (its the only way the shader can know what direction a vertex is facing in).
The shader does now remind you what it wants in terms of tangents or normals though 
If you grab latest you might need to retick 'use fixed normals' on your materials as the defines have changed, sorry!
The majority of the time with Spine animations you don't need to adjust the tangents for correct back face lighting - it's needed only when you have rotated your object to face away from the camera and thus the tangents need to be flipped in the shader.
I recommend instead of rotating sprites, use the Spine skeleton.FlipX/Y. This means your Spine animation won't need normals and things like Z offset for submeshes will stay correct.
If you render Unity Sprites or Meshes then you might need to turn on the 'Adjust Backface Tangents' option if they face away from the camera.
03 Jan 2017, 12:39
@[cancellato] yeah using a custom Depth+Normals buffer is pretty advanced to be fair.
What you're doing there is correct - that should render the depth+normals for the scene including soft alpha'd sprites.
However you want to render into a RenderTexture which you can then pass through to your Post Effects. (ie give the camera a target texture).
You will also need to edit the PostEffect shaders you're using to use this newly created RenderTexture instead of the default camera Depth+Normals texture.
Admittedly this is all pretty advanced stuff and you'll need to be able to edit your post effects shaders to get it to work but it's what I do for my game so def works
I recommend reading this (plus the first 2 parts) which explains the CameraDepthNormals texture and how it gets used with a simple example.
http://willychyr.com/2013/11/unity-shaders-depth-and-normal-textures-part-3/
In this example he's telling his camera to render a depth+normals texture for him with the following line of code:
camera.depthTextureMode = DepthTextureMode.DepthNormals;Then his post effect shader is using that texture with:
_CameraDepthNormalsTextureWhich inside a unity shader automatically grabs the last cameras generated DepthNormals texture.
In your case you don't want to generate a texture or use _CameraDepthNormalsTexture as you've rendered your own special one. So instead of using _CameraDepthNormalsTexture in the shader, pass it the texture you rendered into with
camera.RenderWithShader() and you should see the normals and depth for your Sprites.
This can then be adapted for things like Depth of Field or SAAO.
Happy new year!
Thank you for your help and information. I will try to apply it in practice.
Cool, good luck! If you want to use it for a Post Effect that just uses the Depth Buffer (Like I think Unity's built SSAO now does) then I've added a shader that renders a custom depth buffer for a camera with nice soft edges for sprites that don't normally write to depth:
https://github.com/traggett/UnitySpriteShaders/blob/master/SpriteShaders/SpriteDepthTexture.shader:
However aswell as changing references to _CameraDepthTexture in the post effect shader to be your own depth texture you will also need to use DecodeFloatRGB() instead of SAMPLE_DEPTH_TEXTURE() to get a depth value from the texture (SAMPLE_DEPTH_TEXTURE uses 32bit RGBA for depth, we have to use just 24bit RGB because we're using the alpha channel to blend the soft edges).
DecodeFloatRGB() is inside ShaderMaths.cginc.
5 giorni dopo
I'm playing around with the new specular map option. Super cool stuff man! !
Just letting you know, I haven't had any trouble with it on 5.5.0f3.
09 Jan 2017, 09:02
@ToddRivers
Hi ToddRivers, do you have this performance spike when you are using pixel lit, sprite?
Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque
Hey AlaNintendo!
I have noticed spikes in the editor when you turn on/off features on a material for the first time. I haven't experienced them at run time though - looking a the profiler it looks like its the editor compiling a new version of the shader when defines get enabled / disabled. Thats taking 1131ms for me which is a bit scary!
Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque
I suspect I've either done something stupid or gone over the shader keyword limit or something.
Once the shader is compiled there should be no more spikes though (so shouldn't effect performance apart from in the editor)
Is your spike happening whilst playing? It strange it looks like its calling shader.editorloadvariant - the way I thought Unity worked was it makes a compiled version of your shader beforehand.... maybe i need to do something to make unity spit out variants properly when it builds:
https://blogs.unity3d.com/2014/05/06/shader-compilation-in-unity-4-5/
9 giorni dopo
Hi ToddRivers,
I believe it's just lagging while in editor. My builds lag on occasion, but that may be because of other problems with my own code haha..
But just wanted to give you a heads up on what I was experiencing, in regards to your shader.
Thanks again for this. It's been a really awesome shader for Spine!
Hi @ToddRivers,
I'm keeping up with the updates and keep thanking you for creating these shaders.
Is there any chance you could add support for simple offset-shadows to the ubershader (or maybe also an outline?), as part of the ubershader, or as a separate single-coloured-shadow-shader, maybe with some configurable edge blurring that also supports fading the skeleton shadow as a whole (an alpha value for the whole skeleton, not made by overlaying each bone's alpha: i.e.: like a real shadow?)
I remember to have seen something like a skeleton trail FX but can't remember where, and if the trail was actually revealing each bone's borders when fading or was faded as a whole.
If it's not available right now, and you're available to work on it, I'd happily donate to have this feature (working on mobile, I suppose some multiple passes could be needed, but I would be using this for the main chars only)
Cheers,
Alessandro Salvati
11 giorni dopo
Hey folks, does anyone have input for this guy?
Hey! Added a little update which I think was requested a while ago - scaling for normal maps (I noticed Unity added it into their standard shader so just copied that code) that means you can tweak how bumpy your bump map is in the shader
As far as my normal map flow I use SpriteIlluminator to create my normal maps. I'm still paying around with the best way of solving 'pillowing' where joints or limbs that should be one continous shape look like seperately beveled parts.
One method is instead of using SpriteIlluminator to bump each sprite image seperately, export your full character or full limb from photoshop, bump that in SpriteIlluminator and then reimport it into photoshop and then cut it up and export it in the same way you cut up the character for animations.
This means the parts that should be one piece like a leg for example get bumped as they should.
Sure there's better methods though!
6 giorni dopo
What are the limitations of these Shaders? I'm using this for my mobile game. The sprites (SpriteRenderer) flickering very hard on mobile. With flickering I mean appear / disappear of the sprites. Anyne facing the same issue?
Hi, I've been using your Shader extensively and I'm SUPER glad that it exists. Thank you very much for your effort, it's very much appreciated!
I have, however, one technical problem at the moment.
I've begun to realize that fading / tweening the alpha value from 1 to 0 or vice versa, when using your modified shader, produces a very strange behaviour: Whenever I do this it doesn't look like expected, the fading part of the spine object seems to be way too dark, almost like it mixes itself with pure black while fading. Very weird.
I illustrated what I mean by recording these 2 gifs: Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque
1) This is how it SHOULD look, I recorded this using the default spine skeleton shaders.
2) This is how it looks when using the custom shader. Immagine rimossa a causa della mancanza di supporto per HTTPS. | Mostra Comunque
I hope you understand what I mean. Does anyone know what causes this? I already tried almost every export configuration I could think of and checked/unchecked almost every setting in the shader itself but it always looks like this.
Please help :S
This result looks like it's applying straight alpha to PMA colors.
If you are using the skeleton's alpha, make sure you disabled "PMA Vertex Colors" on the component.
If you are sliding the alpha on the material, the shader probably needs a flag somewhere, or needs to handle it. Or you need to use premultiplied alpha blending, which would mismatch if your exports are straight alpha.
Pharan ha scrittoThis result looks like it's applying straight alpha to PMA colors.
If you are using the skeleton's alpha, make sure you disabled "PMA Vertex Colors" on the component.
If you are sliding the alpha on the material, the shader probably needs a flag somewhere, or needs to handle it. Or you need to use premultiplied alpha blending, which would mismatch if your exports are straight alpha.
Thank you so much! The disabling of "PMA Vertex Colors" did the trick, did not know that at all!
Thanks again, everything works perfectly, now!
2 mesi dopo
Hi there!
I was getting a bit worried not to receive any more notifications from this topic 
I had issues because I was using an older version of Unity. Now I upgraded to 5.5.3 and still have normal flipping issues.
The default shader works fine when building for android with normal (0,0,1), but in the editor they're reversed, making it harder to work with.
Unless I do some per-material runtime normal flipping when running on specific platforms.
Is this a known issue? Are you still supporting the shaders?
Thanks for your time
Updating this as well as it seems there's some problems since unity updated to 5.6 !
Now it still seems to work pretty well for spine exports as it goes. However I've been using them for "static" background objects as well and there's an odd transparency issue going on now
Any of you guys have issues with depth writing as well? I seem to get flickering on my character when he is running around in game. :doh:
6 giorni dopo
This Shader is still not runing on mobile devices. I created e bug by Unity, multiple months ago, but no reaction. Maybe someone have a fix for this?
When using these Shader with a SpriteRenderer, it will flickering, or not even displayed. This is very annoying 
Hey y'all! Been a while.
So I just realized I made a silly mistake in the shader fixed normal code which meant lighting would be incorrect on certain platforms. I've checked in a fix but it means from now on the fixed view normal should be defined as (0,0,1).
It should however now work consistently on all platforms.
Let me know if you see any bugs with it!
@AlaaNintendo I've had some Z fighting issues on 5.6, for some reason the depth buffer seems more compressed. Not entirely sure why yet but increasing the Z Spacing on your Skeleton Animation component should stop the Z fighting.