Rotation Nodes Design / Splitting Nodes #109965

Open
opened 2023-07-11 14:27:51 +02:00 by Hans Goudey · 18 comments
Member

The group of nodes above raise the question of consistency with the other somewhat similar "Separate Color" and "Combine Color" nodes. Though the rotation nodes are arguably more like "creation" or "conversion" nodes rather than "separation" or "combination", either way they make it clear we should have a better understanding of when we use a single node with multiple modes or many nodes.

Benefits of a single node with many modes

• Easy to switch behavior after adding the node.
• Easy to see available behavior after adding the node.
• More intuitive when the main purpose of the node remains the same, but the behavior is slightly tweaked.

Benefits of many nodes

• Easier to add different behavior with search and link drag search.
• More intuitive when the modes change the fundamental operations of nodes, changing available input or output sockets for example
• More scalable, especially in combination with user created node groups, which can fit in well with the design of builtin nodes.
• Design is simpler and less arbitrary when some operations don't fit with the overall name of the node. For example, some of the modes above are "separations," but most are just conversions.

The downside of making it harder to switch behavior (switch modes) can be lessened by improving or adding a "switch node" feature, so it's not a fundamental downside.

Proposal

• Use modes when the overall operation is the same, and the inputs and outputs have the same meaning
• Use separate nodes when the operation is different, or the inputs and outputs change significantly
• Make it easier to switch nodes, as a builtin feature
• Each node can contain a manually built list of similar nodes for easier switching

Consequences

• Split math operations to separate nodes that each handle multiple types

The group of nodes above raise the question of consistency with the other somewhat similar "Separate Color" and "Combine Color" nodes. Though the rotation nodes are arguably more like "creation" or "conversion" nodes rather than "separation" or "combination", either way they make it clear we should have a better understanding of when we use a single node with multiple modes or many nodes. ![image](/attachments/5161560d-5405-4686-950c-4b5624a132bd) **Benefits of a single node with many modes** - Easy to switch behavior after adding the node. - Easy to see available behavior after adding the node. - More intuitive when the main purpose of the node remains the same, but the behavior is slightly tweaked. **Benefits of many nodes** - Easier to see available behavior from add menu. - Easier to add different behavior with search and link drag search. - More intuitive when the modes change the fundamental operations of nodes, changing available input or output sockets for example - More scalable, especially in combination with user created node groups, which can fit in well with the design of builtin nodes. - Design is simpler and less arbitrary when some operations don't fit with the overall name of the node. For example, some of the modes above are "separations," but most are just conversions. The downside of making it harder to switch behavior (switch modes) can be lessened by improving or adding a "switch node" feature, so it's not a fundamental downside. **Proposal** - Use modes when the overall operation is the same, and the inputs and outputs have the same meaning - Use separate nodes when the operation is different, or the inputs and outputs change significantly - Make it easier to switch nodes, as a builtin feature - Each node can contain a manually built list of similar nodes for easier switching **Consequences** - Split math operations to separate nodes that each handle multiple types ![image](/attachments/48c25a8a-fd6d-4827-985d-8905c8dea16f) ![image](/attachments/cfba9f0d-4038-431b-8f5d-522661f2641d) ![image](/attachments/fba6cb37-3b48-423d-a6a3-8e92d6738eed)
38 KiB
37 KiB
42 KiB
25 KiB
added the labels 2023-07-11 14:27:52 +02:00
added this to the Nodes & Physics project 2023-07-11 14:27:53 +02:00
Interest
Animation & Rigging
label 2023-07-11 14:32:02 +02:00
Contributor

Blenders Geometry Nodes node-trees are already a cluttered as it is, especially compared to other softwares. Splitting Combine & Separate nodes into different modes is gonna make the matter much worse. I agree with every benefit of single nodes, and I don't think separate nodes have any pros.

Seeing "Combine Color" in add menu makes sense to you, seeing all this 5-6 options that supposedly do same thing are just confusing and make Add menu place to avoid.

