Geometry Nodes Development Discussion

[thorn]

@SterlingRoth

I know it might seem elitist, but with great power comes great responsibilities.

You don’t sound elitist to me, no. My standard reply to other matters is often along the lines of “Go learn to do this” to very generalized Q/A. GN definitely requires the user to learn how the data works, and I’m ok with that.

What I think needs improvement is the disconnect between “here’s the feature, go” and “here’s the manual written by the math genius… go get a PHD, then maybe the documentation might make sense, good luck.”

I’m a youtube junkie, and will try for hours and days to figure out a thing, and look for a tutorial vid, before I dare ask a question on a forum… but this one in particular, for example - seems like every vid I find on GN selections starts talking about the spreadsheet and indexes, and using a position to select things. Which is something of value, but the example posted by @Xorrito above (excellent!) was literally the first time in a year of long GN study that i’ve ever seen that procedure described and demonstrated.

Until yesterday, I was not even aware this was possible. I just assumed this was something that we would be able to do one day as they continue to develop the system. (Like - when you see no one ever talking about it, you sort of decide that maybe it just can’t be done in the first place)

Everything else was “let’s select by proximity, or by material, or by position, or by angle”… holy frack, how about “let’s select by selection!?”

(So, thanks for that!)

[sozap]

@thorn

I hope you’re right. But it does get frustrating to see that geometry nodes continue to expand to be able to do more things, but more higher level things like this simply continue to be put on the category of “one day this might happen.”

Well, a lot can be said from there :
it’s true that the order of how things are put together in blender might be confusing to say the least, like we lack a bevel node and normal handling (autosmooth) for procedural modeling, which sound like a basis, and now devs works on simulations, guizmos, GN operators …

But eventually it will come together, and working the broad strokes without getting into too many details ( just like we do CG / painting) make a lot of sense when you consider the big picture.
We use blender for a reason, and if at least it’s balanced enough to be our main DCC there is no reason this has to stop. It only takes more time that we would like

Finally, are attributes something part of GN or is it a broader concept that is being developped in paralel of GN ? GN uses attributes a lot, but to me it’s more a project about how data is handled in general in blender, a big refactor if you will that will impact a lot of areas…

I think 4.0 is a kind of a milestone where we completely switch to the new system, in that matter, it sounds logical that devs focus first on finishing the refactor, fix the bugs, and finally start to think about the best way to create and interact with attributes through the UI.

Anyway, we’ll see how things goes, attribute seems super useful and verstatile, that’s something we use so much that it sounds super weird to not have a good UX around that eventually.

[Ace_Dragon]

@thorn

It would be like creating a new painting program, and for a year you keep adding brush after brush after brush, but never actually add the ability for people to paint on a canvas without some weird contortions.

This kind of thing is expected in FOSS development like it or not, because it is only within FOSS that you will have developers create a new feature and then not bother to create a UI for it until sometime in the future (much like how Microsoft, even today, does not have to worry about people migrating to Linux in droves when they have a PR disaster related to Windows).

Fun fact, Cycles has a pause/resume function for rendering, but the devs. for some reason thought it did not need a UI unless you roll your own build with it exposed, a clear example of anti-professional, old-school FOSS decision making still lurking around despite all of the progress in usability since 2.8.

[thinsoldier]

I think they are aggressively avoiding new UI until after they get a full time UI designer and UI developer. I think the person who is closest to being their UI code expert almost parted ways a few weeks ago.

[SterlingRoth]

The function is also still in flux. it’s probably better to make sure that everything is working on the backend before you invest the time in making a polished front end.

[Dangry]

@Hadriscus

Obviously the “set attribute” operator is a stub, it was made so people could actually use attributes, but it was likely made in ten minutes, without any design or UI consideration. I am certain we’ll see a set of tools to easily set/pain attributes in the future.

I also agree, it feels very unintuitive and slow to use for me. In the meanwhile, I made an addon that fixes the UI for me inspired by vertex and face gruops. It will be released as part of a much bigger addon hopfully next month

Edit - Now released: Key Ops: Toolkit

[Kologe]

@Ace_Dragon

This kind of thing is expected in FOSS development like it or not, because it is only within FOSS that you will have developers create a new feature and then not bother to create a UI for it until sometime in the future […]

