Dynamic Menu Switch Node for Multiple Data Types

In short, this proposal would allow a single menu to switch several related data types at once, instead of requiring multiple synchronized switches.

The current Menu Switch node is very useful when selecting between multiple values of a single data type. However, things become much more complicated when a single menu needs to control several related values of different data types at the same time—for example, Color, Float, Vector, Geometry, or other data.

Current limitations

When multiple Menu Switch nodes are connected to the same menu socket, Blender reports a menu conflict, even if all menu items have identical names. The mockup below shows the current limitation A possible workaround is to use one Menu Switch as an Integer selector and then drive several Index Switch nodes with the resulting index. However, this requires every corresponding item to be manually kept at the same index across all switches. The mockup below shows the current workaround. This becomes increasingly difficult to maintain when a node group contains many options. Renaming, adding, removing, or reordering an item may require updating several nodes manually.

Large Menu Switch nodes can also become very tall when they contain many entries.

Proposal: Dynamic Menu Switch

I propose a Dynamic Menu Switch node that can switch multiple related data types through a single menu, with menu entries generated dynamically from structured data.

The node could have different modes.

Bundle mode

A Bundle could contain the values associated with each selectable item. Since Bundles can contain values of different types, one menu selection could switch several related data types together without requiring separate synchronized Menu Switch or Index Switch nodes. The mockup below shows the proposed Bundle mode.

Note: Undefined entries are intentionally kept visible.

Even when a menu entry cannot currently be resolved, its socket remains visible. Hiding undefined entries could make it appear that some Bundle elements—and the connections associated with them—do not exist. Keeping placeholder sockets preserves the visible structure of the Bundle and makes unresolved menu entries explicit.

List mode

Menu item names could be generated from a list of strings. This would make it possible for menu labels to follow dynamically generated or externally supplied data instead of being entered manually.

For example, a comma-separated string could be converted into a list and used as the names of the menu items. The mockup below shows the proposed List mode. Why this would be useful

This could make reusable Geometry Nodes groups much easier to build and maintain:

— one menu could control multiple related data types;

— menu items would not need to be duplicated manually across several switches;

— names could be generated or updated dynamically;

— complex node trees could become significantly smaller and easier to understand.

The exact implementation could of course be different, but the main idea is to have a menu selector whose items and associated data are not limited to one manually defined static Menu Switch.

I would be interested to hear what other Geometry Nodes users think about this proposal, and whether there are additional use cases or edge cases worth considering.