JSpin

Spine Feature Request - Copy Keys (selected or not) and Hierarchies between skeletons

I've made a video with sound where I show and explain what I as a new user with experience from other 3D packages and software were expecting but is not possible to do and the work around that for a simple quick task that becomes cumbersome and time consuming. I dearly wish for this to be implemented as soon as possible as it's very frustrating to not being able to just copy a couple of keys between bones and slots in another skeleton when it works just fine within the same. It's very counter intuitive to how you expect it to behave and I've had at least two colleagues remark on this short coming as well.

JSpin
  • Postovi: 23

foriero

Yes please. Our main animator has the same request.
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar
foriero
  • Postovi: 471

Nate

I appreciate that you as a user expect it to just work, and that is of course our goal, so the software is easy to use. However, it can sometimes be quite tricky to address all the details even for seemingly simple operations. For example, you want to preserve the keys when you drag across skeletons -- a reasonable request. However, things can be keyed in many animations, so what happens? Do we bring the keys over only from the current animation, adding them to the current animation in the target skeleton? Or do we create all animations in the target skeleton (unless an animation with the same name already exists) to match all the animations that have keys for the items being transferred? What if you want to drag across skeletons but don't want the keys at all? Are there other actions you might want? We need to figure out all the actions that should be allowed, then we probably need to show a dialog to ask which you want.

I know you likely don't particularly care about the technical difficulties, but there is a lot of complexity when moving across skeletons and that is the reason why not all the expected functionality is there yet. Each action across skeletons is a fair amount of work and is especially error prone because references to things in the old skeleton can easily go unnoticed until much later, leaving a corrupt/broken project.

Note in your video when you copy a bone, you get a "toast" (message in the bottom center of the viewport) about what was copied or pasted, for example: Bone transforms copied. That lets you know you've copied the bone transform, not the bone itself or something else. Hitting ctrl+C may not always do what you expect, as it depends on the context of what you were doing last. Specifically, there are selections in various views (the viewport, tree, dopesheet, etc) so what is copied? When you interact with a view it gains focus, indicated by the view name being underlined. The toast messages can be helpful to clarify what is happening what you copy, for example when copying keys (in the dopesheet) versus bone transforms (in the viewport or tree). As we add more functionality we may need menus to allow choosing what is copied, eg a bone transform versus the bone itself. This is sometimes called "copy special".

After copying, in some cases you can select a different object then paste to have what you copied applied to the other object. For example, you can transfer bone transforms this way, or keys (currently only within the same skeleton). If you paste and there is no selection or the selection isn't valid for transferring what you copied, then it will apply what you copied to the object you copied it from. If you haven't changed what you copied, it appears to do nothing, though it is actually applying what you copied and a toast tells you what was pasted. This is what was happening in your video when you copy/pasted keys -- since currently you can't paste keys across skeletons, it was pasting the keys on top of the existing keys, effectively not making a change. Note when you copy/pasted bone transforms, it is allowed across skeletons and was applying the changes, but the bones were already in the same place so no change could be seen.

As you found, using Import project, Animation is a workaround for not being able to copy/paste keys, though it is a bit clumsy. Note that the imported animation was renamed to anim2 because an animation already existed with the name anim. If there wasn't an anim animation you wouldn't have needed a rename step. We will add an option to overwrite existing animations (and maybe merge?).

Anyway, getting back to your requests, I absolutely agree that we should improve the use cases you've shown in your video. I've create an issue to track the work:
https://github.com/EsotericSoftware/spine-editor/issues/582

As for an ETA, we aren't able to fit this into 4.0 as we are currently focusing on stability so we can get the non-beta release out. Version 4.1 will be a quality of life release, so this would fit well there. If you have other requests to streamline your workflow, please let us know and we'll do our best to make things work more smoothly.
Avatar
Nate

Nate
  • Postovi: 11795

JSpin

Excellent reply,

I understand the short comings and complexities but at least when copying keys, they should transfer the same way they do within a skeleton to another.
- If there are differences in the bone structure when copying keys that resides on more than one bone/slot/attach I would probably past the keys that fits and give a small warning that not all were transferred due to hierarchical mismatch or naming.
- I also support the option of getting a dialogue, perhaps one that that gives you "past to matching simple hierarchy (as best as possible regardless of names)", this would work on a singe bone with a singe slot with a single attachment (or the top one) or a hierarchy of singe bones like a tail or spine. Then one for "only past to matching names" or something like that.
- In worst case I can at least copy keys from just one bone/slot/attach and past it onto another regardless of name, more tedious but still manageable and is close to what I was expecting for starters.

Also where should the keys go for the animations? I think it should go to the currently active animation on the target skeleton, that makes intuitive sense.


