Sorry for the late reply, I wanted to get further in development and give some concrete numbers. As of the current WIP build/test file on a Intel 4.20 GHz i7-7700K (not the best CPU cache but pushed to 4.40 GHz) :
You probably don’t want to instance anything on this…
Damn, that’s a lot of points. But it shouldn’t be a problem for Cycles in terms of polycounts, unless there’s an issue with generating that many instances. Maybe the new pointcloud rendering feature would be more fitting, if you wanted to render a dust cloud, for example, with volume scattering.
The point cloud rendering in cycles would absolutely be needed here since trick is to have the polygon count be zero 
. Maybe eevee could also benefit from some sort of stochastic “splat” rendering technique.
How did you manage to get those instances colored that way based on the falloff? I didn’t know that there was any way to pass color information to instances for shading as yet.
Its just different material on top and bottom
Aha, that would explain it, as the screenshot was misleading! Just checking that I hadn’t missed a recent commit, as I am really looking forward to being able to color instances.
Okay, those two default nodes. What if I delete one of them by mistake, how do I add them back?
There’s no entry in the Add menu for them.
Thought I’d throw this one up here. All the moss on trees, distribution of trees and shrubs (from Botaniq), ground matter (Graswald) and some stones and ferns (Scatter assets), as well as the building of the actual wall is handled by Geo Nodes. I did think while trying to navigate 100k+ foliage objects that it would be nice to have a viewport vs render density option like we do for particles but generally GN handled itself well!
Processing scattering systems like this in parallel is much more convenient than using separate particle systems too:
Why it’s impossible to add several connections to Join geometry node from the same socket or … it is possible? ))
Because it doesn’t make sense.
It does. The whole mesh could be copied. It anyway will be possible using several Join geometry nodes so this should be handled somehow.
Example of copying objects
Well this screenshot already does make sense, but you’re not adding several connections from the same socket anymore.
I feel like it should be legal, but indeed it doesn’t make much sense.
The example above was just about that the same mesh could be copied by Join geometry node.
This example can be more convincing that copying geometry can have sence. Even if it’s not too much what can be done now it does not mean that in the future it will be the same.
Even if this does not have sense and this functionality is about protection from senseless things then it does not help too much because the same thing is possible with several Join geometry nodes.
It’s a misuse of Join Geometry node IMO. Imagine that user wants 1000 copies of geometry(for some reason) then he’d have to have 1000 Join nodes. There’s should a dedicated node to duplicate geometry then.
In programming art it is considered good practice to do not assumptions about using of an interface. Good it or bad but if the interface allows such things they should be properly handled.
I think it should be allowed. I also tried this the other day, thinking I would just insert a transform node in between after the fact (my goal was to simply duplicate and move geometry, and it’s less work inserting a node on an existing noodle than connecting sockets by hand). Since it didn’t work I just took the longer way around.
Order of operations matters.
A nice convinience feature would be to have implicit autoconnections between a single nodegroup and the modifier input node.
