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.
