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!
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
Hmm, yeah, I kinda got the feeling that that would be the opinion of the devs
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.
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âŠ
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
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 !
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!
https://developer.blender.org/D14389
Woah, look at this. Procedural UV unwrapping? Yes please!
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.
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
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.
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.
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.
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
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.
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
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
This specific problem isnât related to the evaluator actually, moreso the dependency graph. There is room to remove these unnecessary dependencies though.