Hi! Recently a matrix socket and some basic nodes were added as an experimental option. The idea is to make it easier and more efficient to pass around a combined location, rotation, and scale, and to make it much simpler to do non-affine transformations like viewport projection.
Soon for geometry nodes we would like to enable a new matrix socket. We have an initial set of nodes, but it would be good to get feedback about how these are working for people. For example:
Are there more basic nodes that would be required for these to be useful?
Are there any node groups we should think about shipping with Blender?
Why two transform nodes?Transform Direction doesn’t take the matrix location into account, while Transform Point does.
Why no “Matrix Math” node? For math nodes in general, we’re pursuing a design where different operations exist in separate nodes. The same design was used for the recent rotation nodes.
Future Plans
For node tools, a new Viewport Transformnode will give the current transform of the 3D viewport, including perspective projection
This is very cool and very useful, but I think there’s an elephant in the room that’s not being addressed. As geometry nodes get more mathematically complex and further into linear algebra with matrices, Euler sockets, and so forth, what is the plan for bridging the gap between mathematically literate coders and the average Blender user?
Said differently- the vast majority of Blender users are artists. Many are hobbyists. Quite a lot are in high school or even younger; we see dozens of high schoolers on BlenderArtists, for example. I’m spitballing here, but I would guess that 90% of Blender users don’t understand how a matrix relates to an object in 3D space.
Of course, it’s not expected that the average Blender user understands all this- there’s a clear distinction between “tool creators” and “tool users”, where the expectation is that mathematically proficient users create tools with these nodes for the average user. My observation, however, is that this isn’t really happening as planned. Tool creators create tools with geometry nodes that average users don’t understand, and adoption of geometry nodes in the average user’s workflow remains low.
Let me finally say something useful. We need more pre-packaged node assets and building blocks that go far beyond the current hair nodes. Without that, the only options for the average user are:
Try and learn linear algebra and advanced geometry and make the tools they need themselves
Try and find a tool creator that explains things in an easy-to-understand way (rare) and offers their node groups for use/sale (even rarer)
Neither of these are good options, and this problem is getting worse over time, as I mentioned- geometry nodes are getting more complex and more mathematical, and the resources for users are not keeping up with this progress.
I think that’s a reasonable expectation. Most people shouldn’t need to understand matrix math. But it’s also the reason we often call them “Transforms” in the current nodes. Since the concept of an object’s transform should be familiar, for example. I’d expect that users will feel comfortable connecting transforms between different node groups, etc.
Thanks for bringing this up. Node group assets bundled with Blender and accessible with the extensions platform are how we imagine making high level nodes more usable.
Currently we’re limited by bad asset data-block management though. In slightly more complex situations with indirect linking, we end up with a bunch of duplicated data-blocks. We have a plan to resolve that, but we need development time to implement it. The idea is to do that in Q2 this year.
After that data-block duplication issue is solved, we can use node group assets more heavily without downsides-- especially mid-level node groups which will help people who are willing to use nodes but overwhelmed by the current low-level nodes.
Playing with (Volume cube based) SDF’s. With matrix nodes, there is no need to tweak vector math nodes or vector rotation nodes. And it is much easier to stack transforms from inside fields.
I played around with this a little bit and I’m super excited that matrices are coming to Geometry Nodes!
One thing that would make the experience better would be to give the “Object Info” node and “Transform Geometry” node matrix sockets.
Right now there’s a bunch of silly extra steps for multiplying object matrices together:
Object info → Combine Transform → Multiply Matrices → Separate Transform → Transform Geometry
I would love if it could be as simple as this:
Object info → Multiply Matrices → Transform Geometry
Also, would it be possible to add a “Set Instance Transform” node? To my knowledge Transform Geometry only works with a single input, not fields, which means to only way to apply different matrices to each instance is to manually break out the Location, Rotation, and Scale from the transform, then use a Rotate Instances, Scale Instances, and Translate Instances nodes which gets pretty messy.
Being able to do this with a single node would be really nice and be more in line with the point of using matrices in the first place.
I had not time to play with these but finally we have matrix transforms!
I can only think about one more mode: Rotation transform - see python api for this functionality
This operation still can be separate node. Only issue there is that such matrix can not be converted to Location & Rotation & Scale vectors. And there is no way to display warning for incorrect result values of attempt to do that.
Working for 15 minutes with matrices and I already miss the features in the first picture. Note that the Combine Matrix in “Elements mode” could also be ordered “row-major”. I suppose both alternatives have their merit: column-major appears in graphics programming but row-major seems more intuitive to me.
Currently the Project Point node does perspective division with the absolute value of the W component. Sometimes this is not desirable, and as far as I know it is impossible to do proper perspective division.
To solve this and many other potential limitations, I suggest the Transform Point node to also output the W value of the resulting vector in a separate output socket. Access to the W component of the resulting vectors seems to me like an essential feature to have, and it would probably be very easy to implement.
Please . As a very involved user of geometry node. one of the reasons i really like Geometry nodes over other node platforms, and why I didn’t get into Unreal engine’s node, is because they keep every node separate, and it is an EXTREME pain to work with. I love that plender combines them by time. combining by operation actually make no (less) sence. If I’m using vectors, then I’ll be mainly using vector nodes and float math, and then i do then i will probably use more than one float math operation, so having to search for each operation (don’t wanna think about using the add manu ) is excruciating, it would be very hard to bear.
Aswell i often swich nodes with their connections still intact, like vector math add to subtract, of divide to multiply, or other combinations of math ops, and having to add a new one and reconnect the links will also be a big time waister (perhaps adding back and a better node switch feature might help solve this).
most the other experienced Geometry node users I know agree, with this, so I have to Idea why you guys keep pushing this idea.
I started using the matrix nodes and already even with the very few operations it has i felt the lack of a matrix math node.
I also see this with the combine node (like combine and separate color matrix etc. but i don’t think we should separate rgb, hsv, hsl, etc.), but those are a bit less annoying and make more sense to be seperate.
(A suggestion: Add a panel to the N pat with a node add menus so you could add in multiple node att the same time without loosing the menu and having to reopen the menu every time. i think bforartists has this.)
I am expressing this because i really care about this and would hate for the advantages of blender and geometry nodes be taken away, while trying to copy the flats of other programs.
I’ve been using geometry nodes for around two years, now (i think), and have been having a lot of fun.
I hope you take this into consideration, and thank you for developing such an amazing and fun tool
i really like the option to get the column or row. I actually made group nodes for separating and joining by column. could we please get this feature added?
. As a very involved user of geometry node. one of the reasons i really like Geometry nodes over other node platforms, and why I didn’t get into Unreal engine’s node, is because they keep every node separate, and it is an EXTREME pain to work with. I love that plender combines them by time. combining by operation actually make no (less) sence. If I’m using vectors, then I’ll be mainly using vector nodes and float math, and then i do then i will probably use more than one float math operation, so having to search for each operation (don’t wanna think about using the add manu 
) is excruciating, it would be very hard to bear.