Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Stripping WhiteSpace and Mesh animations

vallcrist

Erika

When you export using whitespace stripping, Spine warns you that it may ruin meshes:

(it is also mentioned in the user guide Meshes - Spine User Guide: Whitespace stripping and the FAQ Support: Why are meshes not displaying correctly )

We have two related issues for this: Whitespacing trimming for meshes · #260 · EsotericSoftware/spine-editor and Prompt for user decision when mesh images are resized · #205 · EsotericSoftware/spine-editor
Unfortunately, none of them are implemented or close to implementation.

This is also why it is recommended to use the Photoshop to Spine script spine-scripts/photoshop at master · EsotericSoftware/spine-scripts as it will automatically trim all the images before they are even imported in Spine, avoiding the need to trim any whitespace at all.

vallcrist

Hey Erikari, thanks for the swift response.

I am aware of the error messages, as I stated in my post. This was an error my artists made, no doubt on that.
My post was more about asking if there is any way I can turn this around without investing a lot of work hours into reanimating stuff. Maybe a different Region drawing function that accounts for trimmed whitespaces in atlas or something like that?

Pharan

The work wouldn't necessarily be reanimating stuff. It could be calculating the bounds of the mesh mapping, trimming the images in Photoshop and doing some math again to fix the mapping of the mesh(es).

On the Unity renderer side, we would have done this already if it was reliable to do so.
The limitation has to do with the fact that mesh shapes are predefined by the user.
The likely scenario has always been that the mapping of the meshes that use untrimmed backing images would bleed into the other parts of the atlas if the whitespace was removed, so when you render them, you'll see other images in your mesh.

SpriteUV

Hi vallcrist!

Maybe this post could help you ?

SUV2 v1.5: auto React->Mesh conversion, whitespace stripping

Earlybird

hi,
I know this is an older post now but I wanted to check if whitespace trimming on mesh assets is still a problem? I've been getting some odd results when using a mesh with the sequence feature (which is amazing by the way!!) with the trimming on and im unsure if its just the sequence or the mesh thats causing it.

I remember seeing something about spine using mesh regions to packing its assets closer together a while back and thought that would include the support for trimming on mesh as well? unless its a feature I need to turn on somewhere in the export settings?
I mean i get that if you remove whitespace from within the mesh region it'll break but I thought maybe it was able to remove white space from outside of the mesh region and still function correctly??

^^ more of a question than a problem, I can easily work around this in my situation 😉

Misaki

Strip whitespace X/Y should work even if the skeleton has Sequence attachments. However, as a specification of the sequence attachment, if the sequence has different size frames and mesh is enabled, the mesh vertices stay in the same positions so only the texture changes. A smaller or larger image is scaled across the mesh vertices, so I assume that this is the reason you are getting weird results. If that behavior is undesired, you need to use the same size images for your sequence.

I remember seeing something about spine using mesh regions to packing its assets closer together a while back

Perhaps you are referring to polygonal texture packing:
Blog: Spine 3.8 released: Polygonal texture packing
Texture packing - Spine User Guide: Packing2

If the above answer does not solve your problem, I would appreciate it if you could describe the current result in more detail.

Earlybird

Hi Misaki,
Yeah the poly texture packing was exactly what I was referring to before.. thanks for the link :yes:

in my particular situation I have an image sequence where all the images are set to be the same size when importing them into spine. I'm using the sequence feature (which i assume is using a linked mesh) for some reason I was expecting that on export (with poly packing and white space trimming enabled) that spine would be able to trim the whitespace knowing where not to view the overlapping uvs from the atlas.. although thinking about it now im not sure if its possible, maybe if I used separate meshes for each frame? but that wouldn't work for my purpose so for now im disabling 'white space trimming' unless you know of a better way?

update
So I thought i'd try creating the sequence using individual mesh layers (not using the new sequence feature or linked mesh) and it exports fine but seems to be ignoring the white space trimming.. I guess because its not supported on mesh. which would answer why we've never seen an issue before I guess 😃

Nate

The image for a mesh can be whitespace stripped, but Spine will use the maximal rectangular bounds when packing rectangles or the union of polygonal bounds if packing polygons of all meshes that use that image. That way in an app the textures can simply be swapped by the Spine Runtime.

Looks like you found a bug with sequence meshes and whitespace stripping: those meshes don't get whitespace stripped. We'll get it fixed in 4.1.17 and release that soon! Thanks for letting us know.

Earlybird

Thanks Nate!
by the way I had to go back to a previous version of spine to support an older game.. the sequence feature is a game changer thank you! :yes:

saleklar

Hello guys! I was looking for the solution for this problem and stumbled on this thread. I am using 4.1.24 and still, white space is not stripped from sequence meshes. If that bug was fixed in earlier updates, it seems it is back now 🙂

Misaki

saleklar We appreciate you reporting the problem, but unfortunately 4.1 is no longer being updated and any bugs found in it cannot be fixed. If you are experiencing the same problem in the latest 4.2, we would appreciate it if you could start a new thread and tell us how to reproduce it.