The much anticipated first installment of the everything nodes projects is finally integrated into Blender. This will be incorporated in the upcoming Blender 2.92, to be released in 2021.
This iteration implements the initial nodes required for the “scattering pebbles” use case. Artists will be able to set-dress their scenes by randomly placing simple assets, then tweaking a variety of parameters for full artistic control. A total of 24 nodes are available initially, and more will come.
Coming next is the support of “trees and flowers”. In this case different assets that need to co-exist in the same set will be combined. As well as scattering of full collections instead of individual objects.
To learn more check the user manual. Sample files are also available in the project page. For more details on the working process check the recent post about Geometry Nodes.
We need ‘list view’ nodes for data management (like grasshopper for Rhino) :-) Will this be implemented?
Already the second project with geometric nodes cannot be drawn due to a memory error, in the first case I thought it was an accident.
Any chances of getting geometry nodes for curves?
The User Manual link returns
Not Found (404)
Fixed, thanks. (we moved the pages around and didn’t update the links everywhere)
wish Blender considers to make texturing more powerful with more features like substance painter
1. The Point Instance node should have not (only) Object input, but a Geometry input.
2. Attributes must be separated from Geometry, and there must be only two nodes for working with attributes – GetAttribute ans SetAttribute. Both of this nodes must specify attributes’s location (where it is attaching): points, loop, polygon, 2d space, 3d space and so on. Outside that nodes attributes must be represented as usual data table, and all math operation should can work with it.
3. There mush be CommonModifier node in Geometry nodes set , for apply one if exist modifiers to a geometry.
I have a question, is this method performance intensive or actually faster than the particle hair system? My system struggles when I use meshes as hair particle. I want to develop scenes with lots of scattering but while using particles to scatter the objects, the system becomes slow and less responsive. So how does this Geometry Node feature performs in comparison to the Particle feature?
Hey guys, I’m not closely following these threads so I don’t know if this has been suggested before, but I’d personally do the switch to geometry nodes if it had these 2 modifiers: Shrinkwrap and displace
Here’s my usecase, generally when I’m doing hard surface stuff in order to create details non destructively and without surface pinching, incase of panel lines for instance, when I want to do them on mesh A I create an instance of it , mesh B, and displace it with negative strength to the depth I want, then I model the panel lines from 1 view so that they cut through both meshes, subtract mesh B from them using a boolean, then subtract them from mesh A.
With nodes I wouldn’t need an instance I can just branch off the node tree and wouldn’t have to worry about having matching modifier values since I can control where I’m branching off the tree.
also something cool that I found in the newer versions is the output vertex group in solidify modifier, which I use in conjunction with smooth modifier to fix intersecting geometry, would be great if it also had a workflow with nodes
If anyone keeps a list of essential nodes to be added in future releases, there are few (aside from those planned from modifier stack) which I think would really make the geometry editor even more powerful than it already is:
– Switch (switch between A and B inputs based on 0-1 parameter)
– Import Geometry (.abc, .fbx, …)
– Assign Material (only to parts of geometry with certain attribute value, vertex group, etc..)
– Create Vertex Group (based on attribute)
– Text Node
– UV Adjust (Transform, Rotation, Scale)
It confuses me that they all have geometry out.
PointDensity should have a locations (with an s) as output
As input field an object
PointInstances should have a locations as input
And as output it should have objects, or scatter objects.
In fact i think Point density and point instances could just as well be one node to simplify it.
And accept randomize parameters for loc/scale/rot.
Please before this gets mainstream re-evaluate the node texts.
I think we should make it more easy to use it for starters in blenders and ourselves.
For now its a nice code demonstration, but it looks still almost as code to me.
I like the direction of this development though, but wow if this gets complex what will animation nodes and particle nodes becomme, getting a bit worried.
Thank you, very useful tool, but the problem is that we do not have a terrain editor with quality materials. In summer we will have stones, trees and flowers but the ground will be like a 16-bit graphic.
I have tried geometry nodes in Blender 2.92 Alpha, and there is a problem that I am not satisfied with.
In the geometry node, there are many Attribute name functions, such as AttributeMath, AttributeRandomize. For my understanding, these functions are used to handle the array type in the Geometry structure.
But for many things that cannot be handled with one or more Attribute functions, These is no way to define a similar Attribute function to handle array types
Solution:
1. There should be a way to define a function for processing arrays.
2. Or use execution pins similar to those in Unreal Engine. These pins can define the execution direction of the function, so that the foreach function can be used to process the array
(Google Translate)
please am a beginner, can anybody help me out? i really want to learn
I hope they will let the materials show also when “Calling” 2 different objects with different materials , and not just when instanced as particles .. i don t know if i am clear… i d like to make see what i mean
In blender when I use Eevee the textures don’t show up but in Cycles they do, how do I fix this?
Hi, if you believe you found a bug please report in https://developer.blender.org
Thank you to everyone who is working on this. I have already started studying the existing features and I look forward to the incremental updates to Geometry Nodes.
Latest build (today) distributing objects using vertex weight does not show objects unless in edit or weight paint mode.
This appears to be due to plane having a subdivision surface modifier. Weird that it only doesn’t work in Object mode.
looks great! It’s very exciting to see you’re going to allow instancing of collections. Will this will allow scattering of hierarchies which themselves contain instances?
“`
– leaf
– bush
– stalk
– leaves (point cloud of leaf)
– bushes (point cloud of bush)
“`
It does already
Thank you very much for the post, I have been looking for information on this topic for a long time.
Is there any plan to be able to add this modifier to an empty?
I am thinking of cases where an empty is being used as a hook to deform a mesh object. Being able to transform the empty with nodes might prove helpful.
Having said that, I notice that even when a mesh object is used as a hook, the transform node does not have any affect. Only selecting and moving it manually.
That would be for a different kind of nodes, the ones that operate on objects/bones rather than object data. It’s going to be worked on and I assume integrate into the constraint list similarly to how geometry nodes are integrated into the modifier list.
ok
Your should help them, No moking you, I really think you are right. It is totally better in your examples than what they did.
The names can be a lot improve I think :
Example:
-Attribute Math
-Random attribute
Why inverted name ?
Solution:
-Attribute Math
-Attribut Random
This is cleaner and any future attribute name can then follow the convention Type then Function
Why this :
-Point Instance
-Point Distribute
(Type then Function) the GOOD way for some nodes and then :
-Combine XYZ
-Separate XYZ
(Fonction then Type) the reversed way ?? Lack of consistency.
XYZ is a weird name for a vector, better call a cat a cat:
Vector Combine
Vector Sperate
Naming things correctly and with great care will make Blender WAY better and easier to learn understand. Please never ignore that.
* Vector Separate
+10000000!
Completely agree.
Now is the time to get this right!
Once this gets released it will be harder or almost impossible to change it again.
It’s understandable that this looks fine with the limited scope of these two use cases … but it’s important to plan ahead to the future when we have hopefully 100 times the nodes we have now.
Really excited about this though. Geometry nodes + asset manager + Blender community will send shockwaves through this industry.
Thanks devs!
Attribute Math and Random Attribute are actually consistent : both are compound nouns. The first noun operates on a lower hierarchical level than the one after it, which means it qualifies it : Attribute Math is math but specifically on attributes, and Random Attribute means an attribute, but specifically a random one. They are ordered differently in both cases because they don’t bear the same role in the sentence, but the grammar is correct.
Now it would be nice that those nodes are stored in the same category because it’s nice to have all attribute nodes begin with “attribute”+something. For that I think the reasoning gains some more sense.
And “join geometry” for merging when the entire world of CGI all together call this merge… Is it to feel unique or because Blender people only know Blender ? Please call it Merge.
I think because the function exists in Blender since forever and has always been called join ? although it’s true other software call this merging, I think they’re just trying to keep consistent with the established lingo
Then they need to go through a global rename. It reminds me when the lights where called “lamps”, that was so ridiculous. Same-ish here.
Having new tools behaving as expected in the rest of the software is the priority. Then a second pass can always happen to rename things globally. But at any given time things then work consistently within Blender.
Another interesting example we went over recently was the Point Separate. We consider to name it Point Split, but Blender has a very clear distinction between what is a split and what is separate.
No reply nor reaction about this ?
Blender crew doesn’t care apparently about doing this properly, even during the alpha creation process, because I see no mention nowhere about renaming the nodes correctly.
Very Autodesk way too treat feedbacks (silence and doing zero).
Hi, I brought this topic for the team last week (in the #geometry-nodes channel in blender.chat). Some names (e.g., Random Attribute) changed already. Not sure if you are following the daily builds.
The Combine/Separate XYZ is a tricky one. Although I see the reasoning to change to Vector Combine/Separate, right now everywhere else in Blender it is XYZ. There are also different ways of combining/separating a vector (e.g., spherical coordinates), so XYZ is at least explicit.
Could the RGB nodes be instead universal vectors node instead ?
Color is just a vector, if Blender want solid node system to do virtually anything, the data types need to be as agonistic as possible.
The types will be implicitly converted anyway, so you can plug a color into a vector, or the other way around
Colors are color-managed and clamped at 0; there might be other differences as well
Nice) but… stones are overlapping with each other :( hopefully, tools to solve this problem will be developed in the near future
If you want physically accurate pebble-scattering, you need a physics solver, and that is already in blender.
this is possible without physics. for example, in cinema 4d has a modifier “push apart”, that pushes instances away from each other by a certain distance, preventing them from overlapping.
Indeed, no physics needs to scatter without collisions ! (just need to trace the surrounding)
I’m thinking push apart based on bounding box would be better. Hopefully not by pivot points as not all objects are the same size.
this just depends on the distribution function, they’re probably just using a random scatter rather than something like Poisson. In development its normal to produce a MVP (minimum viable product). This is used to prove the concepts work, the architecture is viable and the user experience is basicly working. Once thats done you start adding the advanced time consuming functionality.
I’m a bit worried about the given pebble example, the geometry is “joined”, meaning they are not instances, but one big mesh data? Wouldn’t that have a drastic impact on vram memory and performance?
If they are indeed instances (as any good scattering workflow should offer, so I suspect they are), then it’s a bit confusing as we used nodes called “join geometry”, implying that our result is in fact joined geometry, and not instances.
According to the manual entry of the Point Instance node:
“Output – The points with the information of what to instance.
The geometry of the instanced elements is not outputted directly. Instead it is only generated in the viewport or at rendering time.”
Since the geometry nodes modifier is on a point cloud object, all you’re joining is the point data and the objects they refer to. I do agree though, the fact those sockets and nodes use the term “Geometry” can be misleading, but it doesn’t have to immediately refer to meshes.
Indeed, I must admit it’s not intuitive at all
the nodes are generating geometry ( a set of points )
your seeing a viewport representation of the pebbles instanced with the point cloud. Its normal for point clouds to be represented as a single object in a viewport (its more efficient)
The modifier panels need a little breathing room at the top, maybe add some padding? It looks ugly.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.