=========
As for bringing over a hierarchy to another skeleton, here is how I see it working:

When dragging and drooping a hierarchy, you should get an options dialog asking some thing like this:
1. "Do you want to just bring over the selected keys for the current active animation of the source to the current active animation on the target"
2. "Do you want to bring over all animations that transferred hierarchy is part of to the target." then "If so, do you want to paste keys into animations with matching names or create new animations."

[] = source and taget animation
copy..

Skeleton Source:
BoneArm1
BoneHand2
Slot
Attach
Animation: [Wave], Punch, Walk

to..

Skeleton Target:
BoneArm1
BoneHand2
Slot
Attach
Animation: Wave, Jump

where option 1 will result in...

Skeleton Target:
BoneArm1
BoneHand2
Slot
Attach
Animation: [Wave], Jump
or
Animation: Wave, [Jump]

and option 2 will result in...

Skeleton Target:
BoneArm1
BoneHand2
Slot
Attach
Animation: Wave, Punch, Jump
or
Animation: Wave, Wave2, Punch, Jump
============

Other Feature Request I have are:
- Ability to skip over the Spine File dialog menu directly to OS dialog option as I never use the Spine dialogue and just find it an extra step, especially for "saving as" as I rarely or ever want to over write an existing file but just want to get to the OS dialogue to input a new name. Maybe have it as an options check box in the settings. As for folder shortcuts in the spine dialogue, I actually use my own system of favorites folders with Widows 10 Quick Access instead as I use it in all apps and dialogues as well as file explorer.

- Relative file paths for export. This is quite a critical thing to have as we all are working from home right now with different folder structures but when a colleague want to export it does so to the wrong location on their system as it's not relative to our project structure but rather the absolute path of where they actually put the whole game project on their disk. This is a real pain in the butt right now.

- Be able to grab and scroll in panels (eg hierarchy) with my Wacom pen, in Blender you can navigate the list panels this way and it's very convenient with the pen or else I need to constantly grab my mouse for the wheel or go to the scroll bar on the right which becomes tedious after a while. Ideally this should behave like the view port where you just use RMB to pan, but I know it's currently mapped to expand/collapse hierarchies. I would love to se a option to switch this behaviors so panning can be done with just RMB and the expand/collapse can be done by alt+RMB and or vice verse. Also Photoshop expands/collapses folder hierarchies with alt+LMB

- Being able to zoom in the Dopesheet time with my Wacom pen. This works well in 3D apps as well as you can often zoom and pan with the pen the same way you do in the view port, often by utilizing the MMB or a combination of alt+button or similar. In Spine's case it should preferably work like the view port, ctrl+RMB. Then I could zoom with both a pen and a mouse without relying on a using a scroll wheel.

- When dropping a png sequence onto a slot, I would love for it to aske me if I want to populate the time line with it starting from my current time line indicator, now you have to manually frame step with R and toggle visibility of each attach.

- Last but not least, I dearly need a new sequence attachment type so that I can easily mesh warp a png sequence, I don't want to have a long list of individual meshes as it becomes a nightmare if you want to tweak the mesh. Right now you just have to start over and re-rig everything.

Thank you again for listening.

---

Nate je napisao/la:...
Hi Nate, did you see my replay above?
JSpin
  • Postovi: 23

foriero

Very valid points here.
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar
foriero
  • Postovi: 471

cyb3r

Indeed, lots of good stuff JSpin pointed here. I would add Isolate Selection mode to the list :)
Regards.
cyb3r
  • Postovi: 34

mogbot

Would REALLLY love this feature ASAP please! if it could make it in to 4.1, that would be a game changer for our team.
Avatar
mogbot
  • Postovi: 20

Erika

mogbot je napisao/la:Would REALLLY love this feature ASAP please! if it could make it in to 4.1, that would be a game changer for our team.
While we wait for it, if you explain what exactly you need to be able to do, there's probably workarounds that could help you in the meanwhile!

For example:

- Did you know you can copy bone transforms across skeletons? this means you can copy rotation, translation, scale, shear from one or more bones to another set of bones. Or from one or more vertices to another set of vertices:
Tools - Spine User Guide: Copy/paste

- As long as the bones are named the same, you can brutally import entire animations from a skeleton to another. This can create a fantastic jumpstart by having a generic walking animation and adding flavor to it for example with minimal adjustments (using the adjust tool for example)
Spine Tips: import animation
Animations can be imported as long as bone names match. This can be used for a team to work concurrently on the same skeleton or to salvage parts of animations from other skeletons.

Dopesheet view - Spine User Guide: Key Adjust

Of course being able to directly copy and paste the keys would be the most convenient, but I hope these can still help!
Avatar
Erika

Erikari
  • Postovi: 3049


Natrag na Editor