Testing wanted for the refactor-mesh-uv-map-generic branch

This branch replaces the specialized MLoopUV struct with general purpose attribute layers, a 2d vector layer and 3 associated bool layers for the various selection states.

As described in Blender Archive - developer.blender.org

builds:
Download here.

(From Blender Builds - blender.org in the branches tab)

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.

19 Likes

This link is broken.


I briefly tested the build (playing with UVs with nodes like Realize Instances, shader, exporting and importing the geometry with glTF), and found no issues so far.

Thank you for working on this!

2 Likes

Thanks for testing.

Replaced the ‘nest of links’ , as LazyDodo called it with a single clickety to the right place. (thanks LD for the tip)

Does this change or affect the UDIM tiles?

I hope not :wink:

It should affect nothing except remove the difference between UV attributes and uvmaps.

2 Likes

this looks great thanks!

some thoughts while trying this out quickly:

  • 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.
    b

  • 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… :frowning:
    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.

3 Likes

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

3 Likes

Ah! I did put in a check the other way around, but didn’t think of testing it this way.

I’ll look into it.

About the other problem, yeah you need to be careful to have the right domain+type combination to make it be uvs.

Maybe we should have some way to force the output type to be valid UVs indeed.

Oh and I now see that ‘2D vector’ is not available as output type :frowning:

What does work is store named attribute (set to 2d vector and face corner) to an already existing UV map. Sadly newly created UV maps are not picked up by the shader for some reason.

1 Like

This is true for vertex groups as well. Recently encountered this. It would not be bad to raise the issue of mutual compatibility of names of all custom data…

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.

1 Like

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.

2 Likes

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 :clap:

1 Like

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

Exporters (and shaders) will only see UVMaps that are already present on the base mesh. But using ‘store named attribute’ on an existing UVMap should work when exporting to FBX.

On the default cube writing to UVMap and exporting to FBX and re-importing that has the expected result.

Do you have a small example of a failing case?

Eventually it would be nice if the rest of the pipeline would use the uvmaps of the evaluated object instead of that of the base mesh but that’s outside of the scope of this first patch.

1 Like

A new verstion has been built:

1 Like

@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.

Now using this latest version and change the output type of UVMap into 2D Vector seem working fine in unity already. Thank you very much

1 Like

It has landed in master.

Thanks everybody for testing.

10 Likes