I've been working with a much more complex set of skeletons recently, and I have a few suggestions for how the UI might be improved in the Tree and Animation views:

Animations Folders -
In our game, we are trending toward over 100 animation states for some skeletons. It would be really nice if the animation panel had folders, purely for organizational purposes. This way I could put all of the attack animations into a single collapsible folder, separate from all of the movement (walk, run, jump) animations. These would not need to export, they would only be for organization while working.

Tree Organization -
User Can Change order of Heirarchy -
My first suggestion was originally to put constraints directly underneath the bones in the Hierarchy, since they relate so strongly to bones... it makes less sense to put them at the end of the list, below draw order and images, etc.

But even better - if I could simply change the order that items appear in the hierarchy (along with hiding/showing), this would also improve this issue.

Hide & Show Elements in Heirarchy -
I would like to be able to turn off or collapse all of one type of item in the entire hierarchy (so turn bones or images on/off), like how you can turn these items on/off in the viewport (hiding/showing bones, etc). As a use case, I typically do not use skins or events, so I'd like to be able to hide these elements completely. Or if I'm working only on the skeleton for a bit, I could hide all of the images folders, just to get them out of the way, and then turn them back - ideally re-expanding them back to how I had them expanded before I hid them. Just to be clear, I only want to hide these things in the Tree panel - NOT in the viewport editing area.

Scrolling Shortcuts -
I also think that the Tree view's scrolling length could be improved through another feature. I have to scroll a LOT in some files (or collapse and expand a lot) to go back and forth between 1) different skeletons, 2) bones and their constraints, images, draw order, etc... but mainly between bones and constraints.

To solve all of these issues, it would be nice if there were almost a window inside of the tree window, at top and bottom. These inner windows could be collapsed and expanded if you do/don't want to see them. The top view would be a list of all skeletons, with the ability to 1) jump to a skeleton in the Tree list, and 2) turn on/off an entire skeleton.

The bottom mini-window would be a shortcut list to view the bones, draw order, images, skins, etc. within the skeleton. This way I could also jump to the images without having to collapse the bone list, or scroll through a set of lists to get to the constraints, for instance. This would also be an ideal place to turn on/off a certain element (turn off all skins).

Nate wrote

ryancbaker wrote

What I would want is for the Constraints group (the little dropdown w/ all constraints) to be below the Bones group, not at the bottom of the list below Draw order, Images, Skins, etc. Or allow the user to define the order on a universal level

Ahhh, gotcha. Changing the order is going to confuse all the people who are used to it! What does everyone think of this order:

Image removed due to the lack of support for HTTPS. | Show Anyway

Well I wouldn't want you to confuse everyone for my sake. But I would suggest:

