It should behave identical to stock blender for the most part, except that UVMaps become an attribute and should just work as an attribute. Writing to a float2 attribute on face corners should automatically make it available as UVmap in shaders. Geometry nodes should no longer nuke the UVMaps etc.
While I think this is (nearly) finished, please don’t use it on irreplaceable files, it’s still an Alpha version!
If people could test it and report any irregularities here that would be nice.
adding uvmap might cause a name collision if there is already an attribute named UVMap (which is not a uvmap really). newly created one should be named UVMap.001 instead imo.
Writing to a float2 attribute on face corners should automatically make it available as UVmap in shaders. Geometry nodes should no longer nuke the UVMaps etc.
writing values through the group output still remove uvs as the type has been converted to vector so they are not uvmaps anymore…
not sure if it should do some auto type conversion, or we just need a 2d vector socket. for latter its still a bit error prone since any domain / type mismatch will drop uvs silently, which is quite annoying.
Thanks for working on this. This has been one of the main show stoppers for the last year+, having to choose between keeping everything as instances or just not use geo nodes, or have to have python callbacks on export to convert attributes…
Amazing work! Super happy to see this reaching this stage
We can’t really enforce this without breaking backwards compatibility though. For UV and attributes this different. They are enforced to be different in current master I think. Or at least a warning is displayed.
There’s a warning displayed already in master in the attributes panel. I think we can hope these situations were unlikely, show an obvious warning, and require people to fix the collisions. The attribute system won’t really work in general if it’s in such an invalid state.
I just pushed a change that makes sure the name of newly created UV maps is always unique. At least when created via the ED_mesh_uv_add() function, which is what the gui uses when you add uv maps in the UVMap panel.
So… this turns out to be non-trivial to solve, because it would involve float2 sockets, which is something which is still up in the air. So for this first version of the patch outputting UVs via the group output will not be a supported workflow.
Also I found out that the UVMap node in the shader panel gets it’s list of available UVs from the base mesh, and not the evaluated mesh. So unless you apply the geonodes modifier newly created UVs won’t be visible in the shader UVmap node.
Since the patch is already huge I think it’s wiser to fix the UVmap shader node in a subsequent separate patch.
The fact that existing UVs stay available is already a huge win I think.
oh i totally missed the store named attribute node before and used group outputs to write to existing uvmaps… now it works as expected!
shaders can already lookup uvs with the attribute node as a workaround in current master so it might not be a big problem. i mainly use it for exporting and this patch really helps. e.g. the uv unwrap node added in 3.3 now finally works for exporters without needing to manually apply nodes & convert attributes
Thank you very much. I see there is some great progress on this fix. However it seem it still not work on export fbx. The uvmap become generic attribute was recognized as UVMap in face corner channel of blender. But it seem blender did not recognized it as default UV data that it should be exported for fbx. So this build still not work with procedural mesh export as fbx to unity
I don’t know if this was separate issue or should it be on this same branch
@HooglyBoogly We probably need some extra documentation on the fact that UV maps need to be 2D vectors and you can’t output it from a group (for now) and assign it to an attribute there because that converts it to a 3d vector.
I’ve noticed that confuses rather a lot of people.