Add UDIM example and fix handling in Graph Editor

[ld-kerley]

Hoping to address #2007 - and also have some data to test while working on improving UDIM support in MaterialX.

I "borrowed" the example from here, and updated the textures a little to be able more easily differentiate the tiles.

Once I modified the textures it became clear that loading this in to MaterialXGraphEditor didn't actually load the correct images in to the correct materials. They would all end up using the fallback material, so this PR includes a small fix to address that.

[kwokcb]

Hi @ld-kerley,
I recall that UDIMs worked as is with the sample BB8 model some Siggraph's ago. It has a similar MTLX doc setup to your example. Maybe the geometry needs to be split by UDIM boundaries before-hand which is done in MaterialXView ?

[ld-kerley]

@kwokcb Do you know where I can get that BB8 UDIM example? I'm happy to test something we know already works in the graph editor - perhaps there was a code regression or perhaps my new example is subtly broken somehow.

I'm not super familiar with the graph editor code - which is why I was hoping @lfl-eholthouser would be able to take a look too.

The way the current code appears to work it calls RenderView::updateMaterials() with a nullptr here initially - which ends up meaning that materialNode will always be nullptr initially. That means we never end up assigning each of the separate UDIM tile materials here, and instead end up just assigning the fallback material here all the time.

At least thats what I think I was seeing - I do think perhaps if the UDIMs were being assigned to separate pieces of geometry - then the fallback material assignment might be correct, by conicidence, but my understanding of UDIMs is that you're allowed to use multiple tiles on a single shape - at least that how we were using them at Imageworks. Now if only we had a normative specification for UDIMS..... :)

[kwokcb]

Hi @ld-kerley,
Best to take the BB8 model offline with @jstone-lucasfilm as it's an private asset.

For the logic, MaterialXView has this option that Jonathan wrote:

I believe it needs to enabled to perform the pre-split for UDIMs to work in that viewer.
AFAIK, I don't think the graph editor does this.

For Maya, which builds h/w a texture atlas Jerry and I added code to compute UDIM scale / offset hints which is inserted into the generated shader code. Not sure how to test this out but maybe worth adding in @JGamache-autodesk on the review ?

For the code, I'd need to take a closer look as it's been a while :).

[ld-kerley]

Ahh the patch above is for the MaterialXGraphEditor - not MaterialXViewer. I didn't have any problem loading the asset in to MaterialXViewer (when using GLSL backend, MSL backend doesn't currently work).

[lfl-eholthouser]

Hi @ld-kerley ! This seems like a great fix. The initial version of the Graph Editor did not support loading additional geometry so I think UDIMs were just not taken into account originally.

You mentioned the asset working correctly in the Viewer is that without turning on split by udim?

[ld-kerley]

I hadn't changed any settings in MaterialXView - and when I load this mesh the split by UDIMs is enabled, and everything appears to render as I'd expect. Toggling this checkbox on/off does not appear to change the image at all for me .

[lfl-eholthouser]

Got it! I was just curious if that was affecting the asset at all.

[jstone-lucasfilm]

This looks very promising, thanks @ld-kerley!

Do you have a sense of why this faceting might be present on the face of the bunny model? Usually I would not expect multi-UDIM geometries to have divergent normals and tangents along their UDIM seams, and I wonder if something may have gone wrong in the split of this geometry into multiple UDIMs:

Following the suggestion above from @kwokcb, I'll ask our team whether sharing the classic BB-8 geometry from earlier SIGGRAPH presentations might be an option in 2025, as this is a great multi-UDIM asset that has been used in both production contexts and public talks:

https://materialx.org/assets/ASWF_OSD2021_MaterialX_slides_final.pdf#page=20

[jstone-lucasfilm]

Ah, I see that the bunny geometry was created by @crydalch to demonstrate a bug in this post, and the associated material was created by me to resolve the bug in this follow-up post.

As an alternative, perhaps an artist at one of our companies could put together a simple multi-UDIM example and contribute this to MaterialX? It could be as simple as three cubes with texture coordinates that fall in different UDIMs, allowing a different material to be displayed on each cube.

[jstone-lucasfilm]

@ld-kerley Would it make sense to split this into two contributions, where the rendering fix for UDIMs would be merged and included in MaterialX v1.39.2, and an artist would follow up and create a good multi-UDIM example file in the time frame of v1.39.3?

[ld-kerley]

I pushed an update with a simple cube as the example - hopefully this works for testing.

[jstone-lucasfilm]

I had a chance to test out this new work today, @ld-kerley, and it looks great to me.

As one minor suggestion, what would you think about naming the new geometric contribution cube.obj instead of udim_cube.obj?

My sense is that this cube geometry will be very useful for testing non-UDIM materials as well, and it seems more natural to have a new cube.obj that parallels the existing sphere.obj.

[JGamache-autodesk]

Best would be to modify the second UV set on the basic default sphere to have the upper hemisphere in a separate UDIM tile.
This would allow adding some UDIM tests to the rendering test suite.
Would be hard to add that to the OSL test suite since the implicit sphere does not have a second UV set. Might be interesting to add though.

[ld-kerley]

I have no objections to changing the filename if you feel strongly - I added the udim in the name to make the fact that the UVs conform to a UDIM layout more discoverable. without that, someone new to the project would have to either read the obj file directly - or wade back thru commit history or this PR.

[jstone-lucasfilm]

That's a great instinct, @ld-kerley, and I can imagine this discoverability aspect being addressed effectively by a future README.md at the root of the Geometry folder.

In addition to a description of the UV mapping of the cube, it could state the zero origin and unit diameter of our sphere, and any other useful details for future readers of the geometry examples to discover.

[ld-kerley]

Given we don't yet have that README.md and that writing documentation is challenging, is it perhaps prudent to merge this as is with the udim token in the filename. I don't feel that including that token in the filename stops someone from using this as a regular cube for other reasons.

[jstone-lucasfilm]

I'd still recommend that we simplify this filename for consistency with existing geometric assets, and we can add a GitHub Issue for the geometry folder documentation that will clarify the details for interested developers.

[jstone-lucasfilm]

This looks good to me, thanks @ld-kerley!

[jstone-lucasfilm]

I've added the new GitHub Issue as #2343, and I've marked it as a Good First Issue for a future Dev Days.