[Bf-cycles] Interactive GI filtering paper / Siggraph 2014

Lukas Stockner lukas.stockner at freenet.de
Sat May 10 23:55:54 CEST 2014


Regarding BPT in Cycles, I think the problem is that in reference implementation renderers and/or toy renderers, it's quite easy to add, while for actual production systems it's way harder. The reason is that the "regular" light path integration works just as good (since that's what it was developed for), but things like special passes, features (like path-type-dependent visibility), tweaks or tricks (like Russian roulette termination) developed for Pathtracing are way harder to implement, if they're possible at all. Basically, the more advanced an integrator is, the harder it is to add "unphysical" things.
I've worked quite a lot with SmallVCM for one of my projects and from my experience, it works perfect for just calculating an image, but once you try to pull statistics or non-color passes from it, things get complicated. For example, I coded two ways in which light paths are created and wanted a pass giving the relative contributions to the image. However, since light can come from connecting light paths to the camera, connecting lights directly to the camera paths, and connecting both path types either randomly or locally (in VCM), even such a simple-looking task becomes quite a problem.
If Cycles were to get a BPT implementation, I would strongly recommend/favor going for a flexible and versatile approach like in SmallVCM, with explicit Light path types and methods for Camera-Connection, Path-Connection etc., instead of hardcoded BPT. My reason for this is that it allows to add more advanced Algorithms like VCM, PPM (with the reformulation from the VCM paper) and whatever may come in the future using the Path integral framework.


More information about the Bf-cycles mailing list