There are different types of objects. Curves won’t support UV’s. What are normals inside a volume object?What’s the tilt of a vertex of a mesh?
If a field is made to work with a curve object, what would happen if someone applies it to a volume object? Would it crash? Or would nothing happen, with the user wondering whats going on? Would there be an error message?
A general Get- / Set- system for attributes in fields would mix everything. How does it suppose to work reliably for all types of objects?
Currently, Blender splits field attribute inputs and attribute assignment. From a technical point of view, it does fix ambiguity which might cause problems. Mixing incompatible attributes could be detected and could throw an error (instead of a Blender crash).
From a user perspective, the way the nodes are organized is not real intuitive. Currently, attribute input/output nodes for fields are scattered around different categories. At the moment, Field attribute inputs and field attribute outputs are scattered in “Input”, “Geometry”, “Curve”.
A user does want to quickly access field nodes which get/set attributes. But, it seems, he ends up digging them out, because they are scattered between other nodes. Imo, the way these nodes are organized in the menus is the weakest part of the current design.
The way field input/output nodes (output means field evaluator) are organized could be improved. Like having all the field attribute IO nodes in a special field category, perhaps subcategories according to object types.
I admit I just assumed it, since we entered bcon2. Even if it’s not exactly a feature but a re-design, it’s quite a big one, it would be a little bit odd to introduce it just now, but maybe it’s me and it’s not that much of a problem. Don’t get me wrong, I like the redesign, but I also think that some parts need more thought: the wires are quite big, and like Hans Goudey said on blender chat, they are quite distracting and attract too much eye attention away from the nodes. Also, I like the colored line under the label, but now that the labels have a desaturated color, they are less legible than before from a zoomed-out distance. My graphic design side tells me “I love this design”, but there’s also a part of me that is afraid that, as Pablo currently made it, it’s less legible and more distracting. I would prefer maybe to have this introduced in 3.1 to have more time for trying it, see what works and what not,and also see if the devs choose this to be the only way of visualizing nodes, make it an overlay, or a preference option.
I assume if you connect a field somewhere where it doesn’t belong the line will be red indicating it’s not working. It doesn’t matter if that is a “get spline radius” node on a volume or the generic attribute get node.
If you have a simple grid with UVs on it and scatter points on it, the points inherit the UV values of their birth position. Perfectly legit and very useful indeed.
If your software does not implement that kind of point cloud, useful or not: crash or error.
You mean, because of this example all point clouds nescesarly define UV’s?
I wonder why trying to find flaws in my examples, the underlying thought is not disvalidated. There are object types, and there could be incompatibilities, because they use different attributes.
yes, somehow type incompatiblies of get-attribute / set-attribute nodes need to be caught.
If general get/set attribute nodes which uses an object attribute by its name (dropdown, or custom string) could do without overhead, I am not sure about the advantage of having various input/output nodes scattered around.
If it keeps the current way, at least, I hope it will be more organized.
I don’t even understand the problem, please help me.
“My software” does not need to implement UVs on point clouds.
UVs are nothing special, they’re just another attribute (vec2, a vector with 2 components) that happens to be called “uv” and that a renderer might automatically use to project a texture on it. Voila 50.000 points with a texture applied to the uv attribute of the points
The UVs could also be called “MyFunkyAttribute”, store the same data and nothing bad would happen. You might just have to e.g. teach the renderer to use this custom attribute as a UV vector and it’ll do its job, just like before.
We all have no problem rendering and exporting position and normal passes to RGB images although they store colors, not vectors. Again, nothing bad happens. The receiving end like a compositing tool just has to know what to do with it. Otherwise they’re just strangely colored images that don’t help but don’t hurt anyone.
Just think about the hopefully near future when GN support particles: Particles are also just stupid points with attributes on them… a particle fluid sim also is just stupid points with even more attributes on them Nothing bad ever happens if you create attributes on anything. The worst that could happen is that the attribute is not understood by anything that comes after and it might cost memory and cause a bigger file size when exporting to a format that can export this attribute.
If you just export a particle fluid sim from another software and forget to delete all attributes the simulation needed (like size, mass, velocity, viscosity, color, temperature, … you name it) they’ll end up in the Alembic file and make it bigger. But on import the software that doesn’t know how to deal with attributes doesn’t crash or complain. It just ignores the attributes. Just like Blender ignored e.g. velocity vectors on meshes for a long time.
Maybe we’re talking about different things and I’m barking up the wrong tree. I’m sure we find a solution, I’m in no way trying to “invalidate your thoughts”, and attributes are our friends
I think the advantage is you save clicks to set up the node (even though some things can be automated), and the UI can be more optimized for the task.
For a new user, it will also be more obvious to find the position node than to realize that they can use the get attribute node for that, so it eases the learning curve a little.
On the other hand doing everything with set/get also has advantages, since it’s only 1 thing you have to learn and then you can reuse that everywhere. It would also clear up the menu big time.
The funny thing is that 90% of the time I see people adding nodes (to the Shader Editor, the Compositor and now GN) I don’t see them crawling through the “Add” menu but using the fuzzy search
Same would work with attributes… ALL of them, even custom ones. All with a single node.
Mh … we do have “Set Position”. It already gives kind of naming convention. (future nodes could be … “Set UV”, “Set Normal”, “Set Attribute By Name”, etc)
Searching for “Set” would show these nodes in no time.
A naming convention for attribute input nodes would be nice. With a “Get” at the beginning, for fuzzy search.
Index → Get Index
Position → Get Position
Normal → Get Normal
Curve Tangent → Get Curve Tangent
and so on. If one searches “Get”, he will see them all.
Yes, but someone who is looking for “Get Position” could also just type “Pos” into a “Get Attribute” node and a result list would pop up, very likely to show “Position” on top (except you already have defined tons of attributes containing “pos” )
I don’t really care about the “Add” menu getting all filled up with stuff as I use the search all the time. I just think about the future where A LOT of attributes will surface when particles and simulations and other stuff is added to nodes. This might actually scare people a lot more than having to learn some basic terms which are more than sufficient when you start using nodes.
I really think it’s a serious workflow issue all the steps involved to input an attribute name. The first time I saw, I just thought it was a workaround on the fields migration phase, not a finished design workflow.
Is there any reason why we can’t type attributes names directly under a node?
The ideal would be that the editor would be type aware, and not let you connect mismatched types. Good feedback on why something would not connect would be important. A red line is not helpful if it doesn’t tell you why.
For example, you could not a connect a field that depends on UVs to a node that is already connected to geometry that lacks it. If you connected the field first you could not connect the geometry.
One of the theoretical advantages of editor constrained coding is that it is possible to make that type of error impossible to do. A message should appear saying “geometry lacks UV attribute”, or “Field requires geometry to have UV attribute”.
A general get set attributes system would not have to mix everything in that case, provided you did things in the correct order. If you connected a general get field node to a node that already had geometry connected to it, you could constrain the possible selections to only those attributes that are of the correct type and exist. Rather than allowing arbitrary input, you get a searchable drop down of valid inputs.
Completely agree the organisation needs work. Being able to search and/or filter based on input/output type do most of the work I think though. I would love to be able to place a ‘blank’ node, connect inputs and outputs, and then select from a selection ordered by how well they would fit. Even if you don’t know what a node is called, knowing you want a node that turns these things into that, most of the time there will only be a few possible. “I want something that fits here” is a much more descriptive criteria for a computer to search by than name.
There is lots of potential for making it crash resistant and user friendly, probably more than with conventional coding. It is a lot of work to set up a good type inference system though, so don’t expect it soon, even if it is the goal.
I prefer old node design too.New one is cool but distracting and not useful. So it should also be optional and tweakable from preferences or overlay to add colored links or darkening header and adding bright colored line under node name. I also agree that current node bright header colors are important and usefull, thick headers are the way I understand nodes from distance and readability of text was never too hard as its claimed. The colors can be changed from theme to make it more readable. I dont often read node names and I always look at nodes inputs and thick header color usually. I like thick bright header instead of bright colored line under node name. I hope it doesnt be on 3.0 or I will find a way to revert it back by creating my own build. I love the current node design and I think they should be overlay or preference for that fancy design things like ‘‘use the thick header like old design’’ ‘‘use the neon colored line/strip under node name’’ so people can choose or I will make my own build to have old node design… I think thick bright header color is useful, when node is collapsed to small form, its bricght,colorful thick and gives idea about nodes from far without trying to read names.
Sorry but I don’t agree. While refreshments are indeed important after a certain number of releases, they should always aim to improve, facilitate and make the user experience better/easier than before, changing just for the sake of changing it’s not a good approach in my opinion, regardless of how many new people could bring to the software.
This is exactly the type of approach that we should avoid: only because Blender has a number of releases in a year which is doubled (or tripled) compared to other software, we can’t rely on “oh, we can fix this in the next release”. We should instead give to any feature/change its right time to develop, test and gather feedback, and if even after that there are still some quirks that could be improved, but there’s a solid base where the majority agrees on, we can use next releases to improve it. But just putting something in master at the last minute, with not enough feedback and tryouts, stick for some months with it until change it completely in the next release it’s too messy for me.
In my opinion, it’s not a matter of old design vs new design.
I like the Field concept better, but without attributes the UX was better before. It can be condensed to:
Fields < Attributes < Fields + Attributes
I think the user feedback is already quite clear, and hopefully that matters in a community-driven software.
But if we’re missing important factors it would be nice to have a dialogue and discuss about it.
