New node Active Element just landed for tools. Here’s a simple setup for merging selected points to the active one:
12 Likes
This plus modal support is going to be so nice!
1 Like
The blog post from this year’s geometry nodes workshop was published:
And the corresponding meeting notes:
I’m pretty excited about the potential of lists!
It’s a bit of a bummer, that it’s only going to be flat lists in the begining, but I imagine “list fields” will probably make up for that to some degree.
13 Likes
Very exciting indeed ! I can’t say I see the potential for lists, from the mention of topology nodes I suppose accessing many neighbouring elements on a mesh will be simpler, but I really can’t see it right now. I’m stoked for all things relating to interface though, working with nodes could be much simpler and cleaner in general and I’m glad the focus is on this aspect…
4 Likes
I was hoping for a shift on modeling features, but can’t blame them wanting to polish existing features and UX to perfection.
It seems most of the improvements proposed here will only benefit power users though. I think it will benefit the geometry nodes development to start including regular artists in the discussion as well, so that majority of userbase isn’t alienated from the feature.
I’m pretty excited about gizmos tho, and it seems pretty good time to bring up automatic reroute labeling thing 
5 Likes
Oh my god I forgot about the reroutes. There was a task to redesign/embiggen them so you can actually grab them with a mouse click (assuming left-click select). To me this is the most important thing of all. It looked finished last I saw it but that was at least two years ago. I don’t think it’s mentioned in the workshop.
2 Likes
I guess you mean this old patch for reroute node improvements: https://archive.blender.org/developer/D11209
For me, these things usually end up in a limbo state, unfortunately.
While there often seems to be a general sentiment that they are nice to have, between the core team having more important things on their plate and me only working on them sporadically in my free time, the momentum is eventually lost.
5 Likes
If I’m not mistaken your reroute label as been approved ? Thanks a lot for your patience and your efforts to make it append ! It’s really a great step toward better node tree documentation.
4 Likes
That’s precisely it ! would fit right into the workshop theme. It feels like a good opportunity to bundle it up with the rest, if it really is low-hanging fruit. Do you think I should bring it up with them ?
Okay, I just respectfully did.
2 Likes
I love all the talk of new stuff,
However… I think that we should take a look backward at performance / realtime.
(the bvhtree/kdtree caching stuff for meshes that don’t change)
I have a feeling they are avoiding this because it is very tricky*
maybe IdeasMan or Brecht can help with design?
2 Likes
And not a single word about Hair or Cloth simulation… sadness 
Maybe next year…
3 Likes
If BVH trees are as much the silver bullet of optimization techniques you advocate, then the devs. would probably be aware of that and have more patches that integrate such structures. Based on experience, it is not a good idea to assume the devs. have a lack of awareness of available solutions for future work.
Besides that, commit logs show that optimization remains a continuous subject. HowardT has worked on a much faster exact math boolean algorithm and has Manifold in his sights (not committed yet), and a good chunk of Hans work is improvements in both performance and in memory use.
7 Likes
Well, indeed it might be helpful to have control over the cache that nodes like raycast are using internally.
IDK if it would be about storing the BVH for reuse, or just storing the results as an attribute to avoid recomputing stuff.
I find myself in a few situations where some theoretically possible optimizations turned out impossible because of that : each time you inspect the output of a raycast node it’s getting evaluated multiple times.
Things might be better now, currently I’m on 4.0 :
It’s clear that the first call is doing the heavy work with 12000ms evaluation time :
Next ones are just about 200ms, but as you see the hit normal is called twice, where reusing/copying that attribute took less than 1 ms.
This case is obviously pretty basic, but I find myself in position where I had to completely evaluate the raycast twice, or it was impossible to optimize because I had limited control over what’s happening under the hood.
Anyway, while it’s something useful, it’s right to ask how useful that is on a regular basis ? It’s helping to make things faster in some situations but it’s still a niche feature.
However, what’s great with current development strategy is that’s generally things that will impact everyone, and when it’s not the case it’s always some generic stuff that a lot of users will benefit from.
A lot of the plan is also about wrapping up or polishing projects that are already started, without completely starting new ones for the most part.
I also have my own personal wishlist, but I must admit that, as always, they are making clever choices that will have a strong impact on the project as a whole, especially since half of the plan is about usability and handling large trees.
It’s great to see some strong foundations being laid out or solidified, hopefully at some point they’ll be back at working more specific features and filling missing blocks there too.
4 Likes
This certain case is more like leg shoot, but making that more general optimization requers intoducing much more complicated system to represent each geometry component as set of attributes and decide node dependencys on the attributes states and build more complicated internal graph to reflect this…
2 Likes
There is an even easier solution to non reusable non shared node groups used for organizing. Just let us collapse the visibility of frames down to the label of the frame. We don’t need accessible sockets or jumping in an out of another view. We just need things that help us organize the spaghetti visually. As to their proposal I see node groups as functions in programming and in JavaScript all functions are scoped to the parent function they were defined in. I don’t see why that can’t be done the same for node groups. I’m general I think this area of blend would benefit greatly from name spacing. When I add a node now I see a thousand things under the group menu from various add-ons and I have no idea which add-on any of them is from which makes it a pain in the butt to figure out where to go look for documentation about it. But if they were namespaced under the add-on or programmers name that would help greatly.
The proposal talks about custom viewers but they still refuse to let us have even a tiny bit of customizability over how shaders are previewed in workbench engine.
the raycast node - internally uses bvhtree,
other nodes likely do as well,
kdtree is used in ‘nearest neighbor’ or ‘points in radius’ type searches
this is not advocating for adding anything new, so much as caching ones we create that don’t change from frame to frame *
1 Like
People actually use workbench?
Is there anything else ?
2 Likes
Hey, a while back there was talk about implementing some magical boolean library that was supposedly x500 times faster than Blender’s current booleans. I see in 4.2 that the mesh boolean node has a dropdown with float and exact (in 4.1 there’s no choice, it just uses exact). Is that this new library? It is faster (you can actually work “live” with the bools), but I wouldn’t say it’s x500 faster 