Do we really need to have this kind of myth being spread and cultivated around here constantly?
Do we really need to constantly paint this picture of the Blender devs being some kind of dumb Morlocks, while the average user is accordingly an Eloi and knows it all better. Much, much better. By far.

It’s funny,- and very telling - how in one thread, users complain about things being halfbaked or unfinished, yet in others, they complain about a feature being withheld from them due to unsolved design-questions.

Next best random example I could find (no offense, @TheRedWaxPolice ):

@TheRedWaxPolice

I’m afraid make it work with multires is not the issue… it’s all about priorities, I guess…
Remember, Dobarro already had a working patch … it probably would be in master already if multires stuff was high priority…

In the former case, the devs are criticized for delivering a feature in an unpolished state, in the latter they are for withholding a feature from the users, which would be exactly that, unpolished, with answers to open design-questions pending.

greetings, Kologe

[thorn]

On first glance, that looks pretty freaking cool. Please continue.

[Hadriscus]

Nice ! I am eager to try that. Cheers

[sozap]

It’s the unsponken last rule of FOSS :
Free to use,
Free to share,
Free to modify,
Free to complain …

Anyway I agree with you, we can’t have both, and the worse in that we might not even be consistent ourselves about what should be delivered early, and what should be polished, so when it we listen to the community it’s a giant noise of contradictory complains…

[TheRedWaxPolice]

@Kologe

no offense

LOL… you don’t get the point there…

[Kologe]

@TheRedWaxPolice

LOL… you don’t get the point there…

You can have an appointment for a tailormade session of getting offended (insulted even, if you buy Premium!) by me, if you rather.
Just contact my secretary.

P.S.: The example itself wasn’t even a well-fitting one. I’m sure much better ones could be found, but one always quickly looses track of these posts.

[zeauro]

@Hadriscus

Obviously the “set attribute” operator is a stub, it was made so people could actually use attributes, but it was likely made in ten minutes, without any design or UI consideration. I am certain we’ll see a set of tools to easily set/pain attributes in the future.

Original idea was to extend Weight Paint mode, into an Attribute Edit mode.
Weight Paint Mode is a mode to set-up weight of vertex groups.

Vertex Groups are basically just float attributes in vertex domain.
Convert Attribute operator can convert attributes in vertex groups to be editable in Weight Paint mode.
So, for that data type in that domain, we have 9 brushes, a gradient tool, a sample tool and a dozen of operators in Weights menu. Plus, the tools in edit mode, relative to vertex groups.

Weight Paint mode has a part of its UI specific to vertex groups. Active vertex group has to correspond to active bone, for rigging.

For color attributes, we have Sculpt mode or Vertex Paint mode tools. But we need to convert attributes from a data type to another, to pass from one mode to another.
So, the idea evolved into an unique Paint mode, where we would have been able to store selections by having masks tools inverted.

And, then, developers announced that they would renounce to do that and keep current modes, for the moment.

So, for boolean attributes, in Edit mode, we just basically need to have a double of Ctrl G menu for Attributes list, instead of Vertex Group list, that could be sensitive to select mode.
But in an attribute paint mode, we would could also have tools similar to Face Set tools, in sculpt mode.

So, for Boolean, Float and Color attributes, we have a solid basis.

Integer attributes could benefit from being affected by Sort Elements menu.
Vector attributes could benefit from being affected by Normals menu.
But edition of those attributes are requiring a lot more tools to become intuitive.
Before reordering an index field, we have to create an original order for that field.
And who does not want a tool to paint vectors by default ?

Active attribute of the list is conditioning menus operators and tools usage.
I suppose that a mesh attributes tab, handling one list by domain and data type, will be a must-have.
At least, being able to filter Attributes list by domain or data type will be welcomed.

So to sum-up, we already have half of needed tools. But we don’t have modes able to handle several domains or data types.
So, as long as this UI issue is not solved ; we are stuck to use vertex groups and convert them. Or guess what will be better mode between Vertex Paint mode or Sculpt mode for color attributes.

[Hadriscus]

What was the last we heard of attribute paint mode ? did they scrap it, or postpone it ?

[zeauro]

