So the current transform panels reconstructs the matrix? Shear is currently not exposed in the UI already, I don’t see the need to also expose those in any other transform space. The idea of reconstructing the object matrix is exactly why we need the GUI, breaking down the hidden 4x3 matrix to 3x3 vector GUI entry groups. If the current transform panels do set the matrix, then showing the internal matrix or relative matrix, or “transform, rotation, scale, shear (hidden anyway)” with the other internal matrix systems should be able to be coded. The transform panel GUI already does this, in both spaces depending on the mode and object type- meaning a simple solution is showing the user what space it’s using when it’s using it and showing vectors or extra panels with the extra vectors to help understand globale vs local/inverse parenting matrices and animate/rig properly, and then later add the ability to work the user input from the panels should be able to be coded in as well as the current transform panel, since that panel are made from vectors driving a matrix…
Again…which matrix are we working? We don’t know. How? We also don’t know. Only intuitively can we figure it out. GUI control to the matrix spaces is exactly what we’re looking for in the tranform GUI.
Eg.
- Slide Transform X in current transform panel, this is global.
- Object matrix 2m in the X transform vector group moves the object in the X axis in global.
- Parent keep transform object to null. Current transform panel remains in Global (or the panel space shows a space switch notice). Cube is globally at 2m X. Local is at 0m X, relative to parent.
- Local object rotate 90 degrees X then transform in X 3m. Now Global updates to Y 3m and X remains at 2m in the global panel. The local panel only shows X 3m and X rot 90 degrees. Same slider prop type, which is taking the global and local axis, and doing subtract math on location and trig on the the rotation axis to then “get” world matrix and parent inverse roots for local, and to get local axis from the origin, then write values to the slider (like in the transform panel), where the slider then can “add” any local transform and “Set” local position, which is a new global position really. Global position would update, because ultimately everything is in global space first.
As a user, I can see the transforms and move the values from the slider props or widgets, expected to work just like the current transform panels. It is breaking down object matrices in the GUI, trig should be able to get the other matrices without a problem.
It looks like it might be a loop based logic, which the local GUI entries addon mentioned earlier in this thread has had issues with when it comes to Armature posing - but essentially it’s not. I get that it sounds impossible with the current api, but that is because now Armatures move in pose mode are local, instead of global, then it loops when trying to confront that. The panel shows local rotation of bones, not global rotation. No warning on the space switch.
“Global” stores everything, the matrix data. The transform panel gets it and sets it. The origin of the object is the un-looped anchor to store local matrix data, it’s local origin, so trig is able to add or subtract any local transform data from the global matrix data by the object origin and parent origin. Another anchor is the parent matrix redefining the local offset. And working both gets and manages local vs global transform space without looping. You don’t have to read and write to and from local or global matrices seperately referencing one to the other creating issues with looping, but essentially work only global and run the math from the local origin and parent origins. The 3D Widget already does this with it’s Global and Local orientation to a degree and shows expected behaviour, just… it needs a GUI readout and slider props to re-produce the widget transform behaviour. The props read and write of its matrix data should be able to do the same based on that.
If the widget can transform in Local, a panel should be able to show and write the “local transform” space of the selection and be manipulated locally, like we already can - but with GUI readouts and write abilities. If it’s partly done somewhere, it must be possible.
Imagine this:
- I move a cube in global X2 and Y3.
- I switch to Local Widget mode. I rotate the object 90 degrees on X up.
- I then move the local Widget X3. But this time, I use exact numbers in the local transform panel to the right in the sub panel. I write 2.95m in the local X sllder instead of using the widget.
- Now the global updates to Y5.95 and X2, and Local is now X2.95 and Xrotation 90 degrees.
- I now need to duplicate the cube, and move it up another x1.15m. I can do that.
- Now when I move the parent, the local transforms remains fixed… and I can then align the parent to where I’m working, and I can still duplicate child, move precisely in local X from the transform panel and add in another exact measurement.
The widget in its space updates the correct space in current use, just there is no GUI readout of the changes, no origin local offset memory - and I can not have numeric additive control of the transforms relative to local. If we had this, we don’t have to now do trig in the head to understand what we’re doing, or use exclusive local space widgets or hotkey chaining in “local space” to get the values I want to model or layout precisely - even then as is, there is no relative to original local origin transform memory.
And it sounds huge, because you have to think of all object types, all modes, and all secondary modes of special objects (pose in armature). Many don’t have consolidated transform spaces, ei… the edit mode is vastly different from the armature pose mode. So… it would require cleaning up house, then adding the features. Monumental… and … well starting small could help.
-
Get Local read into GUI with all objects and modes into a sub panel. No user input, but the math to see and understand local vs global matrix is now split and readable in the interface. Data only stored in Global Matrix, exception Armature local pose space. Make individual tasks per mode/object type for the GUI. I’m not sure how you guys manage projects in the tracker, but the smaller the task or prototype, the better. So when I use widget or transform mode in “local” I can see those spaces updating correctly. Keep it minimal, same as the transform panel in layout and design, in a sub panel.
-
OR create a quick user notice in the Transform Panel to show why and how the transform space is changing, like a label with an icon explaining that the transform panel is now exclusively in “Parent Inverse” mode and not “Global Mode”. Do the same to clarify what space the other transform panels are in. Let the user know how Blender works first from the GUI. It’s a smaller task, and might point out how to consolidate the transform readouts and user control.
Addon feedback:
Your addon with the Transform Helper works alright as a readout, though not a fan of the wide layout and lack of labeling on the axis - they were cut off on default, maybe stacked vector groups like the transform panel will help. The parent inverse group readout also doesn’t seem to update when moving the object in local widget or transform space, even in local transform mode I am moving things in global. Evaluated transform looks like it’s “Global” so might need better labeling there. But I like the initial idea of it. It’s exposing the hidden matrices so it’s understood.