• Bones
• Constraints (relate to bones)
• Draw Order (they are the "next descendent" of bones, so I'd put them next)
• Skins (make sense between Draw Order and Images, though I could see this after images)
• Images (I only open this up when I need to add an image to a slot... so this gets used <1% of the time I'm in the app)
• Animations (very little use in Setup)
• Events (completely unrelated to Setup)

Reasons:

• easier dragging from the folder/image list to the skeleton hierarchy regardless of skeleton complexity.
• the images view can eventually have a different UI. Big thumbnails? custom ordering? search box?
• images node is useless in Animate mode.
• not an actual node in the skeleton object model

Agreed on all fronts. I would encourage you to extend this reasoning to any/all other types of nodes, especially the last 2 points. In the tree, I would prefer that any node which is not used in a respective mode (Setup or Animate) is not visible at all. So no Events in Setup, no Images in Animate, and so on. And since Animations now have their own panel (view) in Animate, why not remove their node under the skeleton?

I would also very much like a separate window for images, AND for constraints. I realize there is less of a case for constraints... It is just my current pet peeve. But I will say that if you are adjusting constraints, there is far more scrolling that you will have to do, compared to adding images - especially when bones have more than one constraint.

Whether or not you make Constraints a separate window, I would like some kind of highlighting system in bones and constraints. I know you can use the little constraint icons next to bones to jump to their constraint, but that doesn't help much when I'm trying to re-prioritize the constraints. So my suggestion would be that when a bone is selected, any of its constraints are automatically highlighted. And the reverse could be true — if you select a constraint, the bones that it refers to are highlighted. This would make a bit more sense if they were separate windows, but I think it could be helpful regardless.

To give a little background, I currently have 45 constraints in the file I'm working on, but expect to have over 100 by the time I'm done.

I am also feeling like I need a way to view which constraints are breaking each other, and producing unexpected results (or rendering other constraints useless). Currently I have to do some trial and error to get my constraints into the right order so that they don't cause conflicts... and I suspect that I may have created some circular logic that means one set of constraints will simply never work, regardless of what order I put them in. I haven't fully tested this theory yet, and don't have any good suggestions yet — the only thing I could think of would be a little icon like and exclamation mark (!) next to any constraints that may conflict with the current constraint. I'm still trying to determine best practices for layering constraints, so my thoughts are probably premature, but I thought it was worth mentioning.

One final thought — I wish that when a transform constraint was added, it defaulted to 0% transform on all properties, with "=MATCH" automatically applied. I understand that this might confuse some people, but I believe the the typical use case for a transform constraint will not be to immediately snap to the target bone... but rather to apply only a partial transform, or a transform adjustment over time (tossing a weapon from one hand to the other). So in Setup mode, when you create a constraint, you typically won't want the object to snap to its target's position, etc. — rather, you will have it move toward the target bone in Animate mode when needed.

All of this to say, it would save a lot of time if the constraint defaulted the bone in question to its original (=MATCH) position, with 0% transform on all properties, and "link sliders" unchecked, and let the user adjust from there.

Nate wrote

ryancbaker wrote

I would like to be able to lock editing on individual bones, attachments, etc.

On second thought, isn't it enough to just hide the bone in the tree? I don't think there is ever a time where you want to see a bone, but not be able to select it. In 3.5.34, the Background checkbox for region and mesh attachments has become separate Select and Export checkboxes.

There is one specific time when I do want to see a bone, but not select it - when that bone is being controlled by a transform constraint. I have constraints way off to the side that are basically my "levers and pullies" to move various parts of the skeleton indirectly. I want to see what these bones are doing, because they may have a rotation applied by an offscreen transform-constraint-parent. If this bone is 100% controlled by the constraint, then you can select it, but not edit it (or at least not edit the properties that are controlled by the constraint) already, which is fine - but these bones are then cumbersome when they cover other bones that I'm trying to edit. So I'm constantly clicking a transform-constrained bone which I can't edit anyway, don't even want to select, but do want to see

I have so many overlapping bones... and I really need to see them, but don't want to ever edit half of them directly.

My ideal situation would be to have the ability to lock bones, which dims them to 50% opacity, or turns them into a dotted line or something. So I can see them, but know that they are only there for viewing, not editing.

Nate wrote

One consideration is that the properties are shown in the bottom of the tree. With separate views, I'd guess you'd want them to show the properties in the bottom of each view? This could increase the minimum usable width and height for each view by quite a bit.

I use dual (sometimes triple) monitors, so I just spread everything out as wide as I can. I know not everyone uses this setup, but I think that even if the panels are hidden behind each other (so they appear as tabs that you can toggle between), this is still faster than scrolling up and down the tree. I do have auto-scroll turned on, but sometimes you want it on and sometimes you don't.

Yes, I'm fine with the properties being at the bottom of the panel in question - so the Constraints props would appear when you have a bone with constraints selected, or perhaps only when you have a constraint selected. I would also be fine with having the props hidden when nothing is selected, as it currently is in the tree.

ryancbaker wrote

I would like some kind of highlighting system in bones and constraints

FWIW, when you hover over a constraint in the tree, arrows are drawn for the constrained bones. For a bone, the only way to see its constraints is to hover over the annotation buttons at the right edge of the tree, which have tooltips in the latest.

Yes, showing the red arrows connecting the bones to their constraint are very handy. I'm not sure what you mean about the tooltips - I've updated, have beta versions turned on, and tooltips turned on, but I'm not seeing them... maybe I am just misunderstanding, unless you have not pushed that update yet.

Could you also show the red arrows when you hover over a constraint icon in the tree (the ones to the right of bones)? I still think that highlights within the tree could be as much if not more helpful than the arrows in the editing window though.

It would also be great if you currently had a constraint selected, if that constraint's relationship was drawn with a cyan blue arrow, while hovering over any other constraints drew the red arrows as they do now. Sometimes I'm examining a constraint, have it selected, but accidentally mouse over another constraint... or I want to scroll up to the bones to fiddle with something else. While doing this, I lose the red line for the currently selected constraint... hence my suggestion of a more "semi-permanent" blue line for the current selection.

I realize this is probably wishing for too much, but two more items would eventually be handy:

• I would like to be able to change the bone or target of a constraint once it's been created. I've accidentally selected the wrong target before, so I have to delete the constraint and recreate it. I don't really mind how this is done, maybe right click on the target in the Constraint properties, and it then forces you to select a new target bone?
• I would like to be able to duplicate a constraint to another bone - same target, same constraint settings, but applied to a different bone. I notice you have the duplicate button there already next to rename, so maybe this feature is planned?

ryancbaker wrote

I am also feeling like I need a way to view which constraints are breaking each other, and producing unexpected results (or rendering other constraints useless).

This is interesting, issue added:
https://waffle.io/EsotericSoftware/spine/cards/583cdbff25714e1e00d4dab5

You guys are awesome. Any improvement here will be amazing.

ryancbaker wrote

I wish that when a transform constraint was added, it defaulted to 0% transform on all properties, with "=MATCH" automatically applied

I'm with you on the 0%, but I'm not sure about automatically applying match because it's a bit of a pain to zero the offsets.

That works. Thanks!