- 수정됨
[3.8.99-pro] Renaming IKconstraint doesn't update name-label
[solved, unfortunately don't seems to be able to change the title here to [solved]... see below.]
When renaming an IK-constraint in the Tree view by doubleclicking and entering a new name the name updates in the Tree panel, but not in the editor view label near the target of the IK constraint where name is on.
Clicking the name-checkbox of the constraint off and on doesn't refresh the label.
Also saving the file and reloading the file again the name in the label is still the old one and thus not updated.
See video in attachment.
video:
rename-ik-constraint-issue.zip
[edit]
Ah, my bad. I see now the label in the editor isn't showing the name of the IK CONSTRAINT, but the name of the IK Constraint TARGET.
And I see now that creating the constraints also added new seperate instances to the Tree for these targets, next to the constraints themselves. I wasn't aware of that.
If I rename the targets in the tree the label gets updated and it works as expected. So obviously when renaming the IK constraints (instead of the targets) both the related targets in the tree and their representation with a label in the editor don't get updated with it. And visa versa. So they're really two different things.
So it's clear this is not a bug, but intentional. I found it a bit confusing though, because I didn't know about these targets as seperate instances and also can't find a reason why we would like to set the target and the constraint to different names. But now that I know it it is all clear.
I'll leave this thread here just in case somebody else in the future has the same confusion.
Glad you figured it out! It's good you have an eye to notice such things.
As you found, some items in the tree have no representation in the viewport. Spine tries to be smart and select the most relevant thing in the viewport. For an IK constraint it selects the target bone for you.
Nate wroteSpine tries to be smart and select the most relevant thing in the viewport. For an IK constraint it selects the target bone for you.
I like that feature. But sometimes items are too close to each other to be able to select one or the other. What also happens a lot here is that we've selected a bone, and when using the rotate transform tool in the editor suddenly another bone gets selected instead of the transform tool moving.
So then I use the Tree to select a bone, for example, but when using the rotate tool and click one pixel next to it it still selects a close lying other bone, like an IK bone. I've had 'troubles' with that some times now, especially with IK target bones as they can be everywhere.
I understand to work around this we can zoom in, and I do that. But sometimes IK target-bones are really really close to another bone so
1) it takes a lot of zooming until it's easy to select (and keep selecting) the right bone
2) Spine is than so much zoomed in that we're missing the overview. We can zoom out, but than the same 'selection troubles' are there again
I've been looking, but so far couldn't find it. Maybe I'm overlooking something; Is there a way in the software to (temporary) turn off this auto select method in the editor, so we can select bones by clicking on Tree items and use the transform tools without accidentally selecting some other bone that's really close? So in that mode we cannot select items in the editor, only in the tree, so we can fully use the transform tools in the editor without accidentally selecting another (IK-)bone.
Thanks again! And for now, have a nice weekend!
Friebel wroteWhat also happens a lot here is that we've selected a bone, and when using the rotate transform tool in the editor suddenly another bone gets selected instead of the transform tool moving.
This would only happen if you drag to rotate while over another bone or attachment. Once you have a bone selected, you don't have to drag on that bone, you can drag anywhere. It shouldn't be hard to find some blank spot where you can drag with nothing under the mouse, then you can make adjustments without the chance of anything else being selected.
Friebel wroteSo then I use the Tree to select a bone, for example, but when using the rotate tool and click one pixel next to it it still selects a close lying other bone, like an IK bone.
Using the tree to select a bone can be convenient. I don't understand why you'd have problems with the rotate tool though? I have a feeling you missed that you can drag in any blank space, you don't need to be anywhere near the selected bone.
In some cases when you are zoomed in a lot, there may not be any blank space because attachments are taking up the whole screen. In that case if you put the mouse directly over the origin of the selected bone, you can drag there without selecting another bone, even when bones are on top of each other. You'll know if you are over some other bone or attachment because the other bone will be highlighted in white and from the name shown at the bottom center of the viewport.
Friebel wroteIs there a way in the software to (temporary) turn off this auto select method in the editor, so we can select bones by clicking on Tree items and use the transform tools without accidentally selecting some other bone that's really close?
Sure, you can disable bone (and/or attachment) selection in the main toolbar, at the far right. That prevents you from selecting those things at all in the viewport, but you can still use the tree to make selections. It's common to work that way, depending what you are doing.
A few tips:
When using the tree to make selections, filtering the tree can be very helpful, eg to show only bones. enter
focuses the tree search box, then you can type to find a tree node. enter
again goes to the next match, shift+enter
to the previous, ctrl+enter
selects all matches, escape
clears the search.
You can use ctrl+x
and x
, where x is the numbers 0-9, to store and load selections.
Also here's an often overlooked tip: you can navigate through your previous selections using page down
and page up
. It's very common to need to go back and forth between selections and these selection history keys are super convenient, allowing you to avoid making the same selections repeatedly and without using your selection hotkeys.
Nate wrote...
Wow! Thanks for the extensive answer. Great tips. I definitely go check this out!