Reevaluating Worldspace and Localspace Treatment (need some dev triage)

Wow, still unsolved?

1 Like

Trying to rig a wheel that requires agnostic rotation values, but one forward one - with a bone moving in Y or X locally along a path, as an examples - is impossible, as drivers or constraints only detect it’s local position relative to parent and/or global. And local position doesn’t read local rotation direction.

The need to have local and global values exposed and useful in the UI and general architecture is very necessary for good easy rigging, animation and troubleshooting. Right now the transforms feedback is not clear which space we are in and what the transforms values are. Getting these spaces, that do exist in the API, exposed to the user in the drivers, animation editors and transform editors should be imperative.

1 Like

Hi everyone,

Sorry to necroposting but… I have to bump this since to me It’s one of the most basic aspect of blender that need to be fixed…

I remember @sybren answering on another topic (that I’m not able to find right now), mentioning the documentation explaining blender parenting and coordinates and that it’s intended. But still…as many have already mentioned, the current way of displaying coordinates after parenting are just pointless. This is an old topic, and I found a 2011 post on blender artists pointing out the issue… and I’m really surprised that It’s still not fixed!

Just to recap and double check if I understand correctly:

When you parent an object to another, the child objects coordinates displayed are the ones in the moment of parenting. After moving, rotating and scaling the parent, without touching the child, you still see the original world space transformations values the child had at the moment of parenting. Those values are meaningless and have zero usefulness to me:

6 Likes

Hey folks.

TL;DR: no, this is not a bug, it is intentional behaviour. As such, it cannot be “fixed”, because it is not considered “broken”.

The manual section on Parenting Objects explains how this works. In short, there is a matrix called the Parent Inverse matrix. It is this matrix that sits between the parent & child transforms, and it is what makes it possible to (un)parent a child without moving it. By using this matrix it’s possible to even parent an already-animated object, without having to update the animation data.

I agree that Parent Inverse is not the most descriptive name. The fact that this matrix is hidden in the user interface (apart from a few cryptic mentions in some menus) doesn’t help either. The functionality that it offers isn’t going away any time soon, though.

I hope this helps to shed some light on the situation,
Sybren

1 Like

Hi @sybren, thanks for answering. I’m aware that is not a bug, and it’s intended.

My Request (And I believe not only mine, I’ll list all places I could find where users seem to agree with my opinion) is that the intended behavior should be different because the current behavior (at least from my experience) doesn’t seem to be the best it can be, the values displayed are certainly correct, but not useful.

I’m not asking to change the internal behavior but just change how coordinates are presented (and manipulated). I’m not a developer of course and I’m not assuming that It’s simple.
Anyway Literally every other 3d software displays children’s coordinates relative to the parent in the same way (At least as far as I know)And they still give users the possibility to un-parent a child without moving it. .
Only Blender seem to have this way of showing the coordinates that seem to have no advantages.

I’m a professional blender user since 2014, and I’m aware that most of peculiar blender’s ways of doing things are for a reason, Like RMB select ecc, and I actually like them! But in this case, I can’t really see a reason for the coordinates to be displayed like that.

What’s the feedback of blender studio staff about this? @JulienKaspar or @Hjalti (the first two that came to my mind)

I know that I should not show other software but If necessary to better show what I mean, let me know and I’ll better explain the expected behavior with an example in H***** , But I can tell for sure that M***a works the same, and in both DCCs If you un-parent an object it stays in place (or you have the option to disable this feature)

Here are some topics where a lot of other users talk about this issue (Two of them are basically duplicate requests on RCS and one on BA is from 2011!):

Thank you very much for your attention!

2 Likes

I think that to get some traction on this issue, that it needs to be brought up and discussed at one the animation and rigging meetings. Not sure if you want to do that yourself or to get someone like @Orestiskon or Jason Schleifer who were at the last meeting and who have used packages other than Blender.

I think that the main devs (who have possibly only ever used Blender for 3d) don’t really understand where we are coming from on this issue, and it needs to be hashed out in a discussion.

I have the same impression… I don’t know who the guys you mentioned are, but if they can help in convincing Devs that this is a basic , yet very important quirk to fix, they are welcome to join the discussion!

