I see. Totaly missed that point instance node. Thanx for the explanation.
The Join Node
https://developer.blender.org/rB75a92d451ea24ff6f8174f26163b08088122ed3e
Acts just like the âJoin Objectsâ operator in object mode, but it can now be done as a modifier node.
11 Likes
How simple but effective and important this node is. I wished and hoped for a simple join-modifier all the time. Now with Geometry Nodes it finally comes true. 
8 Likes
As a Houdini user Iâm looking forward to Geometry Nodes in Blender and the progress looks like itâs going in the right direction.
Only thing that kind of bothers me (as in âI havenât quite understood why yetâ) is why one has to wire that âGeometryâ in- and outputs through all the nodes. Theyâre already dealing with geometry so what purpose does this serve? I know itâs not Houdini, but I donât have to tell each SOP node which geometry itâs working on, because well⌠itâs already assigned to a certain geometry. 
1 Like
Iâm only guessing: you can make multiple paths with nodes, so you might want the geometry to âsplitâ at a certain node and do 2 different chains of operations, then merge them later in the treeâŚ
Nice guess and thanks for your reply⌠but that is also possible without telling each node what âGeometryâ it is connected to, right? In the end, thereâs geometry coming in and going out of that node network, and everything in between adds, changes or deletes this geometry.
Maybe Iâm misunderstanding what you say but in geometry nodes you donât always use the incoming geometry. Sometimes you even leave it disconnected and use another geometry entered via an object info node, thatâs the current way of instancing particles over a surface as far as I know, since so far it is done in a point cloud object and you just ignore the point cloud geometry and use another one.
I donât know, I didnât try anything yet. Thatâs why I wrote I was guessing.
I think that youâll be able to call other objectsâ geometry into the nodetree. And anyway, if you modify the main geometry you get new geometry and you may want this to interact with the original one, as if they were two different objects. I.e. a displaced and beveled cube gets a boolean subtract by the original cube itself, and then beveled again.
OK, maybe I was a bit too fast there when I wrote âgeometry coming inâ. But even if you merge in external geometry, generate new geometry or instance stuff, in the end it doesnât matter where it came from as it all comes out as geometry inside the object the nodes are on, right?
Yeah, but again this is all possible without the initial input node.
If âGeoâ isnt otherwise defined, its always the original Geo that the nodetree lies on.
My guess would be for consistency: You can add inputs to the modifier which then needs a representation in the node editor. So it would have to pop up a new input node at some point anyways. So better to have a generic input from the get go for consistency. Always there.
Maybe thats the thing that differs from houdini: How you get the nodetree on a geo. in blender its per modifier how is it in houdini? 
global nodetree?
1 Like
No, itâs the same in Houdini and Blender. You get into the geometry context and then you fiddle with nodes. I donât understand the reasoning : of course you have to wire geometry inputs and outputs, thatâs how data flow is represented. If you didnât have those connections showing, how would you know which node flows into which ?
1 Like
I think SteffenD only meant the input node itself, not all the wiring.
So no modifier in Houdini.
1 Like
Oh ok !
Well there are HDAs (Houdini digital assets) which are akin both to Blenderâs group nodes, and now to node modifiers (ie building blocks that can be reused). I can only encourage you to go and try it, the apprentice version is free.
1 Like
To bounce back on this, Blender has a base geometry not represented by nodes (the geometry which you can enter edit mode on), while Houdini doesnât, and I think this is why you need an input node at all. You can either go full-generative and use only primitives made by nodes (well, not yet you canât but⌠I imagine itâs in the works), OR use the base geometry as a starting point, which is what weâve been doing so far.
On the flipside, I donât think we should have an output node at all. Ideally Iâd like to see a tagging system where we can specify the âfinalâ node to be represented on screen, just like in Houdini. Changing the wiring just to see different effects or different parts of a node tree is gonna get old very quick, just like it is with Cycles.
1 Like
If you have output nodes, you can have multiple outputs, which can be useful for intermediate graphs. Whereas if you just tag one as final, you can only have one.
Thereâs nothing stopping you from adding multiple output nodes and just switching the active one, so you donât have to change wiring each time. This works in Cycles and Eevee too, except that those unfortunately donât understand plugging a color into the material output as shorthand for an emissive shader, so itâs kind of hampered in its helpfulness for making shaders and thatâs we all use Node Wrangler.
Well, itâs not like tagging couldnât be made to work well, but I just find the way we have now more obvious and explicit.
Hi, hereâs Geometry Nodes tutorial for my previous forest video, enjoy.
12 Likes
Ah that makes sense⌠bit like AOVs ! However, having to create yet another output node and connect it just for the purpose of visualizing the result of the node tree at that point seems overkill, but youâre right about âgeometry AOVsâ, itâs a pretty good idea. I can imagine pulling this data from another objectâs node tree, or use it as coordinates inside a shaderâŚ
Oh! So, now I realize that we were always talking only of the first geometry input in the nodetree 
So @rbx775 is right.
I wouldnât be against ignoring this and let the âmodifiedâ objectâ geometry feed by default any unconnected input geometry node. More or less as it happens when shading, were image textures nodes take UV by default, while procedurals take âGeneratedâ without having to plug any Texture coordinate node.
So how would you go about setting it to act in the non-default way? What if you just want to disconnect something for a moment to plug in something else? Would you have the graph recalculate based on the default geometry in that case, giving unexpected results and possibly crashing blender from a memory spike? Seems like more trouble than itâs worth considering all this gets you is maybe a second spent adding the input node.