FeedMyData

Hi,

I am encoutering issues when updating images.
Let say I have a 60x50 image with a mesh, and several bones having weight on it.
Now, our artist see that there is an issue on the image, reexport it and the image change size becoming 60x55 or 60x48.

When I update the new image I get the image resize promt. Here, whatever I tick: "Yes" or "No", the result will be messed up.
In my case the image end up in both way too big than what it should be.

It appears that if I do "Reset Deformation", the image will be back to how it should be, but I will loose all my "weight" work. It's a bit awful if any tiny tweak from our artist break my work.

Is this a normal behavior? I'm kind of scratching my head right now.

Especially since I intended to create skin duplicating my base mesh and applying different image with different proportion, then tweaking my mesh by hand, so the new image would fit in it.

---

Digging in the forum, I understand that it is the normal behavior. It's a bit of a bummer since there is no flexibility in the workflow and changing a sprite linked to a mesh is destructive.

The two dedicated video tutorial I watch were kinda avoiding this issue :
- The first one was creating a new skin, with image that had the exact same proportion, and without using meshes it seems : https://www.youtube.com/watch?v=81XU7Uqpm6E&t=172s
- The second was creating a new skin, with different proportion, but without using meshes : https://www.youtube.com/watch?v=p7yZET00GeE

I've seen on some old post that you were thinking of a solution to implement skin / image replacement with different proportion while keeping the mesh work. Is there any news?

I'm kinda trying to build a character where I will be later able to add new skins. I want to recycle as much animation work as possible to avoid that the cost of each skin skyrocket.
Avatar utente
FeedMyData
  • Messaggi: 11

Abelius

Hi there,

This is indeed one of the things I've been having my own problems with, because I also get lots of minor adjustment images and even new images based on the original (like an arm with some fur when the previous one didn't have).

You may have found some post of mine about it in the forum and yes, Nate explained it happens because the pivot or "center" point of a meshed image changes when you modify their general "dimensions". The moment you delete the outer vertices, you're changing its "center".

I don't know if they'll change this behavior in some future version, but I've been using some workarounds these years. Let's explain...

What you want is that center doesn't change from one version to another. And for that, Spine needs to think both images are either identical (or symmetrically proportional, so the re-scale feature actually works well).

At this point you don't have neither of those, so what you can do is choosing one of the following...:


a) Fit the new image into the old size.

For this to work out you need to leave a generous padding space in all images. I'm not talking about 8 pixels on each side, but something like 64px.

That will will you an extra space for when you receive the new exported PNGs from the artist, you could use GIMP like this:

1.- Load the old image first, so the canvas size is set to the original
2.- Drag the new image into GIMP
3.- Move it so it matches the old image
4.- Hide the old layer
5.- Export the whole thing as PNG, overwriting the old image

Spine won't ask you anything, because the size wasn't changed, and you'll be able to modify the mesh to include the new area.

Cons of this method are that it's a manual process for every image, and you may run out of space if the change is too big.


b) Export at canvas size.

This is what I'm currently doing myself, much more flexible but comes at a cost.

First of all, you need to settle to a canvas size for the whole model with your artist. Mine was using ludicrously large dimensions on both vertical and horizontal axis. What you want is something you know it will be enough for additional future images like a backpack, a tall hat, etc., without needing to expand the canvas.

For example, models don't need much padding on the bottom because that's where their feet and typical root bone are. They may need more on the top, for some large hat. The sides are tricky and will depend on what you want. A backpack won't occupy much space, but a long tail could.

When you settle to that canvas size, you need to make a list of images with "some probability to be changed", In my case it's almost every body part, like the legs, torso, arms, feet, even the hands, etc. Also any part that derives from them, like tight-fitting clothes that go on top.

All of those you export them at canvas size. And from now on, your problems are gone because they'll always be the same size and have the same perceived center.

Of course this means you'll end up with HUGE images in which 90% of the space will be transparent. It's a performance hit for Spine, a lot more VRAM is used so you need a nice graphics card, and whatever you do you'll need to wait a bit for images loading every time you change skins.

However, from that point on your artist will be able to modify those parts without any worries if they're one pixel larger. You just overwrite for the fixes, and make linked meshes for the new parts. As easy as that, no manual tweaking needed.

As a bonus, you could still expand the canvas size in case it's not enough. BUT you'd need to expand it by a fixed percentage on all sides, so the pivot point or center Spine detects is still in the same place. Then Spine will detect a new size for the meshed images and offer you to re-scale the meshes. You can say yes because this time the new image is symmetrically proportional and everything will fit correctly. I actually didn't need to do this yet, but it's nice to know you can in case you underestimated the canvas size.

Ah, if you're worried about stupidly huge atlases, fear not. When Spine packs the atlases it won't include those huge transparent areas, so the only thing you're paying for this is a performance hit only when loading images.

Also, Spine is very stable right now working with these big images. I uncovered some memory leak issue because of this way of working of mine, and the devs quickly fixed them.

I know it's not an ideal solution, but it works for me.
Avatar utente
Abelius
  • Messaggi: 198

FeedMyData

Hi Abelius,

