• Editor

  • Moving parent bone without moving image Issue

    영어
Related Discussions
...

Hi Guys,

I just want to check that this isn't something 'wrong' in Spine?

As a workflow, what I am aiming for is importing images from Photoshop using json file. Then in Spine, create a bone for each slot, then set up hierarchies etc to animate with. As a part of this process, I want to be able to move the bones into position (using the 'don't move the image, only the bone' button). This all works as intended. I go away and set up some animations...great!

Now lets say one of the 2d Artists edits a layer in the PSD file, or even just renames a layer. I want to export again to Spine, and the images come in fine. BUT...if I've offset a bone that had a slot and image below it, that is now offset.

Is the only way around this to create extra bones in the hierarchy rather than using the 'don't move the image, only the bone' button?

It means my skeleton is going to be overly complex.

Any help is appreciated as this is a pipeline we are trying to get right from the start of the project.

Thanks
Matt

Obviously, we can't reimport from json file as this wipes out any hierarchy/animation already done!

It's great you are considering your pipeline before doing a huge amount of work. I wish more people would take the time to do this!

I want to export again to Spine, and the images come in fine.

I can't tell what you are doing from this. Are you importing the data from Photoshop into a new skeleton? Or into your existing skeleton? Are you not using Import Data again and manually creating attachments? If so, that won't affect any bones or attachments you've moved, so I don't understand the problem you are having.

My guess is that you want to import data into your existing skeleton (uncheck New project to see more options):

Import - Spine User Guide: Data

 Loading Image

Choosing Ignore will prevent changing existing attachments, so if you've moved the attachment (by moving the bone with compensation) the attachment will stay where you have them.

Regardless whether you choose Ignore or Replace for Existing attachments, if a bone already exists, it won't be changed by Import Data.

Hi Nate, thanks for the rapid response!
I'll run you through what I did (as best as I can remember! As I didnt keep the file in its broken state #sillyme)

  1. Initial export of Photoshop layers to Spine WITH JSON file
  2. In Spine Import data (using the JSON file) This gave me a root bone with Slots containing the images from Photoshop.
  3. Selected all the Slots and created new bones (1 for each slot)
  4. Edited the placement of some of the bones using the 'don't affect images button'
  5. At this point, after talking to an engineer, we decided to edit the names of some of the layers, so back to Photoshop and edit the names.
  6. Re-exported from Photoshop to Spine.

At this point I went back to Spine, only to notice a few of my images (the slots) had moved, and of course, at this point, I didn't know why.
I had NOT imported data at this point. I had only updated the images in photoshop, and nothing had been touched in Spine, but for some reason, the images that I had moved the bone position on had moved exactly the amount that I had moved the bone and were now offset by that amount.

The above info you've provided is really useful, however as the images updated 'behind the scenes' before I had come back into Spine, I had no control or understanding of why the images had offset just from re-exporting them from Photoshop.

I think what I am trying to understand is, what is it that made the images move, just from re-exporting from Photoshop?

The reason this is so important is, I am not creating the images, someone else is, and I want to be sure that as he is working in parallel with me first creating sketches, then final art, that I as the Spine person, do not have to wait for all the art to be finalized before I can start setting up and animating. I need to be sure that whatever process I do in Spine isn't going to break if I get updated art.

I hope this makes sense. Let me know if you have any insight into this.

Many Thanks,

Matt

*EDIT - Are you saying that IF the assets are offset for whatever reason, r-Importing data to the existing skeleton should fix it?

**EDIT I am all about the pipeline!

Indeed, it is strange that just by changing the layers’ name, the position of the attachments (a slot is just a container, so we call what is in the slot, such as the actual image, as an attachment) would be misaligned.

However, there is a possibility that the scale or padding settings were different the first time and the second time you exported. The default settings in PhotoshopToSpine are 100% for scale and 1px for padding, and these settings are reset to default after quitting and reopening Photoshop, so it is possible that you thought you exported with the same settings and misunderstood.
Do you recall changing the scale or padding?

It IS possible that I may have changed the padding thinking I had it on 2 initially. Would that have the effect of moving the image the exact distance the bone was moved? I definitely didn't change scale. Also, would there be a reason it only affected a few of the slots and not all of them in this case?

Also for future reference, when the artist works on replacing sketches with Final art, and if these images differ in size from the originals, is that also going to offset images in the spine file?

I'm currently looking at adding in redundant bones to make sure (as much as possible) this doesn't affect us, but my worry is that this in itself is adding complexity.

If the new art is replaced in the folder without a reimport using the json in Spine, and the new art has a different size, yes the images will offset in Spine.
But as mentioned, if you also use the json to realign the images, then they are going to be realigned.
The general advice is to make sure the height and width match perfectly, so in case you had already drawn meshes, you won't need to redo those. If you don't use meshes or don't make them before the art is replaced, then this won't be an issue.

What would the redundant bones achieve?

Can I make a small suggestion also? In the json file exported from Photoshop, Would it be worth storing the Scale and Padding info? That way IF someone comes along and re-exports from Photoshop, they can check their settings are the same as the previous export.

Spine watches your images folder and reloads image files that change. That never changes attachment positions. It may change mesh UVs, but if so Spine will show you a dialog asking what you want.

The image for a region attachment is drawn so the center of the image is at the region attachment position. If you change the image size, the new image is centered and it may appear that the region attachment has moved, but it has not. If you want to use placeholder art, you can make it large enough to contain whatever the final art will be. That way your placeholder and final art images can be the same size and so will be positioned the same when centered at the region attachment position.

The position of mesh attachments is a list of mesh vertices. Each vertex has a position. Like the region attachment position, those are never moved automatically from changing the image size. Each vertex maps to a position on the image, called a UV or "texture coordinate". The image is stretched so that the UV is under each vertex, allowing you to move a vertex to deform the image. UVs are stored as a percentage of the image dimensions, eg 30%,20%. This means when you resize an image, the UVs stretch too. If you resized the image only to add whitespace around the edges then you don't want the UVs to stretch

that is what answering Yes on the dialog linked above is for. If you answer know, then Spine changes nothing and continues using the same UV percentages. If you do answer Yes, you can use undo to undo the UV adjustment so you can better understand the change that is made (look in Edit Mesh mode, with Deformed unchecked).

For placeholder art you might want to use region attachments, only making a region attachment into a mesh attachment when you have final art. It's still useful to understand how updating mesh images works, as final art is seldom actually final. 🙂

One way to have your attachment images large enough for future art is to not trim whitespace. Every image will be full size, with lots of whitespace. This will work fine in Spine, which is smart about making selections. When you pack an atlas at runtime, you can use whitespace stripping so the large images don't take up any extra space.

If you prefer more control over the size of each of your attachment images, you can use layer masks:
https://github.com/EsotericSoftware/spine-scripts/tree/master/photoshop#layer-masks

I like the idea of the PhotoshopToSpine script writing some extra data to the JSON file. We've done that in the latest script, v7.31. Spine just ignores the extra information.

"PhotoshopToSpine": { "scale": 1, "padding": 1, "trim": true },

Thanks for that info Nate, much appreciated. Whilst testing/investigating this, I found that when dropping an image onto a bone, sometimes the image and slot get offset by 0.5? Is this to counter the fact that the image is of odd-numbered pixels in width/height? I also found sometimes that Images have a 0.0001 offset (rounding error?)

Is there a way to Always get an image/slot to have Zeroe'd out values in translation? Or could whitespace be trimmed to only even-numbered pixel sizes?

We are going to look at using non trimmed whitespace images to make sure everything is 'exactly where it should be all the time'.

Thanks for all the help!

matt_foxfuelled wrote

I found that when dropping an image onto a bone, sometimes the image and slot get offset by 0.5? Is this to counter the fact that the image is of odd-numbered pixels in width/height?

Yes. Since the image is centered, when it has even (not odd) dimensions it needs to be offset 0.5 so the image pixels match screen pixels at 100% zoom. This matters sometimes, depending on what you are doing.

matt_foxfuelled wrote

Is there a way to Always get an image/slot to have Zeroe'd out values in translation? Or could whitespace be trimmed to only even-numbered pixel sizes?

There aren't features to do those things. Usually it either doesn't matter or you want the 0.5 offset. When do you find you don't want the offset?

matt_foxfuelled wrote

I also found sometimes that Images have a 0.0001 offset (rounding error?)

Probably you have World or Local axes selected. Math is required to show those values and precision is limited. You'll see the actual values by selecting Parent, since the translation values are stored in the parent coordinates.