Matrix Sockets #116067

New Issue

Hans Goudey · 2023-12-12T00:09:39+01:00

Hans Goudey commented

2023-12-12 00:09:39 +01:00

Use Cases

Viewport transform node for node tools
Simpler access to all object transforms
Simpler combination of transforms
Simpler transform from different spaces
Projection and other math that is cumbersome currently

Options

Transform socket
- Benefits are a clear use case definition, and the clearer possibility of abstraction to make things simpler for users. But it would be a leaky abstraction.
Matrix socket
- With subtypes for different matrix sizes used in the UI
- With implicit different matrix sizes used internally
- Biggest question is how conversions between subtypes would work
4x4 matrix socket, 3x3 matrix socket, etc.
- The biggest upside would be not confusing very different matrices like 2x2 and 4x3, etc, once we have support for those suptypes.
- If we were building a programming language, this would be the way to go. But socket types are mainly for the UI, and to define implicit conversions. So I don't think the explosion of socket types would be worth it.

Proposal

Add one matrix socket right now, called "Matrix"
Use "Transform" word in node and socket names whenever the matrix is semantically used as a transform.
Internally, node systems can change the internal format based on runtime or static information. The user doesn't have to know about this though.
Default values are not exposed at all in the UI for the initial PR, instead rely on explicit conversions. In the future they can be edited in a popup. At that point, the socket subtype would be added.
Attribute types are specific to certain matrix dimensions. We would start with float4x4.

Concerns

Wrapping up float3x3, float4x4, float2x2 in the same socket type might not work when one really wants to use a non-4x4 type. It might be too much of a loss to display them all with the same color

Nodes

Transform Point
Transform Direction
Project Point
Multiply Matrix
Location to Transform
Rotation to Transform
Scale to Transform
Vectors to Matrix
- 3x3 and 4x4 options initially
Invert Matrix
Transpose Matrix

More builtin nodes might be helpful. In particular nodes to construct a matrix based on orthonormal axes may be helpful for curve deformation. But plenty could be handled by node group assets as well.

Implicit Conversions

Rotation to Matrix
Matrix to Rotation

Only provide implicit conversions with rotations. Other conversions might lose too much information and would be confusing, or they would make arbitary choices about the use of the matrix.

However, it might be that implicit conversions to and from vectors (location component) and floats (scale) would be useful and obvious enough to add.

## Use Cases - Viewport transform node for node tools ![image](/attachments/d9a00ab6-0136-43cb-8dbd-76b2e0b6a79d) - Simpler access to all object transforms ![image](/attachments/49259d68-106a-4a80-b341-089a25ccbbde) - Simpler combination of transforms - Simpler transform from different spaces - Projection and other math that is cumbersome currently ## Options 1. Transform socket - Benefits are a clear use case definition, and the clearer possibility of abstraction to make things simpler for users. But it would be a leaky abstraction. 3. Matrix socket - With subtypes for different matrix sizes used in the UI - With implicit different matrix sizes used internally - Biggest question is how conversions between subtypes would work 4. 4x4 matrix socket, 3x3 matrix socket, etc. - The biggest upside would be not confusing very different matrices like 2x2 and 4x3, etc, once we have support for those suptypes. - If we were building a programming language, this would be the way to go. But socket types are mainly for the UI, and to define implicit conversions. So I don't think the explosion of socket types would be worth it. ## Proposal - Add one matrix socket right now, called "Matrix" - Use "Transform" word in node and socket names whenever the matrix is semantically used as a transform. - Internally, node systems can change the internal format based on runtime or static information. The user doesn't have to know about this though. - Default values are not exposed at all in the UI for the initial PR, instead rely on explicit conversions. In the future they can be edited in a popup. At that point, the socket subtype would be added. - Attribute types are specific to certain matrix dimensions. We would start with `float4x4`. ### Concerns Wrapping up float3x3, float4x4, float2x2 in the same socket type might not work when one really wants to use a non-4x4 type. It might be too much of a loss to display them all with the same color ### Nodes - Transform Point - Transform Direction - Project Point - Multiply Matrix - Location to Transform - Rotation to Transform - Scale to Transform - Vectors to Matrix - 3x3 and 4x4 options initially - Invert Matrix - Transpose Matrix More builtin nodes might be helpful. In particular nodes to construct a matrix based on orthonormal axes may be helpful for curve deformation. But plenty could be handled by node group assets as well. ### Implicit Conversions - Rotation to Matrix - Matrix to Rotation Only provide implicit conversions with rotations. Other conversions might lose too much information and would be confusing, or they would make arbitary choices about the use of the matrix. However, it might be that implicit conversions to and from vectors (location component) and floats (scale) would be useful and obvious enough to add.

image.png

15 KiB

image.png

12 KiB

👀 3 ❤️ 5 🚀 3

Hans Goudey added the

Type

Design

label 2023-12-12 00:09:39 +01:00

Hans Goudey added this to the Nodes & Physics project 2023-12-12 00:09:41 +01:00

Hans Goudey commented

2023-12-12 00:12:09 +01:00

There was some work on this before #105408. Conflicts make it hard to reuse the code though.

I think this approach is a bit simpler, with fewer nodes in the proposed initial version.
Also, using the "Transform" abstraction as UI text and still allowing access to the internal data should be the best of both worlds IMO.

There was some work on this before #105408. Conflicts make it hard to reuse the code though. I think this approach is a bit simpler, with fewer nodes in the proposed initial version. Also, using the "Transform" abstraction as UI text and still allowing access to the internal data should be the best of both worlds IMO.

Hans Goudey referenced this issue

2023-12-13 18:27:13 +01:00

Matrix operations and sockets for geometry nodes #105408

Hans Goudey referenced this issue

2023-12-14 00:32:17 +01:00

Geometry Nodes: Matrix socket type, attribute type, and initial nodes #116166

Hans Goudey referenced this issue from a commit

2024-02-13 18:59:45 +01:00

Geometry Nodes: Matrix socket type, attribute type, and initial nodes

Sign in to join this conversation.