Also when I want to combine color or XYZ I search for combine. This just ruins muscle memory, and makes searching for things harder too. Combine just shows you two nodes that combine stuff. Searching for Color, XYZ, RGB give you much broader list of nodes. More clutter.

Splitting Combine and Separate once again will mess with older tutorials and make things harder for beginners, who will be searching for Cimbine node and will either see nothing or 9 nodes with different names. It will change nodes in older versions of Blender, needing forward/backward compatibility.

Most importantly, it will be different from Shader Nodes and Compositor, and having ANOTHER incosistency between node editors is not ideal.

And lastly, especially with color, I want to try different methods to see what result I can get. Having to add second node to see Lightness value instead of Value is also not ideal. I hear about switch operator, but just why, when it's already here in enum list.

Member

And lastly, especially with color, I want to try different methods to see what result I can get.

If you're doing this while solving your task, chances are you just don't know what you're doing. It's as if you chose different math operations.

> And lastly, especially with color, I want to try different methods to see what result I can get. If you're doing this while solving your task, chances are you just don't know what you're doing. It's as if you chose different math operations.
Contributor

And lastly, especially with color, I want to try different methods to see what result I can get.

If you're doing this while solving your task, chances are you just don't know what you're doing.

I would like if once I had interaction with you in which you just weren't rude to me :)

If developers would like user's and add-on developers opinion about possible API-breaking changes it is there.

> > And lastly, especially with color, I want to try different methods to see what result I can get. > > If you're doing this while solving your task, chances are you just don't know what you're doing. I would like if once I had interaction with you in which you just weren't rude to me :) If developers would like user's and add-on developers opinion about possible API-breaking changes it is there.
Member

Seeing "Combine Color" in add menu makes sense to you, seeing all this 5-6 options that supposedly do same thing are just confusing and make Add menu place to avoid.

On the one hand, there are requests to add all math operations to this menu. On the other hand, as you say, adding different modes to this menu makes it worse. I wonder if it's just a search list. You don't need to scroll it. So what is the problem with a large number of elements?

Also when I want to combine color or XYZ I search for combine. This just ruins muscle memory, and makes searching for things harder too. Combine just shows you two nodes that combine stuff. Searching for Color, XYZ, RGB give you much broader list of nodes. More clutter.

And now you will be search `XYZ` and will be find both and separate and combine.

Splitting Combine and Separate once again will mess with older tutorials and make things harder for beginners, who will be searching for Cimbine node and will either see nothing or 9 nodes with different names. It will change nodes in older versions of Blender, needing forward/backward compatibility.

Changing anything, this argument is correct. Not sure if this makes sense?

> Seeing "Combine Color" in add menu makes sense to you, seeing all this 5-6 options that supposedly do same thing are just confusing and make Add menu place to avoid. On the one hand, there are requests to add all math operations to this menu. On the other hand, as you say, adding different modes to this menu makes it worse. I wonder if it's just a search list. You don't need to scroll it. So what is the problem with a large number of elements? > Also when I want to combine color or XYZ I search for combine. This just ruins muscle memory, and makes searching for things harder too. Combine just shows you two nodes that combine stuff. Searching for Color, XYZ, RGB give you much broader list of nodes. More clutter. And now you will be search `XYZ` and will be find both and separate and combine. > Splitting Combine and Separate once again will mess with older tutorials and make things harder for beginners, who will be searching for Cimbine node and will either see nothing or 9 nodes with different names. It will change nodes in older versions of Blender, needing forward/backward compatibility. Changing anything, this argument is correct. Not sure if this makes sense?
Contributor

On the one hand, there are requests to add all math operations to this menu. On the other hand, as you say, adding different modes to this menu makes it worse. I wonder if it's just a search list. You don't need to scroll it. So what is the problem with a large number of elements?

That is a good point, for math node I too would like the ability to be able to search Greater and Less Than, but if they were in different nodes that would quite ruin my workflow. But I'm not sure if different modes of Combine/Separate nodes need to be searchable, as it's not used as often as math node, which can often times be 2/3 of node tree.

Changing anything, this argument is correct. Not sure if this makes sense?

