5
$\begingroup$

Geometry Nodes and enumerated lists:

I was thinking of developing a complex node system with user selection enabling or disabling node groups much like an enumerated list in a script would allow a single user selection to perform various functions.

As such I thought I'd start small by just having a selection to create the primitives:

![](geo%20nodes%20enum%20operation.gif)

This quickly led to 2 issues that I'm wondering if perhaps there's a better way to achieve the overall goal.

1st: While technically there could be a string input if the user does not know all available options and enter an input case sensitive correctly there would be no feedback of the issue input not in list. Since I do not see a way to make a selection list the user input can only be an arbitrary number which while the user can scroll through and see feed back does not allow anticipation of the result and requires a user to scroll through the full range to even know what is possible.

2nd: Even a small sample of available inputs begins to create a fairly extensive tree simply testing an input value

![](file:///C:\blender%20forum%20questions\blender%20stack%20exchange\geo%20nodes%20enum%20list\node%20tree.png)

Is there a more efficient solution to testing an input within a range (list) and providing a specific output based on an individual input?

Additional info:

After rearranging and grouping the nodes I have an arrangement that can to some extent be easily modified.

![](Outer%20node%20group.png)

An outer node group is providing a macro level access for visibility.

![](outer_ng%20inside.png)

Within the outer node group sub node groups are connected which are largely just duplicated of a template. Each subgroup providing access to an index value (tested against the modifier input value) and string to be used for identification.

Then passing outputs only when the modifier input value is equal to the index of the sub group.

![](sub%20grp%20inside.png)

Because the subgroups pass all incoming requirements to the parent group the only required change internally is the actual geometry to build.

  • note confirmed geometry is not saved. --The concern I have with using a collection of premade geometry is going to be file size given the choice selections will not just be primitives.

Ideally I would still prefer a drop down text selection as the modifier value input but may have to postpone or scratch that idea unless I just want to have a script that creates only the desired node group. The problem with having a script only create the desired node group becomes lack of visual feedback to the user.

Edit 2:

Hybrid of @quellenform solution

Main object node tree:

![](main%20obj%20node%20tree.png)

Individual obj node tree:

![](basic%20node%20setup.png)

I have included a driver from the main object geo node index selection for each object in the collection to disable geometry if the index is not selected. While having the collection hidden does prevent the underlying nodes (and geometry they create) from being passed to the gpu and evaluated for shading etc, it does not prevent them from being evaluated by the cpu and loaded into ram.

![](memory%20usage.gif)

Ultimately it will include a trade off between when computation time occurs, adding the driver will add some minor overhead for its evaluation and available processing and memory on the end device as to which method works best but I believe saving some ram (~ 20 % of what blender was using in this example) for other process may end up being useful. Thanks to all for their inputs.

Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ You could put the objects in a collection, and instantiate them directly by index. $\endgroup$
    – quellenform ♦
    May 7, 2022 at 22:14
  • $\begingroup$ @quellenform perhaps I over simplified the process but the output of the joined geometry in the node setup shown above would then feed to another selection group sequentially 4 more times and getting the position of points of the geometry based on the previous selection might be more difficult that way i'll take a look. $\endgroup$
    – Ratt
    May 7, 2022 at 22:22
  • $\begingroup$ I did not really understand, which problems the solution of @quellenform could cause. Can you explain it differently? - An alternative could be, to use the "Geometry to Instances" node in combination with the "Separate Geometry" node instead of instantiation. $\endgroup$
    – André Zmuda
    May 8, 2022 at 10:50
  • $\begingroup$ Let me explain, as I think I understand Ratt pretty well. He'd like a Switch node with multiple inputs, and an integer with index, rather than boolean switch value. Ratther than using a binary tree with switches, he came up with an easier to maintain method of switching between a string/geometry that matches the index, and nothing, and then joining all results together. $\endgroup$
    – Markus von Broady
    May 8, 2022 at 14:29
  • $\begingroup$ @AndréZmuda the end goal is to have much more complex geometry available for each selection. While the point selection output is only an instance creating all the geometry into collections will force a large file size of objects that are never used. $\endgroup$
    – Ratt
    May 8, 2022 at 18:14

2 Answers 2

Reset to default
2
$\begingroup$

If you want to flexibly create various objects per index, it is best to use the following structure:

  • Put your objects into a collection (These objects don't even have to contain any geometry, but can also use Geometry Nodes there to create the geometry).
  • Get it with the node Collection Info.
  • Use the desired value as input for Instance Index in the node Instance on Points

enter image description here

And if you want to select multiple objects with one index, nest them again in a separate collection inside the chosen collection.

Remember: If there are no objects stored in a collection that contain any geometry, but instead only empty objects are placed there that create the geometry using Geometry Nodes, the whole thing also works.

Improve this answer
$\endgroup$
7
  • $\begingroup$ The way I understand it: what if you generate stairs, but there are 10 different generators, so you pick one. You don't want to evaluate the geometry unused geometry like in my answer. I think only switch works this way. $\endgroup$
    – Markus von Broady
    May 8, 2022 at 12:54
  • $\begingroup$ @MarkusvonBroady OK, I see, switch works this way, but which geometry should be evaluated here? In this case, one instance is simply selected by index, and all others are not treated further, right? ...or maybe I still didn't get the question ;-) $\endgroup$
    – quellenform ♦
    May 8, 2022 at 13:04
  • $\begingroup$ @quellenform added a bit to the question but the concern I have with instancing from a collection is that the collection objects must exist and that will end up in the multi million poly count for the file before a user combination is created. The switch allows only geometry for the user selection to be created. I understand that you are only instancing as your out put but all geometry must be available in the collection. $\endgroup$
    – Ratt
    May 8, 2022 at 18:07
  • $\begingroup$ @Ratt No, it doesn't, because you can also store empty objects in your collection, which create the geometry using geometry nodes. So you don't store unnecessary geometry in your file! $\endgroup$
    – quellenform ♦
    May 8, 2022 at 18:22
  • $\begingroup$ @quellenform how do you prevent the nodes from evaluating in the collection prior to selection? $\endgroup$
    – Ratt
    May 8, 2022 at 19:17
1
$\begingroup$

For strings you could use a hack like this:

For meshes:

But I think it actually makes it slower, especially for meshes (and the node count for meshes is similar to yours anyway).

I thought maybe a driver can be used, but there are problems, one being that a driver evaluates for the entire tree once (per frame), but the tree can be used for multiple objects (which may have different settings in the modifier stack)...

Improve this answer
$\endgroup$
2
  • $\begingroup$ Interesting approach on the meshes as for the text it's really only to try to offer a temporary explanation given there appears to be no means of a user selection by text. I'll try some additional testing but atm the node setup I have in the OP runs ~ 1/2 the timing of your approach. While 20 msec isn't much now once compounded through a few iterations of choices it may add up especially with more complex shape generation. Oddly the ico sphere primitive seems to be the slowest from what I've seen. $\endgroup$
    – Ratt
    May 8, 2022 at 0:40
  • $\begingroup$ @Ratt I'd expect my approach is so much more slower than double the time of yours if you connect some real computation there - because my approach has to evaluate everything, while yours evaluates only 1/n. For 10 elements my approach is 10 times slower on average. I just had some fun. $\endgroup$
    – Markus von Broady
    May 8, 2022 at 7:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .