Sprite Shaders for Unity

ToddRivers

Argh thats just because you're not on Unity 5.5.

Its only a warning about the SpriteDepthNormalsTexture shader which you prob won't be using - the rest of the shaders will be uneffected 🙂

@dothem sorry must've missed your post - what do you mean by 'normale sprite'? Like a sprite with a normal map?
The shaders should work on mobile and with spine animations.

NeatWolf

ToddRivers wrote
Argh thats just because you're not on Unity 5.5.

Its only a warning about the SpriteDepthNormalsTexture shader which you prob won't be using - the rest of the shaders will be uneffected 🙂

@dothem sorry must've missed your post - what do you mean by 'normale sprite'? Like a sprite with a normal map?
The shaders should work on mobile and with spine animations.

Yes, I can't upgrade now, not all of the assets I'm using are 5.5 compatible. 😢

Yet, previous version worked like a charm. It's not really a warning, the shader doesn't compile at all. What should I change to solve the issue?

Pharan

@[deleted]
UNITY_VERTEX_INPUT_INSTANCE_ID should be UNITY_INSTANCE_ID in Unity 5.4
Should be easy to find it in the shader code and replace it.

The spine-unity bundled version has this change.

ToddRivers

You can also delete that shader if you want, like I said I very much doubt you're using it (it's only used to render a Depth+Normals texure for effects like ScreenSpace Ambient Obscurance).

It really shouldn't matter even if it doesn't compile - its not referenced by the main sprite shaders.

NeatWolf

Thank you 🙂
I'll test the new shaders tomorrow 🙂

Thanks again for your work!

ToddRivers

No worrie 🙂 Fingers crossed that's finally sorted your vertex lighting normals problems!

dothem

Yep, normal map. But without Spine (normal Sprite with material). This won't rendered on mobile. But the Spine object do.

NeatWolf

Pharan wrote
@[deleted]
UNITY_VERTEX_INPUT_INSTANCE_ID should be UNITY_INSTANCE_ID in Unity 5.4
Should be easy to find it in the shader code and replace it.

The spine-unity bundled version has this change.

Thanks, that fixed all the errors (there were more than one).

About the normals, now (with the version of yesterday) work only if:

Pixel lit, write to depth on, (0,0,-1)

Vertex lit, (0,0,1)

if I flip the normals, they're no longer lit, in both cases.

Also, the pixel lit one looks way darker than the vertex lit. Is that normal?
I'm using the vertex lit shaders so having all of the normals to (0,0,1) it's just fine for me, yet, it's a bit weird.

ToddRivers

Hmm thats not good. The pixel shader being dark was another bug I forgot to fix when I last checked in doh - I wasn't clamping the dot value for lights, that's fixed in latest.

I've attached an example project showing pixel lighting, vertex lighting and unity's standard shader side by side.
In it the mesh normals are set to (0,0,-1) and the lighting looks correct (for me at least!)

And if you set the normals to (0,0,1)...

Its worth opening it and seeing what it looks like for you.

NeatWolf

ToddRivers wrote
Hmm thats not good. The pixel shader being dark was another bug I forgot to fix when I last checked in doh - I wasn't clamping the dot value for lights, that's fixed in latest.

I've attached an example project showing pixel lighting, vertex lighting and unity's standard shader side by side.
In it the mesh normals are set to (0,0,-1) and the lighting looks correct (for me at least!)

And if you set the normals to (0,0,1)...

Its worth opening it and seeing what it looks like for you.

Unfortunately you're using 5.5 (which I still consider too early to adopt since they did a lot of changes and devs from the asset store are generally waiting a bit before supporting it fully) and I'm still on 5.4.2f2 so the import of the project didn't go as expected...

Anyway, the last version fixed the pixel lighting.

Still, pixel lighting is ok on 5.4.2f2

but

vertex lit has its normals inverted (only works with 0,0,1)

yet

if I enable rim lighting with (0,0,-1) on vertex lit, I get almost a perfectly lit skeleton. The higher the power, the better.
With the same settings if I later switch to (0,0,1) the material gets fully white (rim color) doesn't matter the rim power value.

So, whatever lighting calculation you make to get rim lighting, assume an infinite power and that should work with vertex lighting as well with proper normals (0,0,-1)..
Or, rim lighting inverts the normals again, I don't know :-/

ToddRivers

Gah forgot your not on 5.5.
Is anyone else on 5.5? Can anyone confirm the normals work as expected for them?

It's possible that for some reason UNITY_REVERSED_Z isn't defined when using vertex lighting in 5.4 on android (thats the platform your running right?). That seems super weird / unlikely but running out of ideas.
If that is the case then that's a bug with Unity and not something I can really fix, I will try and check android on 5.5 at somepoint to make sure it's not a prob with that as well.

NeatWolf

ToddRivers wrote
Gah forgot your not on 5.5.
Is anyone else on 5.5? Can anyone confirm the normals work as expected for them?

