hmm, both the normals and the tangents are in model space. Normals will always be the same for Spine animations but tangents are unknown & have to be calcluated. They are only used for bump mapping though.
So for bump mapping the shader ultimately needs to work out a normal direction in worldspace to bounce light off correctly. This is done by reading a direction from the normal map texture, and then converting it into world space.
To do this for any vert you need the model space normal (which yep will be (0,0,-1) for spine sprites), plus the modelspace tangent which can be any perpendicular direction to that normal. The tangent will let the vert know what way 'up' its normal map textures is by pointing along the direction of its mapped texture.
If you had a spine animation where every textured mesh in it had its texture aligned with the screen (ie not rotated / just dragged and dropped from the image folder) then all the tangents would be (1,0,0).
If one of those meshes was rotated by 90cw then its verts tangents should be (0,1,0). If the tangent is still (1,0,0) then the world space normal caluclated by the shader will be incorrect (ie also 90 degrees out), so you get some meshes lit incorrectly like the dragon above.
So for correct bump mapped lighting in Spine we dont need to pass the normals to the shader in or even store them on the mesh, but we do need to calculate tangents using something like that tangent sovler. They might be a more optimised way of doing it though!
I get it now.
I guess one option is to store it with the attachments at load time, and have their ComputeWorldVertices method return bone-transformed world vertex tangents accordingly for SkeletonRenderer to use.
It's too bad those are on the spine-csharp side but that shouldn't be a hindrance for people who are really after it.
I've replaced SkeletonRenderer.cs and included SpineTangentSolver.cs but it doesn't seem to change anything..
Huge thanks to you Todd. You've done a lot to help and you're not even part of the spine team :clap: , but this really shouldn't be necessary.
3rd party tools shouldn't be breaking core parts of unity..
The problem seems to be related to the way that spine rotates the images (maybe in local space instead of tangent space??), as non-spine images don't have this problem when rotated.
I can rotate the sprite map and the angle is known by the unity lighting engine and the lighting on the surface is updated correctly.
However for spine models using the spine system (even the ones that are then built in unity), any rotation on objects is done in a way that the unity lighting system doesn't recognise.
Even if I manually rotate spine models in unity (even ones built in unity), the lighting doesn't update to respect the rotation..
However if I use unity's standard bone animation I can use standard or custom shaders and unity's lighting respects the rotation of the object.
If this is not fixed I'll probably just give up and go back to the standard unity animation system.
Spine did seem like the most popular system for unity animation but it completely breaks other parts of Unity..
Hmm sorry I think I might've uploaded a broken SkeletonRenderer.cs.
I do have go this all working locally so it is possible, but yeah Spines unity runtime needs to be changed to build proper tangents - without them bump lighting just can't work.
Could you try downloading the shaders package from the first post again? I've added my current skeletonrenderer and tangent solver to it. Hopefully that should sort things, its def working for me now finally!
Also I've added a 'SpineFlipper' component I've been using to flip spine animations in the editor, which you should be doing instead of rotating the sprite 180 around the Yaixs or giving it negative scale. (Just add the component to a gameobject with a SkeletonAnimation and then you can set the two flip flags to flip animation in the scene view).
@Pharan I've also found a bug with the BoneFollower component which means it doesn work properly when the skeleon is flipped. I can share my fix with you if you want?
Hmm sorry I think I might've uploaded a broken SkeletonRenderer.cs.
I do have go this all working locally so it is possible, but yeah Spines unity runtime needs to be changed to build proper tangents - without them bump lighting just can't work.
Could you try downloading the shaders package from the first post again? I've added my current skeletonrenderer and tangent solver to it. Hopefully that should sort things, its def working for me now finally!
Also I've added a 'SpineFlipper' component I've been using to flip spine animations in the editor, which you should be doing instead of rotating the sprite 180 around the Yaixs or giving it negative scale. (Just add the component to a gameobject with a SkeletonAnimation and then you can set the two flip flags to flip animation in the scene view).
@Pharan I've also found a bug with the BoneFollower component which means it doesn work properly when the skeleon is flipped. I can share my fix with you if you want?
I've re-downloaded the attachment from the original post and started a new project as the original one seems to have coloured all of the textures a flat bright pink.
I've imported spine-unity and SpriteShaders.unitypackage.
I've baked a dragon from the Examples folder and changed the shader on the dragon's material the Game/Sprite Pixel Lit.
I've included a directional light and am getting the same results as before.
However, I haven't been able to find this window:
Image removed due to the lack of support for HTTPS. | Show Anyway
The script "Skeleton Animation" doesn't seem to exist in my project:
These are the scripts I can add as components to the prefab:
Ok I've switched to an example scene which includes the dragon as a spine object rather than a baked unity object.
This time I get the Skeleton Animation component appearing and I have selected the 2 required options.
However, the lighting is still incorrect. This is most obvious on the tail where some segments are lit from below and some from above:
Also, the rear leg is lit from above but the rear foot is lit from below.
26 Mar 2016, 11:31
Here's a video of spine lighting from over a year ago by the developer.
There seems to have been no progress in over a year on this
This is the effect I'm wanting.
How do I achieve it?
26 Mar 2016, 12:48
I've exported a brand new version of SpineBoy with atlas rotation turned off.
When I light him up in Unity the lighting is now correct on all body parts!
Success!
Actually, not quite..
As soon as I select an animation, the lighting doesn't update correctly based upon the new rotations
As you can see, his rear leg appears to be lit from the bottom by the bright blue/white light (really it's being lit from the top right).
But he does look really good with just a couple of lights.
It's a real shame that spine isn't compatible with unity shaders and lighting
(unity shaders are one of, if not the most important, parts of unity - without shaders nothing would be drawn to the screen - I can't comprehend how an animation modelling system wouldn't be compatible with the core process of drawing things to the screen - it kind of defeats the purpose)
Thanks Todd for all your hard work on writing custom shaders for spine, but really spine should be compatible with any of the other custom shaders for unity and most certainly the default shaders..
I could go one but there's no point.
I'll just get a refund on Spine and if they ever fix their tool to be compatible with Unity I will purchase it again.
Normal mapping 2D things is complex. 3D lighting on 2D things is complex. None of these things are now nor have ever been part of Spine. I'm sorry you were deceived, but MageLight is a personal project of mine and a friend's and not part of Spine.
Also, since we're pulling on the same thread as Mitch was, the theoretical solution for the simple case is to rotate the tangent according to bone rotation + region offset rotation + setup pose rotation. That setup pose+offset value thing is probably where storing a value in the attachment class is helpful.
For meshes and weights, I guess the theory is still to have its CalculateWorldVertices also rotate its tangents, taking FFD and weights into consideration. The "setup pose" tangent values are probably according to UVs like you said.
Having followed this thread for some weeks, I've started to experiment with the shaders:
Image removed due to the lack of support for HTTPS. | Show Anyway
The developer of Sprite Dlight very helpfully exported a couple of normal maps to test with, clearly there are some unpleasant seam artifacts that you can spot between limb sections, we're talking about ways to sort that out.
Running into the problem that Stevepunk described, with the tangents not taking into account the rotations. It sounds rather complicated to me, anyone think it's solvable?
For region attachments, it's solvable; no doubt about it. Meshes with weights and FFD is a bit complicated.
The pillowed joint seams are a problem on the normal map generator side though. Those programs need to have a way to define areas where parts need to blend into each other.
For region attachments, it's solvable; no doubt about it. Meshes with weights and FFD is a bit complicated.
That's great news. I think supporting attachments would be the minimum, and maybe for most uses it would provide results that would be 'close enough', despite slight inaccuracies when vertexs are deformed.
Pharan wrote
The pillowed joint seams are a problem on the normal map generator side though. Those programs need to have a way to define areas where parts need to blend into each other.
Yes indeed! I'm less concerned about this one.
Found an issue with the shader, I tend to use slot colouring to shade different parts of my game's zoo visitors, but the shader seems to colour them with a pinkish hue?
Image removed due to the lack of support for HTTPS. | Show Anyway
Hey sorry haven't checked the replies on this thread for a while!
Locally I have lighting working with normal maps perfectly now so am a little confused why its not working for you guys - let me put together an example scene based on the sprite unity example to show how I'm using everything. It should all be easy enough.
One thing to look out for is how you generate sprite normals - they need to be facing the correct directions themselves otherwise things will never work. You can in theory pack them rotated but make super sure their all generated facing the same direction. I'm using Sprite Illuminator by the TexturePackerPro guys and that seems to be pretty awesome.
@Pharan The tangents are working even for deformed meshes using my current method. Using a solver function that calculates the tangent for each vert based on the other verts it shares a triangle with and their UVs means it will always be correct. It just needs to only happen when UVs or verts actually change.
@Cranktrain huh, I guess slot coloring just changes the vert colors behind the scene? Don't know why that wouldn't work.. could be a bug with the shaders I've never used vert colors. Let me check!
Cool. Ok I totally missed the lastest big Spine update, which is why my last shader package wasn't working for peops.
I've now grabbed it and updated the code to work with it. Saw you left some nice comments for where to hook in the tangent stuff
I'm not 100% of the new mesh generation flow so its worth grabbing it and having a look at what I've changed to SkeletonRenderer.
Also see you dropped in the skeleton utility component for flipping in editor, nice!
Anyways yep, grab the latest package in the first post in order to have normal maps work with the latest spine!
Oops my bad I thought you could now use the flip flags on the utility to properly flip spine animations in scenes but its not serialised so it revert back when you enter play mode - its cool I've got a component that does it anyways.
Plus yeah must've been a while since I grabbed it - all the SubmeshInstruction stuff is new. But yeah looks a lot tidier!
@ToddRivers thank you very much for sharing this and putting the work into it.
Just to let you know. I just downloaded the shaders from the first post and importeted it and got some skeletonrendere errors. As it seems this has been mentioned before so I don't know if this is helpful.
Hey! Sorry I fixed the shaders locally to work with the latest spine-unity runtimes but forgot to post them!
If you grab latest from the first post they should all be working (I also removed some out of date info/intructions from that post).
@Pharan been a while dude! is there any chance the tangent solver could become part of the spine unity runtimes? Otherwise I and others have to always redo the changes to spine code after they update thier runtimes.
The tangent solving function is in its own class which you're free to take and I simply made the following change to SkeletonRenderer:
Inside the check to see if triangles should be updated (around line 652), just bellow
for (int i = 0; i < submeshCount; ++i)
currentMesh.SetTriangles(submeshes.Items.triangles, i);
Working on spine-unity 3.3 right now. Will have a look at it after!
Thanks for the code! I may put the tangent solver itself in one of the MeshGeneration classes.
Hey Pharan! I've updated the shaders and tangent code to work with Spine 3.4 (looking forward to properly playing around with the new editor stuff for 3.4 btw!)
I'm now using the render separator stuff to render a Unity Cloth mesh in between a sprite attachments and realised the tangent code isn't working with that stuff so I've had to expose the tangents to some of those classes.
Anyways all the tangent stuff is now working with latest. It would be sweet if it could be added to the spine-unity runtimes so the calculate tangents flag works (meaning me and others using bump maps don't have to edit the files everytime we grab the latest spine runtimes).
These are the files I had to edit:
Great! You're still in the forums. I was a bit worried!
I was wondering if I could ask you some things about it 'cause I just crossed a few things out in my list, and I think making the changes to incorporate the optional tangent solver is a good thing to do next.
Thanks for the info!
Loading...
Something went wrong while trying to load the full version of this site. Try hard-refreshing this page to fix the error.
