Geometry Nodes Development Discussion

Continuing the discussion from this megathread. Please limit the conversation here to just being about the development of the Geometry Nodes feature.

  • Experiments with GN should be posted in #artwork:blender-tests
  • Support questions for using GN should be posted in the appropriate #support category
  • In all cases, take advantage of the #geometry-nodes tag to other GN enthusiasts can follow along

3 posts were merged into an existing topic: Megathread discussion, revisited

I think what is really really needed is some sort of auto-clean up auto-align node trees in a similar way that it’s implemented in Houdini. Those node trees tend to get very messy after a while, this is true for shader nodes as well.

I know there is an add-on that does this, but I think it really needs to be a native coded implementation


Soooo 3.2 will be out soon, and lead devs already terminated the legacy nodes
meaning thousands of users will suddenly wonder why their scenes don’t work anymore

any though? As a plugin dev, I do not think this was a responsible decision, way too soon.


They’ll still be able to access their files in earlier versions. But I think this was a smart decisision, so that those that are still using legacy nodes are almost forced to transition so that they don’t have as large of a leap to make from attributes to fields.


I do think a message indicating the legacy node in the interface somewhere is necessary

Like where? A message they get before downloading the new version so that they know? Or a message telling them inside Blender itself that they are no longer avaliable?

Inside blender itself, within the modifier interface.
That would be nice :slight_smile:

I guess that would be useful, especially for all the more causual blender users who aren’t paying attention in detail to everything being updated so that they know why their files aren’t working anymore.

Sounds like a good candidate for a relatively easy patch from someone with a little programming background. :wink:


does anyone know if there is an add on for customization within the geometry nodes stack. Like adding dropdowns to organize it when you have a ton of different inputs?

if they used python layouts we could have whole geometry node based plugins stored in modifiers, it would’ve been awesome


It also would have been extremely slow :wink: python creeps along at sloth pace compared to C++

Nah it would’ve been fine, most of blender GUI is using python layouts


Not saying it wouldn’t be nice to have but I’d rather have some kind of clear way to indicate node groups meant for re-use separate from node groups that were created just to clean up a node tree and make it easier to read. I have this same problem with Collections.

We should really try to inform newcomers and less computer savvy people about how convenient and useful it is to have a handful of different blender versions available (and even open) all at the same time.

1 Like

Are you looking for something that’s more programmatic (like you can filter based on whether it’s for organization or reuse) or more of a visual indicator?

I’d prefer programmatic. When I’m trying to understand/refactor a shader or geometry node network I tend to make a hell of a lot of frames which eventually become groups which eventually become groups within groups within groups. Days/weeks/months/2 years later when I want to reuse a group in another project there’s like 17 things to choose from and 16 of them are not the one I want. So then I’ve got to go back to the original file and implement some kind of naming convention to make the main thing easier to locate in the Add > Group list.

Some kind of switch to say “Don’t appear in this list” is what I really want.

My current naming convention is to put at $ at the start of reusable group and collection names. This has the wonderful side effect of putting such things at the top of the list. I sometimes also “namespace” groups because I’d have 2 things with the same name imported from different projects that are not exactly the same. So for example $project-one / $rough-chrome and $project-two / $rough-chrome. There’s a program I use for git called Sourcetree that intelligently recognizes the / in a name and automatically displays such names as submenus and nested sublists.

So many parts of Blender desperately need some kind of namespacing in my opinion.

or more of a visual indicator?

Many types of visual indicators don’t work for me. I strongly prefer reading words over recognizing icons. It’s the main reason I like Blender over Maya. I’m kind of colorblind so various shades of red/green/orange/brown/blue/purple/pink are meaningless to me.


That’s like navigating a single 9000 line long code file instead of breaking things up into functions (that may or may not be reused someday but they are not being reused today) to make the code much much easier to read and understand at a glance.

Also sometimes things are only reused within one area and while I’m working in that area I’m more likely to shift+d an existing group node. When I leave that area to work on other things, I’d rather not have the groups from that first area polluting the list of things I’m more likely to reuse at a higher level.

1 Like

From here. (Not something obvious I could find in the manuals and something I think everyone should know.)
Adding a . as the pre-fix to any node-group’s name will hide it from the Group list. Then the only way to use “hidden” node-groups is to find where you use them and Copy-and-Paste them.

All this can definitely be improved, and I’m sure it will one day.

Good luck.


oh wow, someone accidentally triggering this via a typo would probably lose their mind.
They should at least be gathered into a submenu named “.” or “secondary” or “unimportant” or “Other Groups” or something.

1 Like

For nodes you can use addon that automatically make submenus for groups, splitting them by underscore in name.

Free, works with GN too :slight_smile: