Cycles Global Illumination cache
This would more be a question directly for the developers, as I'm not familiar with the internals of Cycles, or if this would add too much overhead to be useful, but I propose the following: A system that caches secondary bounces as "cache points," and then terminates rays early if they enter into the radius of one of these points.
Global illumination, especially on diffuse surfaces doesn't need to be very accurate. For example, if we have a red cube next to a white wall, it doesn't matter if the secondary bounces are 1-2cm off, it will still look almost exactly the same.
In theory, the steps would be something like this (also pictured in the diagram):
- Trace scene like normal
- Once the ray reaches a light source, back trace, and on each bounce, create a "cache point," which stores the surface color at that point. Each Cache Point has a small radius (use defined, larger radius = faster but less accurate)
- Trace scene again like normal, except on every bounce we check to see if the collision point is within the radius of a cache point. If it is, then we terminate the ray immediately and return the color of that point as if we completely traced the ray.
Again, I don't know if something like this would be viable to implement in Cycles, but I would still be curious to hear from the developers if this would be possible/yield time savings.
3 Comments
Not a dev, but I know a bit about render engines.
Firstly, Cycles is a Unidirectional Path tracer which means it only traces from the camera, never from the light sources. What you're describing as 'back trace' of rays from the light source is "Bidirectional Path Tracing"; re-architecturing Cycles to be bidirectional would be a massive job. There are other renders which do Bidir PT that work with Blender. LuxCore is one which is free and Pixar Renderman used to have a Blender addon but I think that's dead now.
Anyway the cache of lighting points you suggest here is a commonly used algorithm known as "Photon Mapping". The problem with it is the cache instantly becomes invalid if there is any animation in the scene. Even small object movements cause the light points to move a lot because small changes in the direction of a ray add up to bigger and bigger deflections the further that ray goes. Cycles is designed to be a renderer for animations so that's why it was designed as Unidirectional in the first place.
That doesn't mean you can't do animation with Bidir -- what LuxCore and Renderman do is use a dynamic cache with an algorithm called "Progressive Photon Mapping" to create the light points; then they trace rays from the camera as usual and match up camera rays with the lighting points just as you describe using a method called "Vertex Connection and Merging"; (not vertex as in a mesh, the bounce points are also called 'vertex' in this algorithm).
All the original research papers for these algorithms are online if you're interested and I suggest trying out LuxCore and the renderer Cycles is based on is PBRT which you can check out at pbrt.org
* @johnedwardcox * So photon mapping is completely impossible to do with unidirectional path tracing?
If something like this were to work, it should still provide a good boost to animated scenes though, as a per-frame cache would still allow for new rays emitted on that same frame to be terminated early.
Also they are doing something called adaptive rendering , it will be available in 2.83 which way huge leap in speed in most cases