It's possible that for some reason UNITY_REVERSED_Z isn't defined when using vertex lighting in 5.4 on android (thats the platform your running right?). That seems super weird / unlikely but running out of ideas.
If that is the case then that's a bug with Unity and not something I can really fix, I will try and check android on 5.5 at somepoint to make sure it's not a prob with that as well.

This implies you're going to support only the very latest unity version, that's a pity 🙁

Is the version shipped with the runtimes by Esoteric going to only support 5.5 as well?

Nate

In general we aim to officially support the latest version of each game toolkit. It nearly doubles our workload to also support the penultimate version. That said, unofficially the latest runtimes usually continue to work on recent previous versions of the game toolkits. There is also the option to freeze your runtime and editor versions.

Pharan

@[deleted]
That seems right.
UNITY_REVERSED_Z is in the 5.5 documentation (https://docs.unity3d.com/550/Documentation/Manual/SL-BuiltinMacros.html)
but not in 5.4 (https://docs.unity3d.com/540/Documentation/Manual/SL-BuiltinMacros.html)

NeatWolf

Pharan wrote
@[deleted]
That seems right.
UNITY_REVERSED_Z is in the 5.5 documentation (https://docs.unity3d.com/550/Documentation/Manual/SL-BuiltinMacros.html)
but not in 5.4 (https://docs.unity3d.com/540/Documentation/Manual/SL-BuiltinMacros.html)

Yup, I don't know if it has any impact on the shaders, but with 5.5 (and I suppose starting from 5.5) the depth buffer is inverted.

From the ChangeLog:
"Graphics: Improve shadows precision for large game worlds. Use reverse-float depth buffer for improved depth buffer precision on modern GPUs. Particularly improves directional light shadowing for large view distances."
"Graphics: Added bool SystemInfo.usesReversedZBuffer to be able to know if the platform is using a "reversed" depth buffer."

Probably some useful info from the upgrade guide to 5.5:
https://docs.unity3d.com/Manual/UpgradeGuide55.html

Shaders: Z-buffer float inverted

The Z-buffer (depth buffer) direction has been inverted and this means the Z-buffer will now contain 1.0 at the near plane, 0.0 at the far plane. This, combined with the floating point depth buffer significantly increases the depth buffer precision resulting in less Z-fighting and better shadows, especially when using small near planes and large far planes.

Graphics API changes:

Clip space range is [near, 0] instead of [0, far]
_CameraDepthTexture texture range is [1,0] instead of [0,1]
Z-bias is negated before being applied
24 bit depth buffers are switched to 32 bit float format
The following macros/functions will handle reversed Z situations without any other steps. If your shader was already using them, then no changes needed from your side:

Linear01Depth(float z)
LinearEyeDepth(float z)
UNITY_CALC_FOG_FACTOR(coord)
However if you are fetching the Z buffer value manually you will need to do write code similar to:

float z = tex2D(_CameraDepthTexture, uv);
#if defined(UNITY_REVERSED_Z)
z = 1.0f - z;
#endif
For clip space depth you can use the following macro. Please note that this macro will not alter clip space on OpenGL/ES plaforms but will remain [-near, far]:

float clipSpaceRange01 = UNITY_Z_0_FAR_FROM_CLIPSPACE(rawClipSpace);
Z-bias is handled automatically by Unity but if you are using a native code rendering plugin you will need to negate it in your C/C++ code on matching platforms.

Nate

Unity 5.6: right is now left!

NeatWolf

Nate wrote
Unity 5.6: right is now left!

Pretty much 😃

little update: on 5.4 vertex-lit shaders work correctly with (0,0,-1) also if you add a normal map (correctly lit from the front)

so, if I use either a normal map or rim lighting all is fine.
If the shader is flat and "simple", its lighting gets inverted.

Could this help to spot the issue? It's really weird the lighting is flipped only when there is not a normal map and there's not rim lighting activated.

alcyongames

I don't understand why Unity devs love to change sometimes names for code methods. It's like they love to mess projects up haha.

Anyways, I have a question. Is there a way to have the additive blending from Spine to work with your shaders @ToddRivers?
If I use additive blending in Spine that attachment doesn't work with your shaders. It would be awesome to combine both of them so I can animate lit things. Something I could do would be to animate the emissive power in your shaders to animate the lighting on my character, or something like that.

Pharan

additive blending on the same shader is a premultiplied-alpha trick.
It probably will never work combined with various other lighting and shader features, so you may have to set a separate additive material specific to that slot/attachment. Note that this will necessarily break dynamic batching.

I think animating the Emissive Power property is fine. Are you not able to do that?

alcyongames

@Pharan what do you mean by setting a separate additive material specific to that slot/attachment? You mean inside Spine or in Unity?
Also I haven't tried to animate the emissive power yet so I can't tell if it works or not.

« Previous Page Next Page »