As I replied in the case this is a known (but unfortunate) limitation. You currently can only save UV maps with Store Named Attribute because there are no 2D vector sockets yet and using the group output converts it to a 3D vector (which is no longer a valid UV map).
This should probably be documented somewhere, but I don’t really know where.
Isn’t that what the manual is for ? or the release notes perhaps ? but they’re more hidden
I’m trying to find a good spot in the manual to add this to.
I had hoped the 2d vector problem would have been solved before 3.5, but I couldn’t find the time to work on it.
It wasn’t the source of the problem unfortunately. It may be separate problem, but even removing it and using Store Named Attribute still doesn’t make exported UVs work.
EDIT: I did not know/notice that Store Named Attribute has 2D Vector type (as most other nodes don’t). So it works now.
Yeah, the workflow is not ideal yet. Better than nothing, but still some small wrinkles.
There is a FLOAT2 attribute type. But sadly no FLOAT2 socket type (yet) and no way to force the type.
It gets even more confusing because in the modifier output panel it shows the current type of the attribute and not the type it will become.
I had planned to work on that. But real life got in the way.
What’s most confusing here is that I can access attribute only as Vector, and I can sample the nearest surface also only as Vector. Only Store has also Vector 2D option.
Yeah, it’s all related to only FLOAT3 vector sockets being available. Most of the time it doesn’t really matter (the 3d element just gets set to zero) but in the context of UV maps it’s a bit (haha) confusing.
I added some info to the docs. (currently under review) thanks for reminding me of this problem.
I wish the confusion was only issue. Unfortunately I could not find any better way to transfer UVs from bottom geometry after they get nuked by Remesh modifier than using sample nearest from referenced external object.
The problem is that since I can’t specify domain and Vector2D type, I have no choice and implicit domain conversion happens. This ultimately means that all UVs get merged into one big island, with distortion artifacts on their edges.
Hm, that’s kinda strange. domain conversion is not supposed to happen are you sure you store it on Corners ? (In the store node you can specify the domain)
edit: it’s probably the ‘sample nearest surface’ ndoe that does a domain conversion.
But I must admit I don’t know much about the actual GN UV handling stuff. I’ve only been busy with the storage side of things (which was quite the undertaking already).
https://projects.blender.org/attachments/64776bd0-8aa2-43c6-bd13-e965477adc88
It’s this file, the one I attached to the bug report. If you can figure out a better way, that would be a miracle.
Basically, what I want to do is following:
I have a some low poly geometry which I do UV mapping on. Then I want to remesh that geometry for displacement, and then I want to displace the mesh using the original UVs below the remesh modifier, which remesh modifier destroys.
The problems:
I just can’t find any better way. Ideal case scenario would be not using remesh modifier at all, and doing it all in GN. But the problems there are:
Right now, the way in the file is the best way, but it still suffers from the UV degradation due to that domain conversion.
It’s an interesting problem. But I’m currently too tried to really think about it. I don’t really see how Sample Nearest Surface could work without domain conversion. By nature of what it does it needs to interpolate the UVs between corners.
I would hope that with the new experimental “Mesh to SDF Volume” node this would be better. Then as far as I know the operation would be exactly the same as voxel remesh.
Even if you’re right and this is never solved, the fact that performance issues aren’t accepted on the bug tracker wouldn’t be the reason. But anyway, performance with volumes is one of our long-term goals, and at least catching up to Blender’s own voxel remesher should absolutely be possible.
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.
How can usability issues like this one ever get fixed when they are constantly rejected on bug tracker?
I’m not sure the bug tracker is the right place. But I agree completely that that button in the modifier panel should just do a copy instead of a new.
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?
Exhibit A:
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.
