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.

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?

@[हटाया गया]
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.

Thank you
I'll test the new shaders tomorrow

Thanks again for your work!

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

Pharan लिखा

@[हटाया गया]
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.

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.

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?

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.

@[हटाया गया]
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)

Pharan लिखा

@[हटाया गया]
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.

Unity 5.6: right is now left!

Nate लिखा

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.

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.

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?

@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.