theoneonion I would really like to be able to group transform constraints (inside a folder) for organization purposes.
Sure, you can do this in 4.2!
theoneonion a more specific path would be better than just a simple name. (e.g., “folder name > skin name” instead of “skin name.”)
Also in 4.2!
theoneonion when you have more than one skin using the constraint, currently it just says, “3 skins.” That is very unhelpful haha. I would save a lot of time being able to see at least the names of the skins
We can do this. I wonder how many becomes too many. 10 I suppose.
theoneonion While in setup mode using the filters at the top of the tree, selecting the SLOT filter essentially reorganizes the entire tree into (I think) the DRAW order of the images that are attached to each slot. For me, it makes a lot more logical sense to keep them in order of the bones they are connected to
I'm not sure. The tree's bone order is alphabetical. When the bones aren't shown, the slot order would seem random, except that slots under the same bone would be near each other. If you wanted that wouldn't you enable bones in the tree? 🤔 For example, show only bones and slots in the tree, then right click the root bone to expand everything.
theoneonion The biggest one (and the one I waste more time on) has to do with targeting smaller bones with my mouse. Sometimes it feels like I click 5 or 6 times to get the right thing selected.
Spine always gives an indicator of what will happen before you click, ie bones turn white so you know what you'll select when you click. I'd be interested in a real world example where you find a bone hard to select. For example, I'm able to easy select any of these eye bones, even when they are so tightly packed and I'm zoomed out:
Loading Image
There are a few things that could help:
- If your skeleton is very small or very large, changing bone scale in the settings could help. Many (subtle) things in the viewport UI are optimized for a reasonable and most common skeleton size and the bone scale setting lets you adjust that.
- You can disable selecting attachments if the problem is you hit attachments instead of the bone you want. The details about how bone selections are chosen changes slightly when attachments can't be selected in the viewport. Also when you can't select attachments in the viewport, you can still select them in the tree, which will select them in the viewport for manipulation. This keeps you from needing to toggle attachment selection on/off.
- Try deselecting first. When you have a selection, the distance to select different objects is less.
- Zero length bones are prioritized in some situations. Instead of having a very short bone, it may be better for selection to give it zero length.
- In animate mode you can select an attachment and then use the
Select - Bones hotkey to select the bone it is under. It's not bound by default. Be sure not to confuse it with the Select Bones hotkey, which enabled/disables selected bones in the viewport.
- Are you ready for your reward for reading all these bloody bullets? This last one should not be underestimated. Prepare your mind to be blown! Press
page up and page down to navigate your selection history. This will save you so much time! It's very common to have a selection you want, need to do something else, and want to go back to the selection you had. You can do that using these hotkeys! Don't recreate selections over and over, that is very tedious and a time waste!
theoneonion once I have the ik selected, I click and drag to move it, but because I am zoomed in, I often click and move something else instead.
One way around this is to start your drag over the selected bone. This is a little tricky, as you don't get the white hover color for already selected items, but it can still be a useful tip.
theoneonion it would be spectacular to see what action I am undoing with my “Ctrl+Z.”
You can see it at least in that what you changed goes back to before you changed it. What would you like to see? A textual description of what was undone? I'm afraid this would be pretty difficult. 🤕
You are not alone in using undo a lot. When I'm in the situation you described, I typically undo until I press ctrl+Z and I don't see what I was working on change. At that point I know I've gone one too far, so I redo ctrl+shift+Z and now I know I'm in the right state. I do this exact same workflow when editing code, too. I undo until the cursor jumps to some other location I was working on earlier, then I redo once.
Spine's undo system is one of our proudest achievements. Developing such a system is not talked about much and users tend to under appreciate the difficulties, but undo is notoriously hard to implement well because it's very invasive at the source code level -- every action the user can do has to be able to support both undo and redo. Every single action, so you can imagine this quickly becomes many thousands of places in the source code for even a moderate sized app. There are many ways to do this poorly and in most apps it becomes a significant hurdle for adding new features and a huge source for bugs. Our solution is super slick, it is rock solid and doesn't get in the way of new development at all, but unfortunately it would be difficult to name each undo state for technical reasons.
Thanks for sharing your ideas! Feel free to bring up new ideas any time. Don't be discouraged if we can't get to all of them or we have a disagreement on how things should. I'm happy to continue discussing them and, while we have our own opinions on many things, we always remain open to seeing things from a new perspective or otherwise being convinced. 🙂
