Attributes Sockets and Geometry Nodes 2.0 [Proposal]

Great proposal with the latest examples! Im only missing an “interpolation method” dropdown (or something similar) in the set attribute node and the nodes that interpolates new geo (subdivide, resample). If the attribute list and the geometry doesnt have the same amount of data, we could control a bit better the data flow in our geometry.
ie: If i subdivide a line, but previously i created a boolean “tip” attribute in it when it was only 2 points, i will loss that “selection” if i have no control over how the attributes are mapped again to the geometry.

Thanks for all what you are doing! You are creating something so powerfull… :slight_smile:

A little thing i did yesterday trunk+roots. Its much much faster, but you know, remesh and eevee :stuck_out_tongue:


GN, as any generative tool, is also limited with creative/artwork design workflows by its scope.

Artwork is indefinite by its nature, to create decent artwork you can use whatever generative tool (GN, Sverchok, Grasshopper, Dynamo), you can to not to use computer at all (there are a lot of known cases), so there is always “you can use”, but there is never “you have to use”.
Artwork tools can be evolved infinitely in infinitely many ways - no matter how much artwork is improved, there will be always a space for even more improvements.

So all of them are always just proof of concepts, that are formalized at some point.
There is no bedrock here.

Just as Sverchok was developed, collecting all possible concepts and realizations in order to reconcile and redesign them later, when the critical mass was reached.
That strategy works for addons.

I think you’re doing a great job. Thanks!

However, I would like to ask @dfelinto , from a user and training maker POV, how much will be lost with the future direction of the Geometry Nodes. I’m afraid of creating training if the workflow can or will change in the near future. Can you give a clear statement about how the currect knowledge will translate to Geometry Nodes 2.0?

Why would you create training for early alpha version? O_o


I’m talking about the current 2.93 nodes.

Oh, right, yeah. I almost forgot they are in 2.93 given how primitive state they are in. I am still perplexed they were actually called production ready in 2.92 :expressionless:

I hope that the new version will make it easier for me to track and define attributes. There are too many nodes and too confusing. Once more than 30 nodes find and modify the node tree is a huge problem (even if the frame is added, how uncomfortable it is when I try to overlap 2 frames)

In my opinion, both methods are good (although they have something common). The design of field reduces the difficulty of people tracking attributes, and the scheme of getting atttribute makes certain things clearer. I think we need to do the subtraction first, and then do the addition.

The essence of the node tree is to make things simpler rather than more complicated. I prefer the attribute processor because it separates two different levels of things(It is a best design first , a simliar design to Hou’s design second). For most users who do not have a programming mindset, this seems easier to understand. When I am at level a, I don’t need to worry about things at level b (I don’t need to spend more energy to remember what attributes I put in place)

I created a new proposal that I consider an evolution in relation to this one: Expandable Geometry Socket [Proposal]

I will create a new post as well for anyone that wants more information regarding handling old files and documentation.

1 Like

I wrote a complete post on that:


Thanks for the post. It’s all fair enough. I hope to help testing and sharing feedback! :slight_smile:

1 Like

It’s starting to get really demotivating to read for the N’th time, that benchmark for the GN production readiness is something as trivial and as arbitrary as a non-commercial studio which the workflow has been tailored specifically to using it on one non commercial project, and one no name studio having used it for an indie student level short movie.

Instead of admitting that calling GN production ready in 2.9x versions was a mistake, doubling down on it with phrases like “This is the definition of production-ready I’m abiding to.”

It shows significant level of detachment from what the real, high end production scenarios require. After all, if it was really the case and GN was production ready, we would not have to read posts about “Disruptive Changes” and juggle between two significant overhaul proposals, both of which fundamentally change how already supposedly “production ready” geometry nodes work.

I’d say majority of us are unhappy with the current state of GN, but we are happy about its future potential. That’s what keeps the atmosphere positive. Hearing that GN are already considered production ready completely wrecks that positivity because it sounds like goes against the idea of significant changes geometry nodes need to actually become production ready.

1 Like

Simmer down, it’s only a matter of semantics… I never saw Dalai or anyone else wave away feedback from users who stress-tested the system harder than the Blender Studio did, quite the opposite in fact. Maybe “production-driven” would be more accurate ? but then again I don’t see how calling it this or that is an actual problem.


Well, I do. Production ready is widely used term for “can be relied on”, which is certainly not the case, not even for the initial scattering use case, with issues like these still being around: ⚓ T85962 Many Nodes (Join geometry, Boolean, Object Info?) and realizing instances remove UVs (output float2, not MLoopUV).

Many people who aren’t exactly Blender forum(s) lurkers who learn that Blender has Geometry Nodes that are production ready and useful for instancing will probably sooner or later run into a case where they want to, in some way, modify the instanced geometry after it’s been placed. It doesn’t get much more basic than that. If even something as simple doesn’t work properly, then I hardly see how calling it production ready is appropriate.

I’ve tried to use GN several times on some of the production ready tasks, and I always failed.

More specifically:

I tried to use them to distribute branches on a tree trunk mesh. I failed because I could not drive the width of branch base with the weight map from the tree trunk mesh without destroying UVs on the branches.

I tried to utilize GN’s Attribute Texture node to create simple triplanar displacement modifier. I failed because despite doing my best to use as few nodes as possible, the mesh performance was so poor that it was not worth it compared to legacy modifiers.

Production Ready implies at the very least reliability for the feature set that’s already there, but the reality is far from that yet.

And all it takes to turn this all around is to stop claiming production readiness and just say it’s experimental, which is a lot more appropriate for the current state of things.

It is,
it’s not fair for blender to claim this when directly competing with other software.
it’s also completely misleading with people who are professionals working in the VFX industry.
there’s “ready” in “production-ready”.Meaning that it is a mature technology ready for mass adoption.

Saying that 2.92 geonode is production-ready would be similar to an architect saying that his house is ready for people to settle-in while there’s still massive work/rework being done. It do not make any sense Imo and wouldn’t be fair in the housing market to say such. If the house wouldn’t be given for free this semantic misintepretation would be taken very seriously.

at least that’s my interpretation of things of course

beware this is off topic,
perhaps we shall create dedicated topic for this subject

or perhaps a moderator could split it into another topic @moderators


There is a certain difference between something that can be used in production and production-ready terms.

In practice is incredibly hard to create something completely useless or something completely useful.
Industry already is full of solutions that can be used somehow.

1 Like

Yes, exactly. Many people use experimental features in production. That’s fine. After all, brave folks who use it in production to find bugs and workflow issues is how the feature eventually becomes production ready.

The only difference here is it that not calling it production ready doesn’t imply it can be relied on, which can cause lots of issues to lots of people, and can end up costing time and money. Occasionally even failed jobs.

They expected it to be better than it actually was. That was clearly a mistake and I am sure they are going to be more careful in the future with major new functionality, e.g. by having a few iterations through official releases before calling it production ready.
It is unfortunate, but mistakes happen. The line where something is considered ready is surprisingly difficult to spot. On one side we have the situation we are currently in, on the other side, there are overengineered solutions where it is not unlikely they don’t meet the production requirements.

@LudvikKoutny You are so right! You should get your money back from Ton personally.
Can we now go on discussing the proposal please?

1 Like

Hi everyone. I got enough feedback on the proposal itself. And now this is going off topic. Since I have already another iteration for the design, I will close this for now.

Thanks everyone for the feedback in the proposal.