Node Editor: 4x4 Matrix data type and Matrix nodes.

[probiner]

3x3 and 4x4 transformation matrices are not very friendly to start with. In LightWave's node editor I think they are even less friendly because there is no dedicated Matrix data type, so every operation involving matrices forces people to deal with the explicit matrix components which rises by a lot the price experimentation/iteration and makes the activity more prone to errors due to the amount of required connections and possible mis-connections.
One of the strengths of nodes is the ability to quickly change the tree algorithm, get instant feedback and produce better guesses to improve the algorithm. If a person has to deal with 7 connections instead of 1, that strength will be diluted or even rendered unpractical. After using XSI ICE matrix data type I can say LW matrix nodes force me to know more about matrix vector math than ICE nodes. That deterred me from experimenting, learning and tracing algorithms, faster if at all.
The easier it is to use something, the easier is to learn overlaying concepts, acquire a tool that gives desired results and not worry about the details.
The following image shows the same operation being done in the two systems and hopefully the contrast becomes clear:




Here's a mock.up of what the ports could look like in two essential places: "Item Info" node and Nodal Motion output. Please discuss which output would be better and why (Might be impractical to have both for evaluation consistency) and their interaction with IK.




Using ICE node as example, I gathered a family of operations that would be useful to have to deal with a Matrix data type. Let me know if something more would be useful and why.