Thanks a lot for your answer and sorry to read it only so late. It makes a lot of sense. The solution B could work indeed. I love those kind of clever workaround. I did a quick test and it seems that when exporting, Spine is indeed removing all the unused white space. This is great!
I'm not sure if I will use it. We will try at first to optimize our process while producing assets to avoid those issue as much as possible. We ran into those issue since it was our first time doing this, and we rushed. Loads of sprite had default we could have spotted before starting to animate.

Thanks again!

---

I read your post here : I need to know how horrible is the thing I'm gonna do...
And even though it took me 3 weeks to write a first answer, i still answered too fast.

Your b) solution seems the go to for big projects with lots of skins having different proportions. I'm gonna do the same as you. It's resolving a lot of issues of mine.
On the long run I'm gonna save a lot of time. Thanks for that!

I'm having like you also stupidly high rez images to support newer mobile device and to have futur proof assets (like 3820x2000 x 50). Even with a low range hardware (1050ti) I'm pleased to see that I can import everything without crash, without even using the scaling down features. I did not do all the mesh work and animation, but it looks promising. As you said, except when launching the project (which takes a minute now), everything seems to be the same.
Avatar utente
FeedMyData
  • Messaggi: 11

Abelius

Happy to help!

You people will slowly give in to my evil ways, har har! :devil:
Avatar utente
Abelius
  • Messaggi: 198

Alchemi

Hi There. I'm having this issue too from what I can tell. I've only just started on the program
How it looks when i tick "yes" Below, when I tick "no" nothing shows up at all. You'll see here that this new image automatically gets deformed way more than the original image was
Deformedd.JPG


When I uncheck deformation in the mesh you can see how drastic the difference is.

Undeformed.JPG


I dont know if your (A) or (B) fixes will work with this and I'm not fully understanding them, i seem to only grasp how to use this program by watching videos

At this point I guess i'll have to start fresh and re mesh, weight and animate... sigh
Non hai i permessi necessari per visualizzare i file allegati in questo messaggio.
Alchemi
  • Messaggi: 1

FeedMyData

Hi Alchemi, did you increase the resolution of your image?

I will try to reformulate Abelius' B) solution to help you understand it.
The goal of this solution is to be able to change an image with another that have "slightly" different resolution, while keeping the current mesh and weight work. Yet, what we mean by a different resolution is not going from 512x512px to 2048x2048px. There is other solution in Spine to deal with this. The goal is to change the 512x512px image by a 510x520px for example. The solution allows you to keep your mesh and weight work. You will still likely need to readapt it a bit but you won't have to start from scratch again.

How the solution work? When you want to export from your image creation software, rather than exporting each png without any blank space around it - like when you do "quick export into png" inphotoshop - you will export each png at your working canvas / artboard size - like you would do if on photoshop you do "save as > png". For example, if you create a full character on a 2000x3000 canvas/artboard, when you export juste the left eye, the left eye dimension will not be something like 50x50 but it will be at the canvas/artboard size: 2000x3000, and most of the eye image will juste be transparency.

Why doing this? Let say you realize your character left eye had an issue, and its proportion were wrong. You adjust it in your image creation software so it takes more space on its left. Now, if you don't use the B) technic, Spine will import the image and see that the resolution changed from "50x50" to "50x60"~~ it will not be able to place your image correctly anymore, since the center of your image changed of 10px on one axis (the center has been slightly moved to the left). Imagine this kind of change happens on several images: the nightmare starts. All the new image are displayed wrong, they might all have move according to their new center etc. The only way to solve this would be to reset you mesh and therefore loose all your weight work too.

How would this behave with the b solution? If you change the eye size so it takes more space on the left, now the final image size will not change. It remains the canvas/artboard size: 2000x3000. Therefore, when you import it into spine, the image center remains the same and the image stays in place. It won't be perfect, since you will have to correct your mesh work. The 10 pixel added in the image will likely be cropped according to your mesh work, but you can easily move the vertex, and they will keep their weight.

On to export at canvas/artboard size? When using the photoshop to spine script, uncheck "trim white space".

---

Here the explanation with images. Let say I started with this eye image and this mesh work.

Trim white space / usual workflow
1) I imported everything with the usual workflow using "trim white space".
Screenshot_1.png


2) Now I realize that I don't like the eye and I want to stretch it to look like this the following image.
Screenshot_5.png


3) So I edit the image in my image creation software and I export it again using "trim white space". Here is what happens in Spine:
Screenshot_6.png


4) I correct the mesh and here how it looks. The eye has been moved to the left because the image center changed.
Screenshot_7.png


This is really annoying, especially if it happens to a lot of images simultaneously, everything end up being wrong....

Now with trim white space unchecked / the B solution from Abelius :

1) I export everything from the start at canvas/artboard size, with trim white space unchecked (solution B). My initial mesh work will be similar:
Screenshot_1.png


2) Then I change the eye in my image creation software and reimport in spine. It will look like this:
Screenshot_2.png


3) Now after correcting my mesh, everything looks good.
Screenshot_3.png


For reference, here the difference between the two eye image according to the two workflow: "eye.png" is the eye export with the usual workflow using "trim white space". "eye_canvas_size.png" is the eye export with the b) workflow of Abelius: with "trim white space" unchecked.
Screenshot_4.png


I hope it helps and that it is understandable.
Non hai i permessi necessari per visualizzare i file allegati in questo messaggio.
Avatar utente
FeedMyData
  • Messaggi: 11


Torna a Editor