Probably, several years ago.

Julien 's proposal of an unique paint mode ( only to paint color attributes and textures ) was published in May 2022.
It was clear in April, that was not a target for 2022.

Then, developers redirected people to brush management project that should solve all UI/UX issues. We had a talk by Severin at Blenderconf 2022, explaining that he did not understand what people were asking him to do.

In May 2023, devs explained that they would focus on other stuff than Paint mode for 2023.
But at same moment, a roadmap for second quarter of 2023 was published announcing Brush Assets stuff finished for June.

And Joe was fired at start of summer 2023. Since then, the module Sculpt/Texture/Paint is orphaned. And changes to it are accepted, at condition to be marginal.

Nobody has a clue to what could be done to improve attributes edition by painting. Because painting is out of their scope.

[Hadriscus]

Ok, thanks for the writeup. So in essence it’s not very clear and of course the module is orphaned. What I’m wondering is where painting fits into future geonodes. What if you want to paint a map on a generated mesh? (say a float attribute on vertices) The very same issue as with the “edit node” creeps up : this is the same as operating on individual indices, aka not really a procedural operation. But we’re not purists, we just want to get work done. So if painting on a surface really is the quickest way to get there, why should I be prevented from doing so ? What if upstream nodes change and now your painted map looks like garbage because the indices are all jumbled. This is where I think painting could become smart. Perhaps each paint stroke generates a 3d curve with painting data (pressure, color, etc) stored as attributes. Then under the hood these attributes are simply transferred to the underlying geometry, and that’s how it stays -relatively- procedural. Change the underlying topology and it still works the same. Change the underlying shape and of course your painting is invalidated -but ! the strokes are still there if you want to refit them manually.

[Romanji]

@Hadriscus

The very same issue as with the “edit node” creeps up : this is the same as operating on individual indices, aka not really a procedural operation. But we’re not purists, we just want to get work done. So if painting on a surface really is the quickest way to get there, why should I be prevented from doing so ? What if upstream nodes change and now your painted map looks like garbage because the indices are all jumbled.

Good points.
Houdini does just that. You paint a curve(mask) projection onto a mesh.
If you want to paint attribute values directly onto points of a mesh you can do just that, its a semi-destructive operation since the values are written onto the points (but you can always come back to the attribute paint node and change it).
If you change the input of the whole node tree too drastically operations like these will break and become useless.
Tough shit, happens all the time - nobody really cares as it is fast.
It’s Industry standard™.

[nickberckley (Nika Kutsniashvili)]

Dyntopo work, and theoretically color attribute support for Multires is path to that goal. They’re first step in “smart strokes”, where color/attribute is preserved when mesh is upscaled or even deformed. That can be truly revolutionary feature.

Blender, and geonode development even are I think at the point where they’re feeling impact of abandoned sculpt-paint mode, finally, and if they want to continue development they’ll have to adress that issue. Node tools for example, while amazing feature, suffers from issue that sculpt mode is so outdated it just can’t support the feature beyond simple operators. Shape keys or face sets get erased when tool is used, for starters.

Attribute Paint mode was briefly mentioned this year by Brecht in some design task, if I remember correctly, so hope is not abandoned. Studio requested 3D texture paint brush (which is in alpha) and performance improvements, Dalai created to do task for it, but nothing since. I think Studio accepted that sculpt/paint mode is simply not a priority for devs and that’s it. That was most apparent when they used addon for sculpt layers instead of asking for that feature.

[Hadriscus]

I didn’t know that and I’m not surprised Houdini would handle it this way already. It’s maximizing user input while sacrificing as little as possible of the flexibility. That’s what geonode tools should aim for…

@nickberckley

Shape keys or face sets get erased when tool is used, for starters.

Is that not geonodes being unaware of that data ? and destroying it ?

[nickberckley (Nika Kutsniashvili)]

@Hadriscus

Is that not geonodes being unaware of that data ? and destroying it ?

I’m not sure about the technical details, but my hunch for shape keys is that technically tools are like applied modifiers, and only way to reevaluate mesh with shape keys is to delete shape keys. I’m assuming to avoid that you need to port shape keys to attributes, and that’s not gonna be a priority for a long long time.