Geometry Nodes Development Discussion

A post was split to a new topic: Selecting GN instances by name

I have to say, this is something I’ve wondered about quite a lot, it would be really amazing to be able to define a custom interface for geo nodes modifiers.

One way might be to allow users to define a text data block for every node group that has some UI code that gets drawn on the modifier, instead of the default we have currently.
If it was implemented, it would really open a lot of possibilities for customization!

3 Likes

That was EXACTLY what i suggested to the developers chat last year, they didn’t like the idea

“python is too complex for geonode users” ect
 i think they will try to go for a solution similar to houdini, it would be way less flexible

1 Like

Hmm, yeah, I kinda got the feeling that that would be the opinion of the devs :frowning:
It’s a shame because it has so much potential.

I kind of understand where they’re coming from, but at the same time, the users who are using geometry nodes are already going to be pretty technical, and the users who need to create custom UIs for geometry nodes are probably going to want to learn about the python API at some point anyway


Out of curiosity, how does it work in Houdini? I’ve never used it before


Here is a short presentation : https://www.youtube.com/watch?v=g5E4GYKlY18
It’s pretty full-featured honestly. As far as I know it relies on Qt for building the actual interface -Blender developers would have to create their own solution I suppose. See the staggering amount of parameter types that can be added (leftmost column)
 arranging them hierarchically automatically creates corresponding tabs in the interface.

1 Like

Yeah, that looks like it would definitely work, but I think it would be a mistake to rely solely on a solution like that, when there’s so much more potential underneath it when using python.

Actually, though, I think that would be quite a good idea for an addon
 It would be quite possible to make one that lets you construct a UI visually, and then converts it into a script automatically.
In that case you could have the best of both worlds, where newer users could use the GUI addon version to make the interfaces, and users with scripting knowledge could use the more powerful python API underneath.

It’s an interesting thought, though it’s likely quite a long way away


5 Likes

Yeah, i think geonode users are what we call power users, geonode has a level of difficulty right below scripting, and scripting layout is a good first step on learning bpy, which should be considered as feature of blender in it’s own

3 Likes

Super cool ! Thanks a lot for sharing this ! It can be really useful when working in GN with big trees .
I guess this is what we could call a .feature !
Hard to find if you don’t know, but quite handy anyway !

3 Likes

Wow this is amazing!!! Its already helped me clean up the scene I’m working on. And if you type in the period in the modifier, all the node groups show up so you can still access them easily. Thanks for the new knowledge!

3 Likes

https://developer.blender.org/D14389

Woah, look at this. Procedural UV unwrapping? Yes please!

7 Likes

is it a “closed” webpage?
It asks me to login.
I remember that that kind of pages were visible for everyone.

Where am I wrong?

Patch pages can have various levels of visibility (“No login required”, “Users Only”, “Private”, etc.). It just so happens that for some reason this patch is “Users Only” so you need to login. I changed it to “Public” so you should be able to see it now.

6 Likes

Isn’t UV Packing quite slow to calculate?

I think they should work on a better update/baking management solution first, so we’ll be ready for the more computer-intensive node in the future

2 Likes

Hmm
 I think you’re right. Uv unwrapping and packing are both long processes.

Unless they get some serious performance improvements, I wouldn’t want to put this node in the middle of my tree and have it freeze on every update. Instead, I would like to lock those nodes after one evaluation, and keep them there in case I want to undo it, but not update every time after the first.

3 Likes

The more I see nodes that are costly to calculate, the more I hope for a caching/freezing system to be worked on. Booleans, UV unwrapping, etc. That being said, these UV nodes were made by a volunteer.

3 Likes

Or at least a way for nodes to be evaluated in the background, locking related objects in the viewport while keeping the rest of Blender, and your machine, responsive. With 16 threads becoming mainstream now, it should be possible to have more evaluations become non-blocking and lazy in nature.

2 Likes

The fact that changing a single parameter or interacting with object/collection dependencies recalculates the whole nodetree, while trying to push as many update signals as possible per frame is quite bad, there are a lot of optimization potentials in this area.

For example, here’s a simple 3.2 scene demonstrating how update dependencies are flawed. Adding a Object/collection pointers, even muted/disconnected can seriously impact your performance
ezgif-4-332525c923

3 Likes

I suppose Jacques is aware of these limitations, at least his writeup on the new evaluator suggests he intends to lift many of them. I can’t say whether or not the “background processing” Ace mentioned is related to this.

3 Likes

Just wanted to expand on this subject:
in my plugin, instead of running the update functions directly, it is first passing in a wrapper function that gives users more control on update behaviors such as:

  • choosing an update refreshrate
  • update by clicking on a global refresh button
  • or only updating once the property/object tweaking has halted

This is what the “on halt” update method looks like

pubforestation

https://gfycat.com/plainboguscicada

Houdini does possess such update management system, right now blender is trying to push update as fast as possible all the time. Perhaps update management could be implemented as a “update control” node, that let the data flow pass/stop based on user criteria, just thinking

10 Likes

This specific problem isn’t related to the evaluator actually, moreso the dependency graph. There is room to remove these unnecessary dependencies though.

10 Likes