I have number of addons that either import Geometry Nodes setup from blend files, or create from scratch. Changing api will break all of those, and I would consider if breakign api is worth replacing 2 nodes with 6

> On the one hand, there are requests to add all math operations to this menu. On the other hand, as you say, adding different modes to this menu makes it worse. I wonder if it's just a search list. You don't need to scroll it. So what is the problem with a large number of elements? That is a good point, for math node I too would like the ability to be able to search Greater and Less Than, but if they were in different nodes that would quite ruin my workflow. But I'm not sure if different modes of Combine/Separate nodes need to be searchable, as it's not used as often as math node, which can often times be 2/3 of node tree. > Changing anything, this argument is correct. Not sure if this makes sense? I have number of addons that either import Geometry Nodes setup from blend files, or create from scratch. Changing api will break all of those, and I would consider if breakign api is worth replacing 2 nodes with 6
Member

Overall, I agree with the proposal. Having the inputs and outputs change dramatically based on the type drop-down is confusing, especially to new users. I am favour of more explicit nodes except in special cases (such as generic "math" nodes where there are only ever 1-2 inputs and outputs, all of the same type).

Arguably, this is more of a deficiency with the search algorithm. For example, I want be able to type "Add" in the search menu and have a list of all of the nodes where there is an "Add" in the `operation` or `type` (or whatever the primary "operation" switch is), similar to the behaviour of dragging output nodes and and having it auto-suggest a new node and socket to connect it to.

Overall, I agree with the proposal. Having the inputs and outputs change dramatically based on the type drop-down is confusing, especially to new users. I am favour of more explicit nodes except in special cases (such as generic "math" nodes where there are only ever 1-2 inputs and outputs, all of the same type). > Easier to see available behaviour from add menu. Arguably, this is more of a deficiency with the search algorithm. For example, I want be able to type "Add" in the search menu and have a list of all of the nodes where there is an "Add" in the `operation` or `type` (or whatever the primary "operation" switch is), similar to the behaviour of dragging output nodes and and having it auto-suggest a new node and socket to connect it to.
Member

This is a topic I always struggle with even though I've provided many GN and Shader node patches to improve what is available to users out of the box. Blender nodes are currently a mixture of low level and high level nodes. With GN it seems there is a move to having many low level nodes and expecting users to combine these and create node groups if they want new or different functionality. This contrasts to the idea of high level nodes with different modes and settings. I'm somewhere in the middle of these paradigms. For consistency I'd really like to see a Blender Node Style document that could set some design guidelines across Shading, Compositing and GN node systems for the benefit of developers and end users alike.

This is a topic I always struggle with even though I've provided many GN and Shader node patches to improve what is available to users out of the box. Blender nodes are currently a mixture of low level and high level nodes. With GN it seems there is a move to having many low level nodes and expecting users to combine these and create node groups if they want new or different functionality. This contrasts to the idea of high level nodes with different modes and settings. I'm somewhere in the middle of these paradigms. For consistency I'd really like to see a Blender Node Style document that could set some design guidelines across Shading, Compositing and GN node systems for the benefit of developers and end users alike.
Author
Member

Agreed about the importance of documenting this once it's written down and agreed on. I'll just emphasize the importance of node group assets in this design though-- the long term expectation isn't always that users will have to combine nodes themselves to get higher level behavior.

Agreed about the importance of documenting this once it's written down and agreed on. I'll just emphasize the importance of node group assets in this design though-- the long term expectation isn't always that users will have to combine nodes themselves to get higher level behavior.

btw, why is the input of the rotation type displayed as an Euler when it takes in a quaternion?
(and why is it named simply rotation?)

btw, why is the input of the rotation type displayed as an Euler when it takes in a quaternion? (and why is it named simply rotation?)

regarding the design, I don't think the converter nodes should be in the same node as the separate nodes, unless those nodes are renamed to convert node (or the like) and are the conversion to a float. then it could make sense to have a convert node that you set the "from" and "to" conversion from two drop-down.

