Hi,
I tried you shader but I have one issue, some parts of my character don't show up. I think it's because they are flipped version of other parts of the character - so the non-flipped version of the arm is displayed but not the flipped one - etc.
Is that normal ? Did I do something wrong ?
Image removed due to the lack of support for HTTPS. | Show Anyway
Thanks
Hey! Ooh yeah that looks like it caused by back face culling being left on. I've updated the shaders to turn culling off which should fix things not showing when flipped. Grab them again from the zip in the first post (I've attached some new ones).
@Pharan I've also managed to pack up the vertex lighting to use one less register meaning those shader compile errors should be fixed, however the vertex shader needs to use shader model 3.0 as it still uses 11 out put registers when bump mapping is turned on so added a pragma for that.
Ok, everything shows up now :-)
Thank you !
Hey man,
I tried using your shader as I've been looking for something like this but I keep getting this error.
Shader error in 'Game/Sprite Vertex Lit': cannot map expression to vs_4_0 instruction set at Assets/Game/Shaders/Sprites/SpriteVertexLighting.cginc(55) (on d3d11)
Compiling Vertex program with _ALPHAPREMULTIPLY_ON _NORMALMAP _DIFFUSE_RAMP
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_TEXTURE_ALPHASPLIT_ALLOWED
I must set some configuration when the character is flipped?
Image removed due to the lack of support for HTTPS. | Show Anyway
Turn Calculate Normals on.
And you should flip using Skeleton.flipX, not rotation. I think negative scale also works but I don't know what it does to rigidbodies and colliders.
Pharan wroteTurn
Calculate Normalson.
And you should flip using Skeleton.flipX, not rotation. I think negative scale also works but I don't know what it does to rigidbodies and colliders.
Sorry but where is the calculate normals? :tmi:
But already worked with skelton utility flipping.
Thanks Pharan :rock: :rock: :rock:
It's under "advanced" on the SkeletonAnimator.
@Hale_88 Soz, I've fixed the shaders (updated the zip file in the first post). I wasn't checking they compiled against all platforms, my bad. I've now moved the ramp texture lookup onto the frag. Should all be working now!
Thanks!
Do you have this code version controlled somewhere? (Just curious)
Thanks @ToddRivers the error seem to be gone now.
As a different issue I seem to be doing something wrong as the lighting seems to be in reverse.
Image removed due to the lack of support for HTTPS. | Show Anyway
Also I checked and all my scales are in positives, aka no negative z value or anything
@[deleted]
Are you using Per-Pixel lighting?
This is how it normally behaves and it's terrible.
For pixel lighting to work, you need to enable depth, and increase the SkeletonRenderer/SkeletonAnimation's Z-spacing by the tiniest amount (just enough that the depth kicks in).
What do you mean by "reverse" though?
@Pharan yeah I'm using PixelLit, VertexLit wasn't looking as good as PixelLit.
What I meant by reverse is he actually looks like is being lit from the back to the front. Like you can see his whole neck being lit and then each piece being lit and added to it.
Oddly enough if I put a -1 value for Z in scale on the animator it fixes it. I've also tweeked the Z spacing and the depth Alpha cutoff but I always have the lines
Image removed due to the lack of support for HTTPS. | Show Anyway
Now I'm stumped. Why on earth is negative z-spacing causing the correct results? Isn't positive Z moving away from the camera?
@[deleted]
Seeing each piece lit one on top of another is actually normal for Unity if you don't have depth on. We discussed it in the earlier part of this topic. The first post of the topic also demonstrates what was happening.
It doesn't look like black outlines to me. Looks more like the parts are pillow-shaded from an automatically generated normal maps.
Just a hunch
12 Mar 2016 2:54 pm
Sorry. That was my bad. Z-spacing slider values were backwards. It's supposed to be negative because attachments are added to the buffer from farthest to nearest. (Official Esoteric Lunkhead)
Got the fix here: https://github.com/EsotericSoftware/spine-runtimes/commit/5570e2b5d0413a8509a1de046b3dff4754316ed9
Just open SkeletonRendererInspector.cs and replace those values.
12 Mar 2016 2:59 pm
I also see the lines. It may be something that can be adjusted in the shader code.
But I think the surer way to do this is likely to switch to the straight alpha/Standard Alpha instead of PreMultipliedAlpha blend mode (and re-export your atlas from Spine with Premultiply Alpha disabled).
That won't get rid of the pillow-shading though.
Thanks Pharan, Yeah I don't have to inverse the z anymore with that fix.
On Monday I will get my artist to re-export the atlas with Premultiply Alpha off and let you know if that gets rid of the lines.
What do you mean by the pillow-shading?
This is pillow shading: http://darkabstraction.com/showOff/ffhackticks/fft-art-directives-pillow-shading.png
In pixel art terms, it means the artist naively just darkened the drawing along its silhouette uniformly.
In this case, I mean even the parts that are supposed to blend in (the flesh of his face image should blend with his head image, some parts of his torso and arms, I guess) had depth applied to it naively (by a normal map generator?) in the pillow-shading pattern. So its supposedly blended edges will stick out.
13 Mar 2016 10:44 pm
@ToddRivers :
I had a thought regarding normals on sprites.
If we could just let the shader use a constant float3(0,0,-1), we wouldn't need Spine to stuff a bunch of the same normal value for every vertex.
Ooh yeah thats a good idea actually! was thinking about that initially but then totally forget. Would also be one more param free for vertex light info.. hmm might give it a go, still need the tangents passed through for normal mapping though..
@Hale_88 in most cases I would recommend trying to use vertex lighting if you can, its a lot faster to render than pixel lighting and means you don't have to have a hard alpha cutoff for the depth buffer. The key thing is the more verts in you sprite meshes the more accurate it is, so it might be worth making the mesh's more detailed in Spine.
As Pharan says 'Pillow shading' or the artifacts on the seem between the dudes hand / wrist look like they might be from the normal map, I'm getting the same thing with normal maps I've auto generated, basically the normal map saying they're a bump where there should be so you'll need to hand edit the normal maps to remove the edgeing on the base of the hand etc
13 Mar 2016, 16:32
Ok I've added the option to define and use a fixed normal (eg float3(0,0,-1) for Spine sprites) instead of ones in built for the model 
(Update in the zip in first post as usual)
Its actually pretty usefull for my game as means I can use the Sprites shaders to render textured text meshes which don't have normals built in.
Hi,
Is there any gains by not using Spine normal for the Shader ? Do you think it's the best way to go ?
Thanks
Thought about it: It's mostly just stupid to have to define the same normal value, say, 400 times or 10000 times across all sprites, when you could just give it to the shader/material once as the single value that it is.
But it's also less data for the mesh to hold, less data for Unity's dynamic batcher to crunch through, less data to pass to the GPU.
It's not a lot in absolute terms. That's usually the case with these things.
You probably won't see palpable gains until you have hundreds of Spine skeletons (or any collection of meshes with tens of thousands of verts).
Best way to go?
Unless you're doing something advanced that requires unique normal values per vertex, I vote yes.
Thanks for the explanations !
