UDIMs + ColorGrid + Cycles = FuchsiaFail?!?!?

In v4.2.1 & 4.2.2rc (same in both) I’m using a procedural ColorGrid for UV/UDIM work. In the viewports I’m using either Workbench or EEVEE, by Cycles render time I won’t need the ColorGrid so this won’t be an issue. But it still shouldn’t be happening – have I missed a setting, or is this a bug?

For this example I’ve given Suzanne a UV map with 3 UDIM tiles. I have a generated 1024x1024 ColorGrid backing UDIM tile 1001, it’s also in the material via an Image Texture node with a Texture Coordinate node forcing UV for the Vector input.

So far everything looks fine in Viewport Shading Solid using Workbench (Color = Texture), Viewport Shading Material Preview using EEVEE, and Viewport Shading Rendered using Cycles. But to do UV work on the ears in UDIM tile 1002 I need to see both the ColorGrid behind the UV mapping and on the ears in the 3D Viewport. So in the UV Editor > N-Sidebar > Image tab I’ll change Source from Generated to UDIM Tiles, at which point the ears and eyes turn something’s-missing Fuchsia in Viewport Shading Solid and Material Preview (Workbench and EEVEE), but in Viewport Shading Rendered (Cycles) everything’s Fuchsia. Once I go to UDIM Tiles > Add Tiles > Count = 2 and Generated Type = Color Grid, then I have the Color Grid showing behind all the UDIM tiles and on the eyes and ears in the 3D Viewport with either Solid or Material Preview, but in Rendered everything’s something’s-missing Fuchsia. If I change the Render Engine to EEVEE then everything looks fine in the 3D Viewport, the problem’s only happening in Cycles (both Rendered preview and F12 renders).

What am I missing?

Here’s both before and after blend files:

20240913_SuzUDIMCyc_Tests.zip (344.6 KB)

Haven’t checked the files but from what I can see the image you’re using is set as Generated in the shader node tree, it should be set as UDIM Tiles for Cycles to read all the images. I assume you’re also using just one image…?
There should be one image per UDIM tile, named with 1001, 1002, and so on so Blender can recognize them as such

2 Likes

Look at the last screenshot in my first post, in the UV Editor tiles 1001, 1002, & 1003 are set up, each filled with a blender-generated test grid (the Color Grid, details here). I’m not using three saved images ending in 1001.png, 1002.png, & 1003.png, although when I do that works fine.

Sorry, didn’t think to add a screenshot of the nodes while the problem’s happening, here:


Thanks again to @joseph for the image slider.

You can see that the Image Texture node is set to UDIM Tiles (nor has trying any of the other of the node’s options helped).

That’s the reason, as I said on my reply, Blender can’t recognize the UDIM tiles if the images are not named accordingly.
https://docs.blender.org/manual/en/latest/modeling/meshes/uv/workflows/udims.html#workflow

In your Test_001 file I just saved the images and Blender automatically added the 1001 to 1003 sufix, and after that they load just fine in Cycles.

1 Like

What you’re saying is true of external images, like png, jpg, etc. That’s not what this topic’s about. According to the Blender Manual page you linked to:

“ . . . Tiles are managed in the UDIM Tiles panel where they can have a generated image assigned to them . . . tiles can filled with a generated texture . . . ”

And there’s another page on Blender’s Generated Images, including the Color Grid. There’s nothing that says the generated images should have 1001, 1002, 1003 to be assigned to those UDIM tiles (unless they’re saved and then used as external images like in your example), there’s nothing that says Cycles alone needs this while EEVEE and Workbench don’t (let alone why).

This is low-priority for me (as I said in my first post), but if it’s a bug then I’ll try to put in a bug report. If I’m just missing the settings I should be using in Cycles then I’d appreciate it if somebody’d clue me in before I come off as more clueless than usual by reporting a “bug” that’s nothing more than my ignorance.

Opened a bug report, see here.

:beetle:

Edited to add: yep, it’s a bug: