Probably an object input node or the result of some other node tree, who knows, possibilities are endless 
Itās clear to me that we need loops, Iām thinking in some scatter things, but we need loops to modify each instance (unless we already have loops).
But there is no object input node. Thereās just object info, and that doesnāt have an orange output.
And yeah, iteration of some kind is a must. Though, at the moment thereās such a big number of missing nodes that I think itās not very helpful to list any of them.
Yeah weāre just at a point where theyāre riguring out the technicals and havenāt gotten around to adding more nodes, I suppose.
About that object socket, Iām not sure. Since weāre dealing with geometry, I donāt know how useful this can be. Even for instancing, youād instead use the geometry socket from the object info node, and just type the object name into the fieldā¦
The current Empty modifier automatically creates a Geometry node tree upon adding the modifier, this is strange and I suggest it should have a ā+ Newā buttom just like material panel. For example, if you want to have two objects using the same node tree, you will end up having one extra empty node tree that does not do anything. With the ā+ Newā, you can chose to use existing ones or you can add a new one, it makes more sense that way.
The object info plug will allow users to expose this in the modifier stack. Besides the āinstancerā node will support connecting an object.
The auto-creation of geometry-node tree is by design. Extra empty node trees are removed when you re-open Blender.
In the future the node group selector can be replaced by a ātemplateā where users can duplicate it or create a new one. That said I would still by default create a new group upon creating the modifier.
couldnāt find experimental tab in preferences of the latest Geometry nodes build (Nov 14). Can any one guide me to enable geometry nodes
Oh I see. Thatās neat!
We know theyāre removed but itās still very annoying that it pollutes the list with trash until you restart. You shouldnāt have to restart Blender or reach for the purge button each time you add a modifier just to maintain a modicum of order in your file. Is there some important advantage to this design?
If there isnāt, please just make it empty by default so that itās consistent with every other selector in blender.
Hello everybody, I think the change of naming from āNodesā to āEmptyā is a little bit misleading, as doesnāt recall the editor weāre supposed to work in. As I uderstood from the last BlenderToday live, the change was done because eventually all modifiers will be nodes, and I get it, but I still think that a name more connected to the geometry nodes editor (maybe āEmpty Nodeā?) would fit better, also because the modifier icon is the same of the node data-block, not of the editor.
In my opinion:
The name Empty is a bit misleading with empty object type, maybe name it Custom or Advanced . We need something to differentiate from the other modifiers.
Yeah, Empty just doesnāt mean anything and nobody will think this is the one they want when theyāre looking for the node modifier. I had assumed that was an error with the string thatās supposed to be there. Just name it something obvious and predictable, like Nodes for example.
Sorry if this is too far ahead, but I thought Iād ask anyways. Right now the point instance node accepts an āobjectā input. Do you think in the future we would be able to use a āgeometryā input? That way we can instance things we build within the same tree and keep things fully procedural.
Also, just as some general feedback for scattering:
I agree. If you want an object input you could just use the object info node anyway! It makes a lot of sense to be able to build the geometry inside the node tree.
That should be easy enough, and I think we agreed it would make sense before.
Yes, that makes sense too. So far we havenāt needed it for any of the use cases weāre working on, so for now it will be a āfutureā thing
The density attribute should be driveable by volume output too
@HooglyBoogly I know itās early to talk about these sorts of more advanced features, but have you guys planned anything for being able to execute some sort of dynamic loops in the node trees? I ask because I havenāt yet seen any discussion about that in the developement plans, and because the loop functionality is crucially important every time I do something in Animation Nodes.
I suppose itād have to be in the designs quite early on, even just as a future target, so that it doesnāt end up being difficult/impossible to implement later on.
And to be clear, Iām not only talking about being able to modify a set of values with a single node, but speficially being able to to different operations for different parts of the set, based e.g. on the index of the loop.
In Animation Nodes there was this mess of having a loop instance node, and then the actual loop nodes separately in the same node tree, but Geometry Nodes already has the nice node group functionality, which could also be used for loops. You could ādiveā in the loop the same way you dive in a node group, which would be awesome!
Again, sorry if Iām too far ahead of myself, Geometry Nodes are just so exciting
I donāt think that node groups are appropriate for loops functionality. Node groups already have functionality of something like a function in programming. Nobody would like to create separate function just for using loops in a code.
It will take extra time for creating sockets for each parameter which should be used in the loop and for each return value. And I assume that it will require a lot of switching between the loop (group node) and base node tree. Probably something different should be invent for the loops.
Iām not sure I agree, since I think having the loops in a different āwork areaā (as in node groups) would make the node setup a lot tidier and easier to read. Loops tend to become quite complex at times, so everything that can make the main setup cleaner is welcome in my opinion.
But in any case, in however way the loops would be implemented from an UI standpoint, Iād be happy to just have them 
Maybe the node groups have to open as a āfloatingā window or in a similar way to how they open in some compositing software, that is a window inside the node window, pretty useful as everything adapts when you open it and you can maintain it open, at any point in time you can close it again and it collapses to a single node, and everything is inside a frame at all times so you can operate with it ānormallyā but itās a group, itās pretty comfortable.
Animation Nodes separation is not a good choice IMHO because itās actually a mess, I tend to have very complex loops and in the end itās uncomfortable.
This used to be how node groups worked in Blender somewhere around the 2.6 series I think. They took that out. No idea why, I rather liked it.
