[Bf-cycles] Tiled Texture Caching for Cycles
Brecht Van Lommel
brechtvanlommel at pandora.be
Sat May 6 21:38:10 CEST 2017
On Tue, May 2, 2017 at 10:02 PM, Stefan Werner <stewreo at gmail.com> wrote:
> I’ve taken a look at how OSL is doing it, and maybe their code for automatic
> derivatives could help (dual.h in the OSL includes). Having differentials
> only where necessary is probably necessary to not impact performance too much.
Yes, that's a good reference for how to compute the differentials of
any operation. I fear the only way to do this is to manually implement
multiple versions of SVM nodes though. Maybe that's acceptable if it's
only the ones commonly used for manipulating texture coordinates.
> That would require all three shaders to be run in parallel then, like a tiny
> REYES grid. Which would allow the introduction of Dx() Dy() nodes
> to get partial derivatives of any variable.
Yeah, interesting comparison to REYES. We are basically doing this for
bump mapping already, running the shader 3x, I don't think this would
be very different in implementation?
> Not until we ask the BSDF for how it treats the differentials. In my
> experience, domega_in_dx/_dy are important, and especially with
> glossy nodes that vary in roughness, the correct calculation of a ray’s
> footprint can have a big impact on performance.
Right, I was thinking we could assume a sharp reflection. This means
loading in a higher resolution texture than we could get away with,
but the impact might not be so bad since it's only for lights? There
is still some ray footprint then, and it's not really worse than e.g.
a sharp reflection from a high frequency bump map or hair.
I guess we could split light sampling so that we do sample point on
light -> evaluate BSDF -> evaluate light shader, if it's not too
complicated or slow.
More information about the Bf-cycles