Geometry nodes can still be improved for 4 weeks in bcon2, and if it’s still not good enough by then it can be disabled and moved to 2.93.
9 Likes
It does seem to me that the point instance node is not very well named. The first few times I tried geometry nodes, I thought that it was going to instance points themselves. Wouldn’t it be better named as mesh instance or object instance? Or even “instance to points”, though that might be too long or sound like a certain other software “copy to points” node 
Presumably there will be functionality to instance to face normals and edges in the future. Having one node called “object instance” with a dropdown menu for the various options (point, face, edge) would save needing 3 separate nodes.
6 Likes
bug report?
I tried to do billboards scattering and distance-based LOD tonight.
It seem that attr nodes don’t like to be separate in a multi-path data-flow.
not sure why. The second path is not even connected to anything
for now it’s only possible to do it with a single dataflow of attr operation, as soon as i try to separate the attr in multiple flow, it crash and doesn’t display anything / display inaccurate attr values.
Note that the particles are flickering, because the density attr is sometimes going over 1 and there’s no way to clamp values. normally vg operations are limited between 0 and 1 floats, so attr clamping & attr normalization would be a cool addition to the workflow if we are working with vg’s.
*edit, the node set up is wrong in the last screenshot, I did something similar but not like this. i think I uploaded the wrong screenshot
4 Likes
Hello!
I tried something similar substracting attributes and it only worked after duplicating the object info node and connecting it to the other branch. Looks like a bug to me, we should be able to reuse the geometry info from the same node.
I also noticed we can’t change the seed in the points distribute node, so the pebbles in their example appear in the same locations
1 Like
Hello Everyone.
Great work,
i was wondering if it will be possible to use attr to mask out foreign point clouds, not distributed by the distribute node, because so far the masks seem to be only available within this node?
Let say you use the geometry vertices to distribute points, or even import foreign points from let say Houdini, and want to use native blender attr from another mesh to masks points, would it be possible?
Being forced to use the distribute points node might be a bit restrictive, we might want a masking solution that could work with foreign points?
Let say a attr density mask that would mask points by projecting on Z axis? or by attr proximity, similar to what is already existing with weight proximity or weight data-transger?
Note that the particles are flickering, because the density attr is sometimes going over 1 and there’s no way to clamp values. normally vg operations are limited between 0 and 1 floats, so attr clamping & attr normalization would be a cool addition to the workflow if we are working with vg’s.
Here is an example that illustrates the problem of attr going beyond 0-1 limitation. is see devs talking about that in the chat.
“Limiting the density” in the point distribute node is not a working solution if the calculation before is already affected, a standalone attr clamp is needed
So basically we created a area where weight are at -2 values, and it cannot be fixed by just adjusting the input in the density attribute mask.
1 Like
Maybe a Map Range would do the work? (bold assumption)
A simple “remove facemaps” would be really helpfull.
Quick question, every how much time will Master commits from Geometry Nodes branch happen? if there is a fixed time span, maybe there is not.
Hi guys, great work to everyone involved, I’ve been waiting for this forever!
Just a quick suggestion here: could we have outputs for every socket so that we can easily share values across the graph? I realize this is something that could be done for every node editor in Blender so I guess there’s a reason we don’t have it but I still wanted to bring that up since it’s very useful.
Also, I agree with the consistency/naming suggestions I’ve read. ‘XYZ’ and ‘RGB’ could be written as ‘Vector’ and ‘Color’ and their nodes should share the same nomenclature (‘Separate XYZ’ and ‘Vector Math’ is a good example of that). Sticking to the ‘industry standards’ for nodes names would be good too: ‘Join Geometry’ and ‘Point Instance’ are called ‘Merge’ and ‘Scatter’ everywhere. Anything that makes transitioning to Blender easier is welcome.
Cheers and congrats again!
2 Likes
Because that would be very contra-productive for readability.
You would have to trace through every node to understand where values originally came from.
On the contrary to how it is now: just wire it directly and independently.
Imagine reading a nodetree you imported from someone else.
Hell to comprehend its origin for a big nodetree.
Reroute sockets help to clean up wiring, if thats your concern. 
2 Likes
Hello there!
I’ve been playing with procedural modeling nodes a bit and I came across some difficulties when it comes to transform a mesh from a specific point.
So, I come up with a simple design that gather two things :
- A checkbox to limit the transform node to the origin (just like the checkbox in the “options” dropdown in edit mode).
- Some other checkboxes in order to convert individually each input from vector to floating point values.
It could be useful to avoid multiplication of nodes in the graph to reach one axe instead of all of them like this :
Here is the mockup :
Anyway, keep up the good work! 
I really agree with the vector/float thing. We should be able to connect a vector OR individual floats to these.
However, I think your first idea hits a conceptual wall : there is no “origin” in geometry nodes because we only manipulate object data there… the actual transforms of the object are untouched. I’m not saying there is no need to control the transformation origin (you’re perfectly right, I encountered that limitation myself), but I think that would be best done with another triplet of coordinates, or a matrix socket.
Some other checkboxes in order to convert individually each input from vector to floating point
I really agree with the vector/float
All of this just to skip the usage of a separate XYZ?
1 Like
On a pure UI-related note, now that we have so many colors to remember, can we have a little legend somewhere in the UI? Or else perhaps we can have useful tooltips on nodes and their individual input/output sockets?
1 Like
I’ve been working in a major French VFX company for 4 years. They have their own 3D software suit with a custom and very powerful node system. When you have production constraints, no one cares about “readability”. You have to be fast and efficient. But yeah, I guess that makes tutorial Youtubers happy.
1 Like
As someone who’s been modelling procedurally for a while I also think that the pass through would be counter productive. It’s important to be able to read at a glance what value is controlling what data. You could very well have a single value controlling 20+ nodes and if you start just connecting to just whatever was closest passing that value then it’s going to become really slow to trace back in production. Readability does have a massive influence on speed and efficiency.
3 Likes
My favourite solution is what Sverchok does with having an expose button next to vector and matrix input socket so you can generate one auto connected if you need access to those float inputs
6 Likes
Awesome!
Ive been working for a major French game company for a couple of years starting back in 2008!
Not boasting. Just saying that pushing your points based on who you work for might not be a unique selling point on the devtalk forum.
We have some mad unicorns galloping around in here. Including you Im sure!
Rather we should discuss the pros and cons of suggestions!
You hinted at speed:
And I absolutely agree with you on that, its faster for creation when you just can tick a box and use it for the next node.
So, dunno if “grouping” was already part of your 4 years VFX curriculum. (just teasing you)
You can then save them through the startup file, so they dont get lost.
If you want to exchange the standart shift+a Menu with one that uses your groups, you can do that too!
Either through a script (examples are in the Texteditor, in “templates”).
Or conveniently with the pie menu editor Addon.
Its a full circle solution to your feature request, and fairly quickly!
And I have another point against it (also readability related):
When you add ambiguity to wiring, user wont pick one over the other, they will pick both.
And blender is used by a very broad user base, often sharing files.
When importing various node trees you’d get some that wire directly and some that wire through nodes.
I understand your point that this is easier to tame in a studio were you can slap someone on their fingers if they dont abide to guidelines!
But with blenders eco-system I would wish we keep ambiguity to a minimum to maximize readability, which is mainly a fancy word for speed. ;^)
EDIT:
I want to hug you.
One “separate XYZ” every time you need to modify one singlet in a triplet. That’s a lot of clutter ultimately. This is also why I was pushing for expressions (to compress a string of math nodes into a single line, since those are simple operations taking up a lot of space) -although in terms of compactness node groups do the trick well enough.