Geometry Nodes

The average user IMO should not be using Geo Nodes at this stage. ( Its in really early dev )

Geo Nodes is not for everybody but needs to be part of a modern DCC software, but done the blender way.

The target by V1 is to make Geo Nodes more usable for artists while still giving more lower level control to FX artists for eg. that need more complex setups. Which is at a min. is a couple of months from now.

Think of it like the Materials Tab … If you want that’s all you need to use for basic materials you don’t need to go to the shader editor, but for complex setup you will need to. But can just download shader groups and use them without knowing much about whats inside them.

This is how Geo Nodes will work but in the Modifier Stack.

1 Like

For anyone arguing whether or not Geometry Node is alpha/beta/usable/what is its audience … let me add how I see it.

Geometry node is production ready

This is a simple claim, backed by the fact that from day 1 the project was built on top of the Blender Studio needs. And it’s been used in a few scenes already for the upcoming Sprite Fright movie.

Geometry nodes is not for everyone (and won’t ever be).

Geometry nodes is designed for technical artists with interest on parametric and procedural control. It is intended as a visual tool and there are a few improvements still missing for that:

For anyone not interested (or technically inclined) to handle nodes operations there will still be ways to benefit from the system:

  • High-level shareable node groups (already possible, it will be better with the asset-browser project).
  • Node tools.

The future of geometry nodes depends on you

I’m not talking about hair, particles, collection nodes, … but exclusively about geometry nodes.

The current todo-list is roughly:

  • Volume nodes.
  • Curve nodes.
  • Material support.
  • Finish spreadsheet editor.
  • Point cloud (edit mode).

Whether or not this is tackled depends as much (if not more) on the community as it does on the core team.

Blender is an open source project and the core team has to use its time smartly and focus on strategic projects as much as possible.

That means sooner than later it will come the time when geometry nodes will be considered “finished enough”. At that time it will be up to people interested on helping the project to push it forward.

This won’t happen without the foundations being in place for the community to pick it up the development. That is in fact the current focus for the next 6-8 weeks (finishing the basis for volume, curve and material support).

26 Likes

While I agree, once more let me say, the big H is not for everyone, but that does not mean that the main workflow cannot be applied by tech artists that are not so proficient in math, and not all TD’s are math proficient as you can observe from big H TD’s, and they do very complex things.

I don’t think from the beginning that was the idea that was translated to the user base at all.

The idea was to have basic low-level building blocks that will allow basically to program complex interactions and tools or tool building blocks, then medium level nodes that will allow to assemble more complex tools and then high level nodes that will allow artists to use GN.

What you are describing here is a totally different plan TBH, I may be wrong and I may have misunderstood this from the start, but I think that’s the idea others had too.

Regarding this:

The asset browser right now has been a black box for several releases, and it’s functionality seems to be rather limited, once again to the B.A.S. needs, or it seems so, it can’t even explore under folders and it seems to be focused in local limited libraries, at least up to right now, but I have no idea what are the plans for the future.

High level nodes are not possible right now, what is possible are Node Groups, with a very low customization level, very limited functionality for the end user, that has nothing to do with high level node groups that are highly configurable and higly performant, something that has been requested not from day 1 of GN, but from day 1 of Everything Nodes projects, with Particle Nodes or Function Nodes projects included.

That you think that High Level nodes are already possible is something to be a bit worried about because it seems this won’t be evolved up to where it needs to be to be, once again, I may have missunderstood things and I’m not right in this.

6 Likes

Node groups are basically high level nodes. There are things that have been discussed to help with this, but they are already providing this functionality.

What exactly are you trying to build with geometry nodes that you are failing to? Which workarounds (if any) did you find to mitigate that?

What I mean is different kind of functionality:

  • Portability: right now there is no way to “install” a node group to be used, you have to append it, and I’m not sure how will this work with Asset Library, but if you have to have another .blend with two groups, and then you have to open the library to add those groups to your scene, and then they will appear in the menu, but then you end up with a ton of .blends with one or two node groups each, that’s not a good workflow for any studio or freelance at all, it’s a total mess and lack of organization.

  • Feature set: right now you cannot generate different things, like texture inputs, or proper booleans or expandable multiselection menus, etc… there are a ton of limitation on what you can present the user with in a node group, and what would be the layout of that group, I’m sure other users here can add more to this, but basically there is a lot of limitation on what can you present into a node group.

  • Performance: this is important, but one of the ideas planned in the past was to be able to “compile” or CJIT a node group to make it performance up to C++ levels, but right now that idea seems to be more and more far away, and when you have a complex node with several bool operations and other complex operations performance is not the best one, the same when you go with big scenes with thoushands of objects, performance can be killed in a second, and that CJIT idea was there to solve this problem, but it seems it has been put aside, at least for the time being, one of the things of the high level node groups was this one, to get a performant node.

