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.