• Runtimes
  • '[mark]' tag for slot and bone group locators

This is my first post so hello and thanks for having me 🙂

We have [bone] tags for groups as a way to set bone information in Photoshop which is handy. The trick part with setting bone locations is that it will find the middle of the first item of the group and use that for the bone location of that group. You can A: mess with the alpha of that object to add or remove white space, or B: set a dummy object at the top of the group to set that location, but this leaves us with two separate issues. The additional alpha may be trimmed away but you'll still need either 1% transparency in the alpha which defeats the purpose of auto trimming the Alpha.

With Option B: the user has far more visual aid as to where the bones are being positioned, you can place down a visual marker and duplicate that into each group which is timely, but much more precise and clear.

The problem with even that method is that you then need to manually name, manage, find and disable those from showing in the final output. It's not that way for [ignored] items but those are not used to determine bone positions simple to to not being used at all in the process.

So my question is why can't we just have a tag that does this: 'ignore, but still use as a marker for slots and bones' So my feeling is that Spine really needs a [mark] tag.

I feel like interoperability between spine and photoshop/krita/affinity should be the absolute top priority until it's a smooth experience to update over to spine. Right now, I do the thousand yard stare at anyone who requests for me to update things from PSD to Spine. I tell them we need a lot more time because we must simply start the entire rig and all animations from scratch as it's THAT much easier than adjusting an existing rig from this senior artist's perspective. The more options to reduce re-doing things from scratch the more I can be motivated not to jump across to COA and simply change it to do what we need.

Kind regards,

Simon.

Related Discussions
...
  • Đã chỉnh sửa
10 ngày sau

Welcome! Sorry for the delayed response.

As you know, a layer marked with [bone] creates a bone at the center of the layer, but I wouldn't suggest sizing a layer solely to get an exact bone position. It would be difficult to be accurate that way. The bone tag is still convenient to get the basic bone hierarchy from the Photoshop layers on the initial import into Spine, then the bone positions can be adjusted in Spine (eg with bone/attachment compensation).

I agree it would be convenient to use a layer solely to mark a bone origin, without saving it as a PNG file. While there's still plenty of configuration that can only be done in Spine (length, rotation, color, transform inheritance, etc), knowing where the bone origins are can be helpful in Photoshop for placing images. We would still use the center of the layer, but an X or other symmetrical image could be used.

It would be nice to not need a new tag, but I don't see a way to do that. We'd not want to use [bone][ignore], since ignore really should ignore the layer entirely, plus it's not discoverable. I think origin is more descriptive than mark. A layer tagged with [origin] must be under a [bone] group, it's center will be used for the bone position, and the layer will not be exported as a PNG. We'll make this addition soon and post in this thread when it's done.

You should not need to start a skeleton from scratch to update it from Photoshop, within reason. The import data dialog can import into an existing skeleton:

Hình ảnh bị xóa do không hỗ trợ HTTPS. | Vẫn hiển thị

Most commonly this is used to add new attachments to a skeleton. Image only updates can be done without import data. Replacing existing attachments can lose work done with the old attachments, like weights or keys.