Let me ask a question: with current node groups performance, would it be possible to write (in nodes) a proper rigid bodies simulator or will it be way more performant if it’s done in C++, if the answer is the second one, then the high level node is not there yet, because one of the targets AFAIK has always been to produce production tools that can be used by artists, and if an artist get awful performance in a big scene and it can be better in C++ then GN is a failure.

And let me stress “it’s a failure” because this happened in the past in other software with a system that was very powerful but it’s performance was nearly as bad as it’s scripting language, so in the end it was better for TD’s to write the script than to generate tools in that system, that system is now dead, and being replaced for a totally new and different one that performs like C++ while it’s fully node based, and I’m not speaking about the big H.

Finally regarding workarounds, usually it ends up in having to use old workflows with modifiers, or duplicated and collapsed objects so you cannot properly do everything in GN, but that one last thing I think is due to the fact that it still needs several things, some of them were mentioned by you in your post, not due to the system itself. But others have been mentioned here a lot, e.g.: loops

I hope I explained well what I mean with a high level node, and some of the limitations, others can say other limitations they’ve found, I’m sure @BD3D has a few :slight_smile:

13 Likes

Uh? They seem to be quite far from production ready. One indie studio that does inhouse project for no client without any clear deadline and risk of losing money and/or client changes/requirements is not representative of what most of us consider production.

The main goal in production is efficiency. Not just whether you can do something, but whether you can do it in reasonable time at reasonable quality. The time is the biggest issue with geometry nodes currently.

But anyway, what about the blue node slots? Why aren’t they on the todo list?

Right now, for me personally, the biggest obstacle is how laborious are even the most trivial things to achieve, such as my cliff generator:
https://www.youtube.com/watch?v=HzmwbYZvVuc

Instead of multiple node networks of annoying to build long snakes like this:


Where I constantly have to suck hard on my thumb to suck out names for temporary attributes, why can’t I just do something I’d do in the shader editor, and plug it in the blue nodeslot?

Instead of linear chains of attribute math nodes, why can’t I do this?


This would make things so much easier, if I could work with the fundamental data types in the same way I can in the shader editor. What’s on the bottom should be more or less equivalent of what’s on the top, yet much more readable and faster to put together. (Yes I do realized some things are wrong, such as Map Range destroying vector since it’s a float type, but shader editor doesn’t have Vector Map Range)

Now, to be perfectly clear, to avoid any confusion. I do not mean using shader node graph results in geometry nodes graph. I literally mean being able to use geometry nodes graph like I use shader nodes graphs.

The way one constantly needs to keep the names of attributes in their mind and construct the node network flow internally in their head, because the geometry nodes graph is not representative of data flow at all just causes too much mental fatigue for the process to ever be efficient. I mean at this point, why are geometry nodes even node editor, when having them as nodes is pointless? It could be just vertical stack of attribute operators. The power of node editors actually comes from the ability to use them as such. And currently, unfinished design of geometry nodes goes against that.

What I find confusing is that you are talking about geometry nodes as if the design was more or less done, and it was just missing more content. That’s scary.

17 Likes

Most of the annoying wall I hit are either performance-related (mostly because the whole tree is being evaluated constantly at each slightest update trigger) or when the data is not flexible enough (for example using points of a scatter as distance proximity for another scatter, well we can’t pass data like this, it’s not possible)

But overall it is quite an overwhelming improvement for the whole blender community so I think that calling it a “failure” is being a bit harsh :sweat_smile: the biggest problem is A people trying to compare it with Houdini (as a Houdini user myself i find this completely absurd) and B not understanding the development model they chose, it will take time until it reach maturity, there’s no hurry that’s the natural process i think :slight_smile:

6 Likes

Comparing Geo Nodes to H at this point of time is crazy unfair. H has over 25 years of development and UX experience in all things procedural. production tested, the works … GN is a couple of months old.

I feel its too early to call GN production ready at least till a decent set of nodes, Modifier Nodes, Attribute processor, Node portals, support for other objects types, Instancing from within a node group, Node groups Inputs, performance evaluation etc. currently the Node assets appear in the Shading Tab in the Asset Browser.

1 Like

True!

I’m not calling it a failure, what I’m saying is that if the performance problem is not tackled it WILL be a failure, if something has the same performance or worse performance than the existing solution, why would you change your workflow?

What I’m saying is that this already happened in other software, a super powerful node based tool was added, it was VERY VERY powerful, it was very well implemented, and it was VERY useful, with one little problem, once it was used in production with medium / big scenes performance was SO BAD that no one used it, it was not the tool or the capabilities, it was it’s poor performance.