regarding the design, I don't think the converter nodes should be in the same node as the separate nodes, unless those nodes are renamed to convert node (or the like) and are the conversion to a float. then it could make sense to have a convert node that you set the "from" and "to" conversion from two drop-down.
Author
Member

I did not know that vector rotate node had a euler mode for quite some time.

the operation

object.orientation.inverted() @ (World_Point - object_origin)

puts a point of space into local space for a object - (useful for texturing and all sorts of AI logic)

perhaps we could have some 'higher level nodes' - that are groups of nodes already in blender?

I did not know that vector rotate node had a euler mode for quite some time. the operation object.orientation.inverted() @ (World_Point - object_origin) puts a point of space into local space for a object - (useful for texturing and all sorts of AI logic) perhaps we could have some 'higher level nodes' - that are groups of nodes already in blender?
referenced this issue from a commit 2023-08-24 14:59:03 +02:00
Member

I'm guessing node vs modes is no longer a proposal. This creates a UI divergence with existing nodes.

Is the Swap Node Operator #111438 going to be a target for 4.1?

I'm guessing node vs modes is no longer a proposal. This creates a UI divergence with existing nodes. Is the Swap Node Operator #111438 going to be a target for 4.1? ![image](/attachments/e6fe1c31-1d5b-4f29-959d-00d1918deaef)

Contributor

In most node-based software, it's common to prefer the search bar to find nodes.
Ideally the search bar would display node subclasses separately.
For example searching "Combine Color" would display "Combine Color (RGB)", "Combine Color (HSV)", etc.

In the case of Combine Color nodes, before they were merged I saw some users made Python scripts to switch the node type. This shouldn't be required for nodes which are so similar in functionality, as mentioned in the original post.

Likewise with the Math nodes, in practice it's easy to use the wrong operation (addition instead of subtraction, etc), and need to switch the type. This is again something which would need a Python script if the nodes were separate.

If the goal is to have all nodes listed in the Add menu, consider the Math node contains 41 operations currently. This number barely fits on the node itself, let alone on the Add Menu. This is hardly convenient from a UI or user perspective.

In most node-based software, it's common to prefer the search bar to find nodes. Ideally the search bar would display node subclasses separately. For example searching "Combine Color" would display "Combine Color (RGB)", "Combine Color (HSV)", etc. In the case of Combine Color nodes, before they were merged I saw some users made Python scripts to switch the node type. This shouldn't be required for nodes which are so similar in functionality, as mentioned in the original post. Likewise with the Math nodes, in practice it's easy to use the wrong operation (addition instead of subtraction, etc), and need to switch the type. This is again something which would need a Python script if the nodes were separate. If the goal is to have all nodes listed in the Add menu, consider the Math node contains 41 operations currently. This number barely fits on the node itself, let alone on the Add Menu. This is hardly convenient from a UI or user perspective.
Member

Goal also is to split operations in different nodes and support all possible data type for each operation.

Goal also is to split operations in different nodes and support all possible data type for each operation.
Contributor

I saw Jacques said this too. I like the idea overall since it reduces the redundancy, though some operations like cross product only work on vectors. Maybe those operations could be grouped? (Dot product, cross product etc) Or maybe a single math node that does everything?

Also on an unrelated note, I wonder if Combine/Separate Color should be implemented as a color conversion followed by separation? Like RGB => RGB to HSV => Separate. In this case only Combine/Separate XYZ would be needed, and Combine/Separate could be generalized to matrices and quaternions.

I saw Jacques said this too. I like the idea overall since it reduces the redundancy, though some operations like cross product only work on vectors. Maybe those operations could be grouped? (Dot product, cross product etc) Or maybe a single math node that does everything? Also on an unrelated note, I wonder if Combine/Separate Color should be implemented as a color conversion followed by separation? Like RGB => RGB to HSV => Separate. In this case only Combine/Separate XYZ would be needed, and Combine/Separate could be generalized to matrices and quaternions.
Member

If you have thoughts #106680

If you have thoughts #106680
No Milestone
No project
No Assignees
8 Participants