Add a simple Switch node #85374

New Issue

Simon Thommes · 2021-02-04T13:18:51+01:00

Simon Thommes commented

2021-02-04 13:18:51 +01:00

Implement a simple first iteration of a switch node that only supports to be based on a boolean primary input to switch between two secondary inputs.
(It is planned to get this based on an index integer with variable amount of secondary inputs, but there needs to be a solid design for that first. The multi-input socket is currently not suitable when the order matters.)

The name of the output socket should depend on the set type.

The enum to choose the type of the output and secondary inputs should contain the following options:

Float (default)
Integer
Boolean
Vector
Color
String
Geometry
Object
Collection

--

Implementation:

{F10051197, size=full}

Implement a simple *first iteration* of a switch node that only supports to be based on a boolean primary input to switch between two secondary inputs. (It is planned to get this based on an index integer with variable amount of secondary inputs, but there needs to be a solid design for that first. The multi-input socket is currently not suitable when the order matters.) ![image.png](https://archive.blender.org/developer/F9630343/image.png) The name of the output socket should depend on the set type. The enum to choose the type of the output and secondary inputs should contain the following options: - Float (default) - Integer - Boolean - Vector - Color - String - Geometry - Object - Collection -- Implementation: {[F10051197](https://archive.blender.org/developer/F10051197/image.png), size=full}

Simon Thommes commented

2021-02-04 13:18:51 +01:00

Added subscriber: @SimonThommes

Some User commented

2021-02-04 13:22:23 +01:00

Added subscriber: @someuser

Some User commented

2021-02-04 13:22:23 +01:00

imho switch node need integer variable as index input (not binary thing)
and multiinput socket for:
Integer
Boolean
Vector
Color
String
Geometry
Object
Collection

imho switch node need integer variable as index input (not binary thing) and multiinput socket for: Integer Boolean Vector Color String Geometry Object Collection

Kenzie commented

2021-02-04 13:26:28 +01:00

Added subscriber: @KenzieMac130

Kenzie commented

2021-02-04 13:26:28 +01:00

In #85374#1107044, @someuser wrote:
imho switch node need integer variable as index input (not binary thing)
and multiinput socket for:
Integer
Boolean
Vector
Color
String
Geometry
Object
Collection

Hard agree! It should still handle binary switches but being able to switch between many different versions of geometry is just as crucial if not more than the merge node accepting more than one item.

> In #85374#1107044, @someuser wrote: > imho switch node need integer variable as index input (not binary thing) > and multiinput socket for: > Integer > Boolean > Vector > Color > String > Geometry > Object > Collection Hard agree! It should still handle binary switches but being able to switch between many different versions of geometry is just as crucial if not more than the merge node accepting more than one item.

Simon Thommes commented

2021-02-04 14:55:30 +01:00

@someuser @astrand130
Note:

simple first iteration

It is planned to support a variable amount of inputs in the future, but there needs to be a solid design for that first. The multi-input socket is currently not suitable when the order matters.
For now this is just a first step to get the binary functionality as a node faster.

I updated the description of the task to make this more clear.

@someuser @astrand130 Note: > simple first iteration It is planned to support a variable amount of inputs in the future, but there needs to be a solid design for that first. The multi-input socket is currently not suitable when the order matters. For now this is just a first step to get the binary functionality as a node faster. I updated the description of the task to make this more clear.

Miro Horváth commented

2021-02-11 12:17:07 +01:00

Added subscriber: @MiroHorvath

Eitan Traurig self-assigned this 2021-02-17 19:41:52 +01:00

Pablo Vazquez commented

2021-02-18 01:04:02 +01:00

Added subscriber: @pablovazquez

Pablo Vazquez commented

2021-02-18 01:04:02 +01:00

Posting this mockup of how a more advanced version of this node would be. (shared it on blender.chat but keeping it here for later reference)

Basic design on the left. Possible look when connected on the right, with a subtle highlight on the matching socket. And socket number displayed when connected.
{F9813701, size=full}

Posting this mockup of how a more advanced version of this node would be. (shared it on blender.chat but keeping it here for later reference) Basic design on the left. Possible look when connected on the right, with a subtle highlight on the matching socket. And socket number displayed when connected. {[F9813701](https://archive.blender.org/developer/F9813701/image.png), size=full}

Erindale commented

2021-03-08 16:49:22 +01:00

Added subscriber: @Erindale

Erindale commented

2021-03-08 16:49:22 +01:00

In #85374#1114542, @pablovazquez wrote:
Posting this mockup of how a more advanced version of this node would be. (shared it on blender.chat but keeping it here for later reference)

Basic design on the left. Possible look when connected on the right, with a subtle highlight on the matching socket. And socket number displayed when connected.
{F9813701, size=25}

I think it should not have separate input sockets as we've already got the multi input sockets with the Join node. Perhaps it could have the multi input socket and highlight the connecting noodle to show which one is selected?
That might be slightly an accessibility concern if it's not clear which input is live or how to reorder inputs but maybe better than adding another UI design.

> In #85374#1114542, @pablovazquez wrote: > Posting this mockup of how a more advanced version of this node would be. (shared it on blender.chat but keeping it here for later reference) > > > Basic design on the left. Possible look when connected on the right, with a subtle highlight on the matching socket. And socket number displayed when connected. > {[F9813701](https://archive.blender.org/developer/F9813701/image.png), size=25} I think it should not have separate input sockets as we've already got the multi input sockets with the Join node. Perhaps it could have the multi input socket and highlight the connecting noodle to show which one is selected? That might be slightly an accessibility concern if it's not clear which input is live or how to reorder inputs but maybe better than adding another UI design.

Satish Goda commented

2021-03-10 04:55:53 +01:00

Added subscriber: @satishgoda1

Johnny Matthews commented

2021-03-12 17:33:46 +01:00

Added subscriber: @guitargeek

blender-admin commented

2021-04-19 10:38:50 +02:00

This issue was referenced by 799f532f46

This issue was referenced by 799f532f4698ff07353a384ed99131042b5e05de

baoyu commented

2021-04-21 23:41:16 +02:00

Added subscriber: @baoyu

baoyu commented

2021-04-21 23:41:16 +02:00

please add this in the shader node too!

Zijun Zhou commented

2021-04-22 01:35:02 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2021-04-22 01:35:02 +02:00

In #85374#1150079, @baoyu wrote:
please add this in the shader node too!

I think in shader nodes, we already have the Mix RGB and Mix Shader for similar usage. It is just that in Geometry Nodes' context, a "switch" makes more sense than a "mix", imho

> In #85374#1150079, @baoyu wrote: > please add this in the shader node too! I think in shader nodes, we already have the Mix RGB and Mix Shader for similar usage. It is just that in Geometry Nodes' context, a "switch" makes more sense than a "mix", imho

baoyu commented

2021-04-23 08:41:55 +02:00

In #85374#1150095, @Eary wrote:

In #85374#1150079, @baoyu wrote:
please add this in the shader node too!

I think in shader nodes, we already have the Mix RGB and Mix Shader for similar usage. It is just that in Geometry Nodes' context, a "switch" makes more sense than a "mix", imho

Of course the mix node can do the job. It's just like the relationship between "switch case" and "if else" in programming languages. It tides up the node tree and make it more readable and much eaiser to manage.
In shader nodes, say I want to make a material for 100 photo, which are made of the same paper, the only difference is that their content differs. In this example you could tweak one as standard and use it to duplicate 100 materials. What if you want to change the roughness or any other mat?
Then comes the mix node, use object id as the mix factor to recursivly mix between 100 photo. While the node tree will be to long to read and manage.

> In #85374#1150095, @Eary wrote: >> In #85374#1150079, @baoyu wrote: >> please add this in the shader node too! > > I think in shader nodes, we already have the Mix RGB and Mix Shader for similar usage. It is just that in Geometry Nodes' context, a "switch" makes more sense than a "mix", imho Of course the mix node can do the job. It's just like the relationship between "switch case" and "if else" in programming languages. It tides up the node tree and make it more readable and much eaiser to manage. In shader nodes, say I want to make a material for 100 photo, which are made of the same paper, the only difference is that their content differs. In this example you could tweak one as standard and use it to duplicate 100 materials. What if you want to change the roughness or any other mat? Then comes the mix node, use object id as the mix factor to recursivly mix between 100 photo. While the node tree will be to long to read and manage.

Dalai Felinto commented

2021-05-03 14:06:22 +02:00

Added subscriber: @dfelinto