The first problem you mentioned @BD3D has been performance, this is a very big problem.

Right now I know a person that is working in a fracture tool and he tried to implement the same he did in Python with GN, he was able to do some implementation but performance was so bad that there was no reason to do the tool with GN, that’s not good and that’s what I mean.

I’m not saying that GN is a failure, I’m saying that there is a big risk that it ends up being a failure if several basic problems are not solved, like the long snakes of nodes, that’s one big problem too as @LudvikKoutny pointed out.

7 Likes

I’m not comparing it, I wouldn’t dare to do that, what I’m saying is not about it’s present status, but about it’s future state, about the concept and pursued target, it’s not a comparison, it’s an answer to the concept explained here.

3 Likes

I don’t think Geometry Nodes are in a state where they should be called production ready, but most of my reluctance to use that term comes from the issues I have with GN graph topology and the targeted level of nodal atomicity. I think you’re underestimating the value of an attribute processor node and the topological impact it will have on even the simplest of graphs, and I think you’ll find that implementing it will shape a lot of the feedback you’ll receive.

I don’t see myself treating Geometry Nodes as production-ready without it, no matter what other features are implemented.

6 Likes

Fair enough, and I completely agree … I also appreciate any feedback from users especially with procedural experience to the GN team. It can only be better for everyone. The beauty of developing in the open ! ( yeah I know it has its pros and cons )

1 Like

I wasn’t clear on my question. What I’m interested to know is what art you are doing, if you could share.

1 Like

Oh, yes, right now mainly ArchViz, but also some VFX (space ships) that I can’t show due to NDA:

However we cannot use GN in our workflow yet, it’s faster to use other tools like Scatter Addon, or our own animation nodes based distribution tool (that uses curves) for all the scattering we have to do.
Using GN is way slower due to the fact that we have to assemble the whole distribution system instead of having some high level nodes to allow our artists to work with them, and we have very low control over the scattered objects, right now GN is kind of wild scattering, but having control over it is very hard.

(And that’s why @BD3D is working on his new Scatter Addon implementation with GN)

Not even the cobblestones road could be done with GN because there was not way to do a controlled scattering other than generate a mesh with the exact geometry we would need, and that’s easier to do with some array modifiers.

So in the end, in that scene, while it’s full of scattering, GN toolset was not useful I’m afraid, and we tried, but have to comply with production deadlines.
In fact the big stones walls was not done with GN because in the end it was not possible, I tried it and I spoke about it in BChat to see if I could find a solution, but in the end I had to move on.
(BTW in that scene, even the ceilings are distributed gravel, it’s not a texture)

P.S.: one of the first things I’m looking for is to convert our own Animation Nodes based distribution tool to GN, but we still can’t do that, we need more functionality to be able to do so in a controlled way and effective way.

7 Likes

If I understand well, the solution would the “Attribute processor”.
https://developer.blender.org/T85655
Anyway, this is hard to put in place a perfect tool, because everything is linked to geometry and removing the geometry socket might be hard to conceive.

1 Like

Could you show us your AN distribution workflow?

1 Like

It’s not a distribution workflow, I created a tool for curves based distribution, the only thing we can’t do with Scatter XD, I have a course about how to create and modify it, basically it’s a loop were we process a given amount of sampled points in a curve, and then we treat offset position, rotation based on tangent extracted from each sampled point in the curve, scale, randomisation of those values, and object or collection to instance, or collections of collections or objects, we can feed several curves or just one, it has something more I don’t remember right now.

It’s not too complex, the thing was that there was nothing that was able to efficiently distribute objects along a curve in Blender, that’s why I created that tool, but for it to work with GN I need it to support curve sampling and tangent extraction, and we don’t have curve support yet, I tried using curve geometry, however it’s not good enough and delivers some weird results (it’s not supported yet I think)

One of the interesting things of that tool is that in the end you have a bunch of standard collection instances that you can manually control, it’s not a big object or anything like that, so you can manually fix or control some positions or rotations to art direct some objects

1 Like

What would be truly awesome would be the ability to load a custom node as some kind of cdylib shared library kind of thing.

Curve support for Geo Nodes
https://developer.blender.org/D11091

Performance boosts
https://developer.blender.org/D11139
https://developer.blender.org/D11125

Should be in builds soon, maybe you can take it for a spin.

Yep, I know, I was a bit of a little pain to @HooglyBoogly regarding this hahaha

I think I’ll be able to convert the tool sooner than later :slight_smile:

Thanks for the heads up anyways! :slight_smile:

1 Like