Even tho 'offset parent matrix' was an attempt at supplying a way to drive transforms with a matrix the implementation was poorly thought trough. What was done is essentially implement a pre-transform which complicates the actual transform as:
- the local matrix does not take this into account when outputting.
- introduces another layer of dubiousness as to the real 'position' of an object like with the pivot.
- does not update the TRS attrs.
- does not export correctly to other packages.
What we seek is a true input matrix which drives the TRS values as done with a decompose matrix node.
How should this be implemented?
- The input matrix should come with a enum drop down that selects the input type matrix to be a world or local (any other?) input. This so you don't need to compute the inverse parent matrix to get local values. World inputs allows you to plug matrices from all over the dags straight to each other. ie. controller from the controller stack to joints in a clean hierarchy.
- the input matrix is computed before the TRS and sets its values internally before getting overwritten by any TRS inputs so they can co exist if needed.
- setting TRS when the matrix is connected should be possible but revert back to the matrix input when evaluated (like with constraints), keying them should also be possible overwriting the matrix input for those attrs.
- The TRS should become blue like with constraints indicating overwriting
- optionally implement a 'matrix pick' on the transform itself to just drive pos rot or scale leaving room to connect or set TRS seperatly coloring accordingly.
- optionally make the matrix input a multi attr that multiplies inputs like the multMatrix node eliminating more nodes and connections.
I've took some time to make a video about this, please consider my suggestion.
https://youtu.be/mnaJ-PlIL6I
https://youtu.be/Pti0PnNu42w
yours truly
-Tristan