Without wanting to get much into Quaternions and such (which I wouldn't mind having) here's what Fabric engine is using to pack transformations: http://docs.fabric-engine.com/Fabric.../Math/Xfo.html


I decided to make this a public Feature Request because given my background I could be catering solely to my personal needs and have some blind-spot that could impact other people. So feel free to jump in and discuss additions or changes to the idea or it's scope. After a while I'll do a proper feature request through the report system, if it seems fit.

Cheers

PS: I had done similar thread before but it got "eaten" by 2016's database loss event.

[Prince Charming]

I am all for this... just need convert nodes to go with it. There is no need to have to deal with all the components separately... unless necessary. It does lead to way more connecting than needed. Houdini does it as ice (similar), and it is cleaner.
I see you found the very very useful AS nodes Wish I had found them sooner.


I wont get into a conversation about Quaternions... but I will post this for others because they are very relevant to the things we want to do in 3d, and these helped me A LOT.
https://www.youtube.com/playlist?lis...Wj-15_e0yqQQ1U

[probiner]

Yup it's a case where abstraction is needed to make something easier to play with, regardless if you know the math or not, you just use it from a higher level.

Yeah, I've been using AS nodes for some years now, specially since the native matrix multiplication ones are broken (reported) and even for other things like Axis Angle rotation. Really nice library

Yes, I would much like to have quaternions available. But maybe a overall map revamp is needed in that section, not in nodes. Well, maybe even 4x4 matrices pushes that, I don't know the SDK

Cheers

[jwiede]

I decided to make this a public Feature Request because given my background I could be catering solely to my personal needs and have some blind-spot that could impact other people. So feel free to jump in and discuss additions or changes to the idea or it's scope. After a while I'll do a proper feature request through the report system, if it seems fit.

The request seems reasonable and broadly usable as described (plus conversion nodes, as mentioned above). I'd say go ahead and file it.

I also agree having Quaternion construction/dissection and operation nodes would be useful, but suggest filing it as a separate feature request.

[dballesg]

Hi,

A +1 to this and the other two suggestions to have quaternion nodes as well.

3x3 and 4x4 transformation matrices are not very friendly to start with.

Depends how and by whom they are explained. At the end vector and matrix operations are composed of additions and multiplications. And that is basic math that anyone can do.

In LightWave's node editor I think they are even less friendly because there is no dedicated Matrix data type, so every operation involving matrices forces people to deal with the explicit matrix components which rises by a lot the price experimentation/iteration and makes the activity more prone to errors due to the amount of required connections and possible mis-connections.

We don not have ANY data type, and we must. Have a Int, Float and Double, Vector, Quaternion, and Matrix datatypes. And conversion nodes between the complex datatypes.
Curiously we have TWO Vector datatypes, one with the name of Make Vector and hidden under the Tools category, and another under Constant > Vector or ? They have an important difference the second one has scalar X, Y, and Z inputs.

And what's about with Vector Multiply?

Multiply
The Multiply node simply multiplies one vector by another.
Vectors are assumed to contain three elements X, Y and Z. This node multiplies the vectors so that:

ResultX = AX x BX
ResultY = AY x BY
ResultZ = AZ x BZ

And the definitions of vector multiplication in Wikipedia.

One of the strengths of nodes is the ability to quickly change the tree algorithm, get instant feedback and produce better guesses to improve the algorithm. If a person has to deal with 7 connections instead of 1, that strength will be diluted or even rendered unpractical. After using XSI ICE matrix data type I can say LW matrix nodes force me to know more about matrix vector math than ICE nodes. That deterred me from experimenting, learning and tracing algorithms, faster if at all.
The easier it is to use something, the easier is to learn overlaying concepts, acquire a tool that gives desired results and not worry about the details.

Wholeheartedly agree with that.

Here's a mock.up of what the ports could look like in two essential places: "Item Info" node and Nodal Motion output. Please discuss which output would be better and why (Might be impractical to have both for evaluation consistency) and their interaction with IK.

The Item Info node needs an overhaul. For example, simply compare how easy is to read the Get.kine.local from XSI. But I will get rid of the kine part (I know is due to XSI sdk).
In LW all the Item Info nodes are called the same and added the dreaded (+1) in the name when you add more. Instead the could be renamed with the name of the Item they are querying info from.

The After IK is needed due to the way LightWave calculates the IK and how affects the results of other Motion plug-ins, specially because we don't have a motion stack

Using ICE node as example, I gathered a family of operations that would be useful to have to deal with a Matrix data type. Let me know if something more would be useful and why.



Without wanting to get much into Quaternions and such (which I wouldn't mind having) here's what Fabric engine is using to pack transformations: http://docs.fabric-engine.com/Fabric.../Math/Xfo.html

I decided to make this a public Feature Request because given my background I could be catering solely to my personal needs and have some blind-spot that could impact other people. So feel free to jump in and discuss additions or changes to the idea or it's scope. After a while I'll do a proper feature request through the report system, if it seems fit.

Cheers

As Probiner said we dont need 3 Vector outputs per Matrix, when we could have Local, Parent, World Position, Rotation and Scale outputs. Those provide I think all the info about an item transformations.
If we need one vector from one of those connect the output to a Matrix Decompose node (the 4x4 Matrix To Vector) in XSI.

Same problem exists with the Transpose Matrix node in LW, you need to pass the 3x3 Matrix as 3 Vectors and you get 3 Vectors. Looks LW is trying hard to enforce the usage of Vectors everywhere, without realizing that makes the number of connections the user needs to make much higher. I wonder if that will have some impact on the evaluation speed of nodes?

We don't have Multiply 4x4 Matrix Node, , and is needed. XSI one is nice with it's multiple inputs. Gives a visual clue in which order the matrices are multiplied.
Exactly like the Matrix to SRT and SRT To Matrix, the SRT part in the name reminds you of the order of multiplication of transformations. Quite handy.
Another type of node missing is Matrix Blending.

I think with this the list is more or less complete? Or maybe we will need to do a list between the different apps and what nodes they provide.

Cheers,
David

PS: I had done similar thread before but it got "eaten" by 2016's database loss event.

You mean the russian hacking attack to the forums? :P Sorry couldn't resist.

[probiner]

Depends how and by whom they are explained. At the end vector and matrix operations are composed of additions and multiplications. And that is basic math that anyone can do.

I guess I explained myself wrongly. I meant to look at and infer what it's doing. Like looking at:
0.5 1.0 0.0 0.0
0.5 1.5 0.0 0.0
0.0 0.1 0.6 0.0
0.1 0.2 0.0 1.0
So if you have displays showing the axes etc, it helps. In this particular case of usage we're dealing with the rows instead o dealing with the matrices as a single entity. That was my point.

Curiously we have TWO Vector datatypes, one with the name of Make Vector and hidden under the Tools category, and another under Constant > Vector or ? They have an important difference the second one has scalar X, Y, and Z inputs.

You are forgetting data flow. Here's there's not much of a difference but in ICE you have "Scalar to 3D Vector" which has 3 scalar inputs. And Vector constant which has vector input. In LW constants don't have inputs.

The Item Info node needs an overhaul. For example, simply compare how easy is to read the Get.kine.local from XSI. But I will get rid of the kine part (I know is due to XSI sdk).
In LW all the Item Info nodes are called the same and added the dreaded (+1) in the name when you add more. Instead the could be renamed with the name of the Item they are querying info from.

I wonder if that will have some impact on the evaluation speed of nodes?

I wonder as well.

We don't have Multiply 4x4 Matrix Node, , and is needed. XSI one is nice with it's multiple inputs. Gives a visual clue in which order the matrices are multiplied.
Exactly like the Matrix to SRT and SRT To Matrix, the SRT part in the name reminds you of the order of multiplication of transformations. Quite handy.

And what's about with Vector Multiply?
And the definitions of vector multiplication in Wikipedia.

Yeah it's very important to have the order of operations to be explicit. Position, Rotation, Scaling. Heading, Pitch, Bank. Go the other way around.
The Multiply node that we see there working with matrices in ICE, works the same as in LW for 3D vectors. I don't understand your beef with it, ehehe.
I would wish there were more AxBx, AyBy, AzBz operations in LightWave nodes! Otherwise at the moment you have to split the vectors into components to perform simple operations like Max, Pow, etc when your input are 2 nodes. They are basically arrays of scalar operations and that's useful.

Imagine having to split the vector just to multiply the components of 2 :/

We don not have ANY data type, and we must. Have a Int, Float and Double, Vector, Quaternion, and Matrix datatypes. And conversion nodes between the complex datatypes.

We have some don't we? ICE is more of a execution flow than a data flow, so I guess it will catter this mindset better.

Another type of node missing is Matrix Blending.

The request seems reasonable and broadly usable as described (plus conversion nodes, as mentioned above). I'd say go ahead and file it.
I also agree having Quaternion construction/dissection and operation nodes would be useful, but suggest filing it as a separate feature request.

As for Quaternions. I want them, but I'm not as insightful about them, I just use them, I haven't broke them up, like I did matrices. So if you guys want to help me with the FR points I can file it. I will mention quaternions in this report though.
I didn't had Matrix Blending exactly because it requires quaternions.

[/QUOTE]

I think with this the list is more or less complete? Or maybe we will need to do a list between the different apps and what nodes they provide.

I'm not as insightful about other apps. Open to input.

You mean the russian hacking attack to the forums? :P Sorry couldn't resist.

Don't do this to me

Cheers

[probiner]

FR filed with a link to the thread and a TLR short version. Quaternions mentioned in the context of SLERP. I think overall nodes should emanate from the SDK and the way the application works and if they don't have them in the SDK, asking for quaternions only specifically for nodes might make much sense. But this on is covered. But they were mentioned and if someone wants to file one specifically for quaternions, go ahead

Thanks for the input guys.

Cheers

[probiner]

Issues with the native nodes made explicit:

1)
An algorithm of Multiply vector by 4x4 Matrix is:

Vector (Vx, Vy, Vz)
Matrix (Right, Up, Forward) + Translation

Result is an addition of 4 vectors: Right*Vx + Up*Vy + Forward*Vz + Translation

"Transform2" will not do this, for "reasons". The input matrix components need to be transposed for it to work properly. It's "Inverse Transform" option will make the Transpose internally.

2)
"Multiply Matrix3x3" as no "Inverse Transform" option, so you're left up with the default the inverse operation.

Conclusion)
- The inver option only thing it does in the "Transform2" does not invert it but actually transposes it as shown here:




- These nodes should be corrected to NOT perform the transposed operation by default.
- Having an "Invert" option in both nodes instead of just in "Transform2" is fine, if it matches. It should be called Transposed though.
- Inverting/transposing a 3x3 alone doesn't account for Translation, i.e. a 4x4 inversion, so a stand alone Invert for RUFT and not just RUF would be better.

Otherwise just have a matrix data type and end this pain of matrix components like suggested in this thread.