Great update man!
You mentioned normal maps support in your blog post. I wanted to know if spine will generate the normal map or do we have to use some other tool like spritedlite to generate that? Also, any idea when cocos2dx will start supporting the new features!
Blog post: Finally an update
spine-cocos2dx already supports all the Spine features! The fancy lighting that Unity does is specific to Unity, not really a Spine feature, because Unity does most of the lighting stuff for you. It's possible to do with cocos2d-x, you'd just have to implement it.
Spine doesn't create the normal maps. Like creating the other images used in Spine, you'd need to create them yourself with an external tool. There is Sprite Lamp and Sprite DLight that might help.
This is awesome! Btw a quick suggestion related to the blog post since I almost missed it! Maybe make it more visible that the unity baking image is actually linked to a youtube video 
Great!
One question, are the Unity tk2d Runtimes updated too?
Thanks!
Ionog wroteGreat!
One question, are the Unity tk2d Runtimes updated too?
Thanks!
Not yet. I don't use tk2d for myself so they tend to lag behind heh. Most of the spine-unity features I write are things that I immediately need.
Mitch wroteIonog wroteGreat!
One question, are the Unity tk2d Runtimes updated too?
Thanks!
Not yet. I don't use tk2d for myself so they tend to lag behind heh. Most of the spine-unity features I write are things that I immediately need.
Ok, thanks!
Awesome, thanks for the blog post update! I'm switching to Unity, and the lighting tests get me even more excited about playing around in it 
(and thanks for the links to the two different normal map generator tools).
Nice job, and I appreciate the hard work!
Hi about the normal maps:
- Are you using sprite dlight or sprite lamp in the example the video?
- Author of sprite dlight and me were exchanging emails and he mentioned that the biggest obstacle is having a smooth transition on the joints when normal mapping, is that still an issue?
I need some advice concerning this
Tests were done using sprite dlight. Smooth transitions with normals will always be rough unless you paint them not to be heh.
That being said, I added support for skinned mesh deformation of the normal map by taking the most significant bone for each vertex and passing its rotation to alic's shader as part of a tangent. So in that sense, not really an issue heh
Cool thank you, very awesome to hear that!
6 أيام لاحقا
What is the workflow for normal maps?
Please correct me if I'm wrong, but it looks like we need to take the atlas generated by Spine, use a tool like Sprite DLight to create a normal map for the entire atlas and (likely) tweak it manually.
If we later add an image in Spine, the atlas is regenerated and we'll have to create the normal map again?
It would be great if there was a way to import normal maps into Spine alongside the regular sprites. Either with a file naming scheme, or from a Photoshop file (additional layer group for normal maps or something), and have the export generate a normal map atlas.
Rouven
If you had your normal maps as individual files, Spine would pack them exactly as it does the images, so the two atlases textures would match. If using whitespace stripping, you'd need to be careful that you have exactly the same whitespace in the diffuse and normal images. A tool that generates normals probably does this.
The issue arises in that tools that generate normals don't do an artistically good job and only serve as a decent base layer. Painting inside an alpha mask can be rough with normals.
If you're using meshes then you aren't using whitespace stripping, so it's not an issue. Whitespace stripping is for the lazy anyway, just do it yourself before bringing images into Spine. :p
So basically I create a second project in Spine where I only import the normal map images, making sure everything is exactly like the images in the real project. And then I use that to only export the normal map atlas. Sounds like a feasible workaround, but it's a pain to maintain long-term.
No, much easier. You run Spine's texture packer on your folder of normal images.
Thanks! That's a much better solution 
11 أيام لاحقا
thanks for this awesome update !
عام واحد لاحقا
I just realised I can bake to unity's default standards after watching this video which means I can use standard shaders.
This will save a massive amount of time!
[EDIT:]
Ok so I've tried using the standard shaders on a baked character but I'm getting some strange behaviour.
I've baked a lightmap for the goblin using sprite dlight..
But the results I'm getting are strange..
The point light is to the right so the lighting on the shield is correct (although it refuses to light from the top and bottom (only from left or right).
Despite the head being the same orientation in the atlas, it will only light from the left when the point light is on the bottom left.
On the body top and bottom lighting are reversed and side to side lighting doesn't work at all.
The left and right lighting works on the fist but the upper arm seems to have reversed lighting also.
Honestly, I'm at a loss here.
When the image is flipped (negative x scale), the same problems remain.
[EDIT2]
I did a test on the individual parts and normal mapping just to rule out any problems there (they share the exact same material as the goblin character).
As you can see with a point light on the X they are lighting correctly (even when rotated), but the goblin below still has erratic lighting.
Here's an example where I've rotated the planes to show the lighting remains correct.
So the problem with flipped/rotated normals seems to be the way in which spine rotates the objects.
As for the problem with normals only lighting on 1 axis I'm at a loss..
Have you tried packing the texture with rotation off?