I’m with everyone here regarding this issue but I understand that the current way of Blender displaying coordinates and dealing with hierarchies is a bit different and lacking compared to other 3D apps, so I propose a middle ground that would be to at least to address this issue at the UI level:

  1. Expose the inverse transform matrix in the interface (and allow users to change if needed);
  2. Display the world/global transformation (important to actually see what is the actual world transform of a child object in an hierarchy;
  3. Rename the current transform to Local transform in the UI (this is basically what it is now, just not explicit).

I believe that by doing this, nothing would change fundamentally in how internally Blender works, while, making things more clear to the user specially those accustomed to work on other 3D packages.

Just my two cents

3 Likes

This is not the issue, at least when I talk about myself (I can’t speak for other devs). I fully understand that how things are now is confusing, and that there are both simple-but-already-nice and more-complex-but-even-nicer solutions out there.

What we do need is:

  1. A proposal on what to fix, and how to fix it. This should includes some alternatives to choose from, or a list of alternatives considered & discarded (and for what reason). Basically what’s described in Ingredients of a Patch; these are nice to have even when there is no single line of code yet.
  2. Discussion of the proposal. The forthnightly module meetings are the perfect place for this, and I certainly invite people to come and join. If you want to discuss something at the meeting, either pop over to #animation-module on Blender Chat, or wait until the meeting agenda is published in the Animation & Rigging section here on DevTalk and add a comment in which you propose to discuss this topic. That way the people attending the meeting will be aware of the topic before the meeting starts, streamlining the process.
  3. And last but not least, a developer who can implement the changes and stick around to maintain the code after it’s been accepted in Blender.

@NunoConceicao I think you have some nice ideas. Do you have some Python programming skills? If not, may I (tongue-in-cheek) recommend Scripting for Artists? :stuck_out_tongue:

Joking aside, maybe my Transform Helper add-on could be used as a basis for the proposal. It’s always easier to talk about features when they can be demo’d, as then everybody is looking at the same thing.

2 Likes

Thank you Sybren, I do have some Python skills and I already did your course of Scripting for Artists to help me get into how python works in Blender. Regarding the course, in the last Blender conference back in 2019 I spoke to you in person to praise your course and ask you for more, but probably you dont remember that conversation, I’m sure you spoke with a lot of people, but I surely didn’t forget :wink:

1 Like

Thanks, I appreciate your reply. Would be great if you could bring this up with @Orestiskon at your next meeting, as I have heard him mention it, and I think he usually attends the meetings. I don’t have enough of a technical background to put together a proposal for this, but there are plenty of people on this thread that would be capable of it.

Some of the other seasoned rigging td’s such as Jason Schleifer who attend the meetings would no doubt have an opinion on this topic and could be consulted.

2 Likes

Hi Sybren
Following up what you mentioned about proposals, here is an addon that Ondrej Brinkel made after my RCS proposal.
So far this is as close to what was suggested and I think this also serves as a good proposal base imo.
It still has some limitations that I’m not sure that can be addressed by just creating an addon, in my limited python skills view.
I invite anyone in this thread to install and have a look at it.

1 Like

I am currently about to publish an addon for that, one of its main usages is to solve the whole handling of worldspace and localspace discussed here. I put quite some time into it to offer a complete and intuitive treatment with visual feedback for blenders transform spaces. Currently testing that everything works fine with 3.0.

2 Likes

Cool, looking forward to try it!
If you need testers ill gladly help with that

1 Like

image

Oh my, this is so handy even as is!

I miss being able to either animate in Local of World with Local or World keyframes sets, but this helps at least to position numerically in this case.

Agree, it is a good starting point and base to develop upon, I guess, once it gets rotation, scale and the possibility to animate in local space would be great. Although as far as I understood, Blender animation works in local space, the difference is that once it gets parented the object doest shift because there is that hidden inverse transform of the parent that prevents it.
I understand this is how Blender works, but I dont see any reason to not improve this a bit further, specially at the interface level, to make this clearer (what are local coordinates and what are the world coordinates) and also expose that hidden transform matrix

3 Likes

So nobody is looking at & giving feedback on the add-ons that I already made? Here are some screenshots:

Transform Helper:
Transform Helper panel

Copy Real Pose (I didn’t link this before, but I think it’s a nice one to have anyway):
Copy Real Pose panel

The documentation just says:

This addon for Blender 2.80 and up adds local and world location editing for objects.

It doesn’t tell me anything details about what it does, how it manages to do that, and most importantly, it doesn’t tell me which of the things it does are so important for the people here. There is a link to its wiki, but that just leads to a “404 file not found” error.

I circle back to the points I made in an earlier comment: this needs a clear proposal. Just pointing at something and saying “do something like that” isn’t going to help.

This was discussed in yesterday’s Animation & Rigging meeting. The conclusions can be found in the meeting notes.

2 Likes

Hi @sybren

First of all, thanks for giving attention to this thread and bringing the discussion in the meeting,
I was personally extremely busy and couldn’t follow the discussion as much as I wished.

I’m not familiar with the matrix math behind the parenting system, so the best I can do is try to explain the desired outcome in a sort of proposal as soon as I can. But on the point of the proposal of “how to fix it”, Unfortunately, as I said, I’m not familiar enough with the math to include that in a proposal.

I’ll be back as soon as I can and try to be as clear as I can!

Again, thanks a lot! It’s great that this is in the discussion in the meeting!!

Gave it a quick whirl, the GUI could use some love, for consistent sliders and display from the other transform panels, also integrations to the typical transform panels.