Okay, at the very least we can properly define limitations for users so a certain set of things simply means "no, you can't do that. It logically doesn't work."
In that context, my current problem is that using flipX makes the sprite lit from the wrong side.
19 Jul 2016 6:37 pm
Okay, I think I've hammered out the bugs on the C# side.
On the shader side, it's been helpful to optionally remove the normals transformation but not the tangent transformation.
Removing the normals transformation causes the shader to pretend that the normals are always pointed at the camera. The paradigm is explained above.
Loading Image
vertexlit with normal map
This setup works correctly with:
- Unity Transform negative scale
- Unity Transform Z rotation (aka 2D rotation)
- skeleton FlipX and FlipY
- any bone rotation
- bone or attachment negative scale (in other words, flipping, and backwards triangles)
- bent weighted meshes (as far as I can tell)
- meshes with submeshes.
It doesn't work with Unity Transform 180º Y rotation, even with with fixed camera-space normals and transformed tangents.
The result is that X is correctly rotated, but Y is not. But I think this is handled on the shader side; it has something to do with how the shader treats the calculated binormal.
Optimizations are likely to be done in the future on RegionAttachments.
Normal shader limitations will apply. For example: Multipass forward (pixel) lighting requires depth buffer writes to prevent overlapping light passes. But writing to the depth buffer, which also causes hard alpha blending behavior, requires z spacing, and will cause 180º rotation to not work (the spacing would be backwards).
And for the love of all good things, disable backface culling on your shaders if you're using them on sprites. (ToddRiver's SpriteShaders is fine.)
Loading Image
