Hey @Lukas Stockner (lukasstockner97)

Testing this out on my end. In GafferCycles if I create an image_texture node but have the filename path blank, I will get an assert. My workaround is:

if(!path_exists(filename)) {
  return -1;
}

In: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/render/image.cpp$319

So that in https://developer.blender.org/diffusion/B/browse/master/intern/cycles/render/nodes.cpp$410 this doesn't get set to true on an invalid filename path.

While I have your attention, may I suggest using the <UDIM> syntax to force is_tiled to on? This is aligned with how OpenImageIO works and other renderers using OIIO adhere to this system (and I assume the TextureCache branch might also use):
https://github.com/OpenImageIO/oiio/blob/master/src/libtexture/imagecache.cpp#L300

Cheers, great work so far Lukas!

@Alex Fuller (mistaed) I can't reproduce that issue - if I set an empty filename, it just renders pink without any asserts. Can you tell me which assert you're hitting?
Regarding the <UDIM> tag: Good point, implemented in rBe4413dc.

Hi @Lukas Stockner (lukasstockner97)

I just did a clean build off of Blender master to my standalone Cycles and I can't recreate the issue now, it is pink so that's good. I am balancing the texture cache, openvdb, adaptive sampling & light-groups patch here which probably one of them introduced something weird with the udim patch which I'll try to investigate on my side (gut-feeling it was the openvdb one).

In my case it is triggering has_image to true (first slot is not -1) despite having an invalid path so it never assigns pink and thinks there's an image so it'll eventually assert in the kernel somewhere when it can't find the right INTERPOLATION_* or EXTENSION_* as they were never uploaded to the device properly.

Cheers for adding the <UDIM> tag, that'll work consistently inside of GafferCycles next to Arnold, Appleseed & 3Delight.

I just had another thought/idea which isn't necessarily UDIM-related but it might be a good feature to have. In the other renderer backends you are allowed to set the pink missing texture to a color plug. This works well as a fallback, so often in lookdev we would assign a safe texture fallback to the missing texture plug or set it to black if we don't care (like if the model/texture is WIP) or if there's an asset variant change and only some UDIMs are modified and the missing ones would just sample from the base UDIMs via the fallback plug.

In addition to this, I haven't done much testing here with Cycles UDIMs but usually a toggle to fail the render on missing UDIMs (when there are some tiles but not all tiles available based on the mesh UV requests) can be set in other renderer's image samplers, which you can turn off and show the missing texture colour instead of failing. This might go hand-in-hand with the above feature.

Cheers!

Hey Lukas,

I got a chance to test out UDIM support in GafferCycles/Standalone, and I think I've found a bit of an issue here. I noticed in the blender_shader.cpp that this is where the known tiles available are discovered eg.
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/blender/blender_shader.cpp$669

However, in the case of Cycles standalone there's no real way to give this information if all you've got is a file path, so there is an early exit made here:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/render/nodes.cpp$311

Should this use a filesystem check to see what tiles are available, or should I made something custom in GafferCycles to do something similar to what Blender is doing? I'm guessing for regular Cycles standalone that a <UDIM> path won't know/check for more than 1001 either and would need code as well to set the tiles vector.

I wanted to post it here to see if it was an oversight or by design.

Cheers