I wonder if the UVs issue will be solved once more attributes are moved into the new generic attributes system? And if so, what is the plan to include UVs?
I’ve experienced this as well with a mesh object that contains geonodes modifier(s) and then trying to use is as a base mesh for tessellation with the Tissue addon, with the option to set the rotation UV.
It didn’t work, because no matter what, the UV from geonodes is somehow not the default UV of the object and I found that, for example in a shader graph, I need to explicitly specify the name of the UV map that’s coming from the geonodes tree in order for the shader to pick it up.
Tissue can only work with a default UV map - as I imagine the the exporters, and it can’t handle yet an attribute that it should use as a UV with a name that needs to be explicitly specified.
You can have a default UV map generated by GN by overwriting a default UV map already present on the base object.
I tried creating a system where the first UV named map created in GN was set as the default one if there was no default map yet, but it was quite an ugly hack codewise. And as the plan is to change the way ‘default UVs’ works in the near future(1) I decided not to put that in. It alos had the problem that when creating multiple named UV maps it was impossible to define which one GN would decide to treat as ‘the first one’. SO that wasn’t to good either. It would have been nice to have this sorted out before 3.5, but real life got in the way and I couldn’t find the time to implement this in a nice way.
(1) as far as I know the plan is to do something similar to color attributes, where the default layer is stored by name instead of the clumsy system used for CustomData layers.
Then what is the right place? That’s my point. It’s definitely not right click select. Minor usability improvement request just completely die there. I mean absolutely die, immediately after posting. And the developers almost never visit that site, from the large part due to how poorly the data there is organized and displayed.
UI/UX fixes and improvements are not new feature requests. They aren’t technically bugs either, if you use pedantic definition of a bug. Blender’s biggest group of issues right now (in past few years) is neither bugs nor lack of new features. It’s usability issues. So we are in a paradoxical situation where Blender has no system of reporting the largest group of issues which impede its user experience and adoption.
That’s absolutely true. The closest thing the userbase got to a “UX issue reporting place” is this forum. And to even get started it needed a thread like Blender UI paper cuts to be officially created by a team member (William).
Maybe opening the bug tracker to UX improvements, under a specific tag and marked as non-blocking as to not impede other work, could be considered?
Yeah, these sorts of issues would have to be tracked separately. Makes it much easier to report if you know they end up being listed somewhere where they can be found easily (unlike RCS). But this isn’t the topic to discuss that and the one that was opened for this was closed already.
Does anyone find the Viewer node workflow kinda clunky and frustrating? Every time I use viewer I immediately get confused about the flow of my node tree because now the outputs branch into some random node floating about making everything messy.
Wouldn’t it make sense to delete the viewer node and replace it by being able to “focus” nodes like in any other normal node based software? Instead of Ctrl+Shift clicking a node to spawn a a messy, floating viewer node, you could simply Ctrl+Shift click any socket, and when done so, the socket pin would turn into a bit larger, highlighted eye icon.
A bit crappy mockup, but you get the idea (the previewed sockets could possibly have constant screen space size so they don’t get lost when zoomed out):
You could always have only one Geometry socket and one Attribute/Field socket set to preview at a time (in the same way the Viewer node works now). Ctrl+Shift clicking a socket which is being already previewed would remove the preview state, and Ctrl+Shift clicking into an empty space would remove all previews (both geometry and attribute at once, if they are active).
This way the user would not have to make a choice between previewing the node tree along any point and making the node tree appear confusing.
EDIT:
Here’s a bit more refined mockup. Still not sure about it but it’s a bit better than the previous one as it doesn’t overlap the text. Fixing that overlap would otherwise mean adding odd padding to the right of the node frame.
This concept uses only half of the eye icon and uses the original socket shape as the “iris” of the eye:
One more better mockup, because the one above wouldn’t look that great if two sockets right next to each other were being previewed (one geometry and one attribute)
Yeah I agree so much, especially when you have big wide node groups you press ctrl + shift + click and the viewer is so far away so you unzoom and the zoom to find it and etc etc, very clunky workflow sometimes i just to quickly preview the node and I would love to preview it without a new node, I think this was even discussed when implementing the viewer to GN.
Did a quick mockup how it could look, and the eye viewer icon could simply be added into overlays in case you want to turn it off
I do not think the eye icon in the node header would work, because nodes can have multiple outputs. User needs to be aware which specific socket output they are previewing. If the icon was in the header, the only information user would have is “it’s some of them”. You also would not know if you are previewing a geometry or an attribute on a given node.
In your example above, the icon in the node header would make it unclear whether you are previewing Geometry socket, Curves socket or the Surface Normal attribute socket. (Or possibly one of the Geometry sockets and also the Surface Normal attribute socket).
Yea that was my initial reaction to the viewer node as well. However in practice I am absolutely not bothered by it, since it’s quite obvious whether or not it’s active and what it’s connected to. I wish it were smarter in the sense that it could detect the data type it’s connected to automatically, but that’s about it.
Now that I’m thinking I think combining the eye on the node and on the socket is a good compromise, so you could just ctrl + shift + click on the node many time to cycle through the socket while you can easy toggle between the viewer.
When I Ctrl+Shift click to preview a node, the viewer just pops up at random near place. When I start previewing other nodes further down the tree, it’s often ugly when the preview node link just goes backwards because I didn’t “take the preview node with me” when I panned the view:
The only way to make this less ugly is to place the Preview node at the very end next to the Group Output node, but then most of the time, it’s out of the view:
This means it can not be toggled easily using the eye icon. And it also means that when you want to add a new node, you are not sure if you are adding it to the viewer path or the group output path:
The only way to alleviate both of these issues is to be constantly dragging the preview node around, taking it manually with you wherever you pan and zoom your view.
When you have a node with multiple output sockets, with the viewer node, you can’t just click a socket you want to preview. You need to be annoyingly, repeatedly Ctrl+Shift clicking the same node until you cycle to the right output.
Having Ctrl+Shift clickable the sockets themselves and not having and Viewer node that has physically visible node links would be improvement in both these scenarios.
