Just added a note about constant attributes on meshes could replace the existing per-instance values on objects and shrink the object a bit.

Just to clarify @Brecht Van Lommel (brecht) when you mention sorting for split kernels, you mean accumulating samples and sorting them to better feed shaders/kernels for SIMD/occupancy for stuff like incoherent/GI rays? Something I'm interested in also that wouldn't introduce bias afaik if done right.

Yeah I noticed this too with GafferCycles, didn't end up sending a patch in I think I just did a workaround, this is better.

• OSL support for AOV output, currently I am seeing the shader isn't compiling under OSL while debugging like it is in SVM.

Thanks Brecht!

Hey Lukas,

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.

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

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:

I can also see the potential building-blocks for robust light blockers as well here, great job @Charlie Jolly (charlie) !

If it helps @Juan Gea (juang3d), I was able to compile adaptive sampling support on the fairly latest patches of Cycles here:
https://github.com/boberfly/cycles/commit/8d378f97c2dd6c0bb21ce0f44a05637a02e5565f

Hi Brecht/Lukas,

Not sure if it might be related, but I reverted the virtual destructors for anything inheriting from ImageSlotTextureNode so that only ImageTextureNode has the new UDIM destructor update. I found that textures like environment maps weren't freeing properly which might be what you're running into, although it was asserting for me but I am building in debug mode and haven't tried a release build yet.

Just a follow-up on a potential fix:

Hey @Lukas Stockner (lukasstockner97) fantastic patch!

Just giving your patch a go for GafferCycles. I might've made a mistake on my end, but I am getting an assert in the ImageManager::remove_image(int flat_slot) function on the EnvironmentTextureNode, when it tries to get the image back from the slot number it returns a null pointer to image. I'll investigate further, but it looks like it is related to removing the destructors and relying on the ImageSlotNode destructor with this patch.

+1 for this. Currently my GafferCycles implementation needs all elements to be persistent by default, and I currently get around this by managing the scene object vectors outside of ccl::scene and making sure to clear the pointers out of Cycles and transplant them back in eg.
https://github.com/boberfly/GafferCycles/blob/master/src/GafferCycles/IECoreCyclesPreview/Renderer.cpp#L2865

I had this posted a day or two ago but I didn't understand how phabricator's differential works. I've made a basic inline comment in bvh_embree.h in which the new function needs fixing to compile properly:

I'm taking a look at this patch to test with GafferCycles but just the Cycles part, but I am seeing if I can merge it with the ImageTextureNode. From what I understand currently, to fill up the tiles you are relying on Blender to fill this up? The approach I am testing is to just let the user pass a filename with the format 'file.<udim>.tx' and then deriving the name at the SVMCompile/OSLCompile stage. Does anyone have an opinion on this? Also should there be an additional projection called 'udim' or 'mari' which works like the standard 'flat' only it explicitly tells the code to treat it as a udim mapping?

Just an update, I managed to build the latest Blender 2.80 here (I had /usr/bin/c++ & cc set to clang not gcc, doh!)

Something which would be great would be a procedural API in the same vein as Renderman and Arnold, where one can dynamically load geometry to the renderer when the renderer hits a bounding box ray hit for the first time.