Цей сайт найкраще переглядати в сучасному браузері з включеним JavaScript.

Texture UVs assigned incorrectly on some body parts

Xelnath

This is what it's supposed to look like. Note the ponytail and big 'sun' icon on the chest.

This is what shows up in the game.

This is what is shown when I look at it in the unity editor. Somehow, the components with WeightedMesh are not getting their UVs assigned correctly. Any ideas?

I don't think it's user error. I've wiped out all custom changes to my Spine version and am just using the most recent Spine 3.3.07 and the SpineUnity runtime. If not, please advise.

I don't think this is an import issue either - the material used for the chest piece is the same as the one used for the boots.

Pharan

Can you send me these assets, Xelnath?
I'd like to debug.

unity@esotericsoftware.com

Xelnath

incoming

Pharan

I got the stuff. Why do you have untrimmed parts images? That'll be terrible when the texture is packed.

Oh, I think I know what's going on.
Remember how whitespace stripping doesn't play nice with meshes? That still applies. Texture Packing - Spine User Guide

If you or your artist/animator is working on any other skeletons, I recommend you immediately trim all your parts images and realign your images your before continuing any work.

Your images should be trimmed. Not like this. This will kill your GPU.

Xelnath

Oh geez. 🙁

I thought whitespace stripping was possible to do in Spine - did not notice the caveat. We wanted left some extra space in the source image so that our concept artist could paint over the character's raw assets without needing to get it re-rigged each time she needed to make a single part larger.

As you can see, the current skeleton is just a greyscale figure to help get proportions and such right. The idea is to then hand-off to a character artist who will paint in colors, details and a bump-map for lighting.

What's causing the white space stripping to play poorly with meshes?

Even more specifically - is this a "haven't yet fixed", "it can't be fixed" or "it could be, but won't be fixed" issue?

It seems liked this should just be a coordinate mapping issue, but I am still a novice in this area.

Pharan

You may want to read this: Patch for trimmed atlas meshes in c-sharp/unity.
If you use that runtime patch, you may see why it's not ideal, or it may work for you based on very particular image shapes and settings. But it is not reliable.

The essence of it is this:
If you map a mesh on an untrimmed 500x500 image, and it gets stripped to 300x100, where are those coordinates supposed to go if they go outside of the 300x100 area?
Current behavior is that the coordinates get scaled down to fit in the 300x100 area.
The patch above causes those coordinates to stay unscaled but bleed into other regions, which could be any other atlas region.
Also consider that the texture packing step can exist separately from the skeleton export, especially when you have multiple skeletons share one atlas. So it has no knowledge of meshes or UV coordinates or whatever.

I think It's not something to "fix" as it is something to inform the user of, and maybe recommend solutions for.
In any case, the real solution is in the texture packer + Spine editor. There's not much we can do on the runtime end.

Xelnath

Yeah, at this point in time I did not consider the texture packer to be a separate function from the Spine editor. Because the solution to the challenge you just posed would be to extend the bounds of the 'packed' texture based upon how much empty space was used in the asset. Essentially create fake bounding boxes expanding the used size of the packed asset.

tl;dr - linking the exporter and the editor more closely in sequence.

With some experimentation, I was able to confirm that we only needed to trim the mesh assets, which is sufficient for us to move forward.

Anyhow, thanks for the information. Quite an annoying usability issue, but small in scope as it only cost us a few hours to fix.