blender/blender
147
472
Fork 688
Code Issues 6.7k Pull Requests 886 Projects 18 Wiki Activity

Rotation Nodes Design / Splitting Nodes #109965

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

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

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

image

image

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)
image.png
38 KiB
image.png
37 KiB
image.png
42 KiB
image.png
25 KiB
Hans Goudey added the
Type
Design
Interest
Geometry Nodes
 labels 2023-07-11 14:27:52 +02:00
Hans Goudey added this to the Nodes & Physics project 2023-07-11 14:27:53 +02:00
Iliya Katushenock added the
Interest
Animation & Rigging
 label 2023-07-11 14:32:02 +02:00
Nika Kutsniashvili commented 2023-07-11 22:39:03 +02:00
Contributor
Copy Link

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.

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.
👍 1
Iliya Katushenock commented 2023-07-11 22:47:15 +02:00
Member
Copy Link

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.
Nika Kutsniashvili commented 2023-07-11 22:50:48 +02:00
Contributor
Copy Link

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.
Iliya Katushenock commented 2023-07-11 23:01:06 +02:00
Member
Copy Link

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?
Nika Kutsniashvili commented 2023-07-11 23:11:42 +02:00
Contributor
Copy Link

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
Colin Basnett commented 2023-07-21 07:19:56 +02:00
Member
Copy Link

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.

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.
Charlie Jolly commented 2023-07-25 19:25:31 +02:00
Member
Copy Link

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.
👍 1
Hans Goudey commented 2023-07-25 19:41:20 +02:00
Author
Member
Copy Link

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.
Shmuel Israel commented 2023-08-01 13:24:40 +02:00
Copy Link

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?)
Shmuel Israel commented 2023-08-01 13:31:08 +02:00
Copy Link

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.
Hans Goudey commented 2023-08-23 16:32:02 +02:00
Author
Member
Copy Link

Created a followup task: #111438

Created a followup task: #111438
Jacob Merrill commented 2023-08-23 16:57:31 +02:00
Copy Link

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?
Charlie Jolly commented 2023-10-03 17:26:57 +02:00
Member
Copy Link

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

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)
Shmuel Israel commented 2023-10-11 00:40:10 +02:00
Copy Link

what do you guys think about adding Rotors and Matrices?

what do you guys think about adding Rotors and Matrices?
Hallam Roberts commented 2024-05-07 01:25:07 +02:00
Contributor
Copy Link

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.
👍 2
Iliya Katushenock commented 2024-05-07 07:36:08 +02:00
Member
Copy Link

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.
Hallam Roberts commented 2024-05-07 10:19:23 +02:00
Contributor
Copy Link

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.
Iliya Katushenock commented 2024-05-07 10:56:14 +02:00
Member
Copy Link

If you have thoughts #106680

If you have thoughts #106680
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
Backward and forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Viewport & EEVEE

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Module
Viewport & EEVEE

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Severity
High

  
Severity
Low

  
Severity
Normal

  
Severity
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Nodes & Physics
Assignees
Clear assignees
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#109965
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?