[Bf-cycles] Tiled Texture Caching for Cycles

Stefan Werner stewreo at gmail.com
Wed Apr 26 22:28:22 CEST 2017

Hi everyone,

I’d like to tackle the challenge of adding support for texture caching to Cycles, through the means of OIIO’s TextureSystem. Eventually, that should allow us to render scenes with unreasonably large texture assets in a modest memory footprint.

I attempted this at an earlier point already, but didn’t have the time to finish it. To get any benefit whatsoever, texture lookups must use correct dsdx, dsdy, dtdx and dtdy differentials. And that is where I remember three stumbling blocks:

1) Generating the differentials. We already have dudx, dudy, dvdx and dvdy in Cycles. Thus, it’s fairly straightforward to calculate the differentials when the texture lookups are being done with the UV coordinates of the underlying geometry, provided that the UV map is not degenerate. It does however get tricky, when the texture lookup uses s,t coordinates derived by other means, for example through procedural patterns or worse, by looking them up in another texture (which again would then need a filtered lookup). Does anyone have an idea how we could reasonably derive those differentials in those cases for SVM? We could run the shader three times, once at P, then at P+dPdx and at P+dPdy (similar to how bump maps are calculated), but that would break down when texture coordinates are looked up themselves in textures.

2) Passing texture coordinates around. Since a texture lookup is now not using s, t as parameters but s, t, dsdx, dtdx, dsdx and dsdy. So the sockets would then not be float[2] but float[6]. This would either require extra input sockets on texture nodes or a new type of socket. Both methods could break existing shaders.

3) Currently, shader_setup_from_sample() sets all differentials to zero. Any texture lookups from samples (for example, textured mesh lights or background lights) would therefore happen unfiltered and have terrible performance. The only correct way out of that I can think of is to defer shader evaluation for light samples until after the full path has been constructed, which may not be easy to do, especially with the split kernel.

I’d be happy to hear your thoughts. Am I overlooking potential problems or am I missing an obvious solution?


More information about the Bf-cycles mailing list