Dan Lee

tom_g
On the topic of uv channels - I've encountered an issue where CPU and XPU doesn't render the same result when mixing 2 uv channels that have different vector types. The 1st uv channel gets converted automatically in Solaris to 'st' which is a vector 2, but if you have additional uv's from sops named something else, they are likely to be a vector 3 which doesn't get converted in Solaris to vector 2. So if you have a material setup that requires mixing or combining of 2 or more uv channels, then I found the solution was to force any additional uv channels to also be a vector 2, so that texture uvs are consistent between xpu and cpu.

Hi. Please try the more recent daily build - I believe this is a bug that was addressed in 20.5.294.

This is a problem inherent in random walk-based SSS (the walk hits the internal face, and when tries to evaluate light on it, it's fully in shadow). You can reduce this type of artifacts by increasing SSS limit property (via rendergeometrysettings LOP), which allows the walk to continue from the points in shadow.

Old-fashioned diffusion approximation SSS sidesteps this issue but keep in mind it requires vex-based material and thus won't work under XPU.

Indeed there seems to be a bug currently where mantra's cryptomatte metadata isn't being written out to header when using the new OpenImageIO EXR driver (which is 20.5's default).
I'll log a bug, but in the meanwhile, you can work around this issue by setting the environment variable "HOUDINI_OIIO_EXR" to 0.