Geometry nodes cant be used in studios due to avoidable forced repetition

Using geometry nodes to build re-usable tools for studios is an impossibility due to potential massive setup time for each use.

Every time a user uses a pre-built geometry modifier, they have to manually specify the input and output attribute names so other areas of blender or following modifiers can use the attributes created by the modifier. If you have 3 modifiers in a row each requiring 10 attributes to be specified, and then 10 members of staff need to do that for 10 different objects, you’ve got a massive amount of data entry work)

A better solution would be for the input and output attributes to default to the label name, and only use a different attribute if the user specifies one.

For example below. The first modifier uses user specified attributes (UVMap.001 and users_specified), but the second modifier will use the defaults (label name) of ‘UVMap’ and ‘Hello!’

This has the advantage of the tool working without any user setup, but still allowing them to override if they want. This guarantees that all accompanying shaders that rely on specific attributes will work without the user having to manually copy in from a list of output attribute names provided by the TD (the current necessity for this repetitive and avoidable work makes geometry nodes unusable for studios (no one wants to pay their staff to enter the same text into the same textboxes 50 times a day!))

If the default input attribute doesn’t exist on the geometry, then the parameter should revert to a single value input rather than an attribute. Output attributes should always be created if they don’t exist, and if they do exist they should be overwritten, averaged, or added to, based on user preference (maybe a dropdown beside the parameter?)

6 Likes

Why not just write a Python script to automate this?

Because what the OP is suggesting is more user-friendly. I think it should be pretty obvious.

8 Likes

I think there should be an option to set a default attribute for geo nodes with a specific name, so that once you’ve selected it once, it gets automatically found by other geo nodes modifiers

2 Likes

Yes, and that’s the same reason that was exposed as “shareabiltiy”, however is the same reason I agree… it’s not really usable in studios because artists can be all day repeating the names required for a tool to work.

I really hope we get a get/set and an internal way to handle attributes, this is a confusing design, nwhere you have to create a field with a name, and then give a name to the attribute,

Two names for the same thing in two different places (for output attributes), and for input attributes, a name that may not be connected at all with the actual geometry (if you use Object Info) and then has to be used with an attribute capture, it’s something twisted and not good at all, and can be solved with get/set named attributes nodes inside the trees.

4 Likes

another way could be to let the creator of the node tree to define a pair of value/attribute defaults, so when the user later toggles between the two methods, both of them have a predefined default “input value”, and you don’t link the input name to the attribute’s actual name, which could be limiting or inconvenient.

2 Likes

As far as I am experienced with various editor-centric game engines, I have seen this episode over and over again, where a project as it gets more complex it becomes a maintenance nightmare.

With hundreds of objects, with dozens of properties each, scattered all over the place, is impossible to keep track of things manually. More or less to forget about the dream use-case of drag and drop components and having them work seamlessly.

This is why in regard to game engines, I have abandoned editor-centric focused development once and for all. Everything should exist in json files and the process of constructing the scene should not be editor driven.

Is far better to maintain a json file with 10.000 lines if needed that can be parsed automatically in a snap, rather than going the editor-centric way that is human-labor-intensive.

In case of Blender, I have never attempted such a large scale project, but I would see lots of chances to apply the same data-driven paradigm. If this is not the exact ideal solution, at least it will have to be examined properly and popularized within the Blender ecosystem, so it becomes a rule of thumb.

Automation is definitely the way to go. That’s why you have TDs to support your artists.

A JSON format sounds good, since it is text-based and can be managed in version control. You could “import” that into Blender via an addon that uses the Python API to create the corresponding Blender objects, attributes, modifiers, what-have-you.

1 Like

Yes that would also be a nice way of doing it :+1:

Bingo, this is also why Blender should focus on USD integration into their scene hierarchy.

USD scales well with larger scenes and cases.

2 Likes

From the 2020 annual report :

"Strategic contributions to Blender can also be provided by other organizations or
teams. This is already happening. For example, NVIDIA and Tangent Animation assigned
engineers to help integrate Pixar ’s USD into Blender. "

Blender institue already stated that after the asset browser, one big project was asset source control/asset distribution bundled under the term “asset manager”.
Would love a separate topic on this - this is quite off-topic here.

Next paragraph
"Obviously it’s the Blender Foundation’s task to frequently present and discuss strategic
roadmaps for Blender, and to make sure the module teams are aligned. "
Not sure strategy communication has been done great lately.

They did provide a roadmap. I sometimes feel that information is just a bit scattered all over the place.

here’s good too:

https://developer.blender.org/project/board/121/

1 Like

the modifier stack should just be another node editor.

I stumbled upon the same issue with compositor nodes yesterday. Referenced values could work more like file paths — you specify a name of a mask or an attribute and if it’s available in the file, it will be used.

For now I find the overlap between modifiers and geonodes quite a happy accident, you have two different “API” modifier is high-level and geonodes is low-level :slight_smile: