Ok, so you did not make two merge by distance nodes, you just changed the node to use the same algorithm as the modifier this week, am I understanding it right? I apologize if I am being stupid here
EDIT: I think I finally understand it now, So there was an older patch for the node, and that older version was using a different algorithm. But afterwards he thinks the modifier uses a better algorithm so he made a new merge by distance node using the modifier’s algorithm. So he did make two nodes, but I’m not sure what he’s gonna do with the older one, is it simply abandoned? The patch is still open though.
EDIT: I just got the two builds and tested out. It’s strange, the newer one (D12019) does not seem to support point cloud but it still features a point cloud video on its page. It makes sense why it does not support point cloud, given the fact that it’s under “mesh” category. The older one (D10888) does support point cloud, therefore it is under the “Geometry” category.
But… What is going on here then? Is the plan to keep both? But the older one also support mesh which overlaps the new one (though they behave differently since the newer one is a port of the modifier).
Or is the newer one going to support point cloud in future development, and the older one will be abandoned? But the newer one is currently in mesh category, does it make sense to support point cloud on a mesh node?
Or will the older one remove mesh support and rename to “Point Merge by Distance” and the new one being “Mesh Merge by Distance”?
I am genuinely confused.
Hi Eary, I’m sorry for the confusion sometimes the videos on the patches become outdated very quickly. I added back the support for point clouds last week and moved the node to geometry section.
This week I did more polishing on all nodes that I have done so far.
I pushed the Buildbot to make some Test Builds of all the branches, that can be used for testing and to supply feedback.
You can download them under the Builds/Experimental Section on blender.org
Testing and Feedback from Artists is very welcome at this stage to help me making the nodes better.
Great news Fabian! It looks like you are doing a great job!
I didn’t expect an extrude node since you claimed that you are porting the modifiers to nodes, but the extrude node Is one of the most urgent nodes imho to start testing some more advanced procedural modeling with geo nodes. However, I think that ways to easily select components to be extruded are necessary along with an extrude node.
How do you plan to manage selections? It would be great to have a prototype of a “select by index” node or a “select inside volume” node to be used in combo with the extrude node.
So far, design wise, the only info I’m aware of about selections in geo nodes Is this:
It seems to have less builds than I last saw it, but I think we can still find those removed builds in the “All Archived Builds”. Are they removed from the list because they are outdated though?
Great! Do you think there will be time to implement extrusion subdivision, twist and negative extrude?
And by the way the extrude node is included in the fields experimental build, so I had a chance to try it on windows!
Works fine so far! Maybe a toggle to limit the inset to prevent self intersection would be useful as well.
Thanks a lot for the great work!
Hello-
wonderful Stuff-I really hope we can see these in Masterr soon
Are also considering porting the shrinkwrap modifier?
When so, could you make sure that it accepts Curves as Target as well-
It is one big thing thats still missing!
Yeah, the initial idea is to have core features(proximity, raycast…) of modifiers as separate nodes so user can recreate them, BUT having the control of how they function under the hood in his hands.
A bundled node group is indeed good idea, but should be community effort though.
Not sure I agree here… I understand that for a first iteration, (and for further advanced use) core nodes that can be assembled with high controls are the way to go.
But then, having specific nodes ready to be used (like shrinkwrap) , bundled with blender (not from community alone) Is something really needed for a complete, user friendly toolset. Think about shader nodes atomic shaders: of course you want every single node to create whatever you want, but a principled bsdf was really needed at some point, even if theoretically, you could recreate it combining basic nodes.
I tend to agree with you. I think that kind of construct should be part of the official asset bundle planned for 3.x. That being said, the shrinkwrap modifier is not going anywhere (at least not right now), so there is no real incentive to replace it immediately.
Not sure why you see it as a problem to let community to build node groups assets AND have it bundled with Blender then, Blender’s ecosystem is based around community with help from core developers. I don’t think core developers should be the one creating node groups, it’s not necessary to waste their time with an effort that can be accomplished by the community, I have no problem to volunteer to organize such effort
This is where I see core developers should step in and help us. Current UI/UX of Geometry Nodes modifier properties panel is far from ideal, I mean having to linearly scroll over tenths of exposed parameters is rather challenging, but I understand this is not a priority now.
Shrinkwrap modifier is challenging UI wise too as it consists of four Wrap Methods each having its own set of parameters. To wrap it up I think it’s not that hard to re-create each wrap method as a separate node group, but it’s not possible(now) to have them combined into, as you said, user friendly toolset.
Edit: Actually if you think this deserves further discussion please create a new thread so we’re not hijacking Fabian’s Weekly Reports thread
