Cycles_path_guiding tests

[makizar]

@pixelgrip

light tracing

From a quick google search:

Add Light Tracing

This feature was relatively easy to implement in LuxCore, because it already had a bidirectional engine and all materials had the code for rendering by tracing from lights instead of the camera. However, Cycles does not have this infrastructure in place. It performs light tracing on the CPU while doing regular pathtracing on the GPU(s). The results are added. The light tracing is done on the CPU because a) the code already existed (for OpenCL it does not) and b) it is good enough, the CPU c…

and for context:

Bidir Pathtracing for cycles?

No, GPU is definitely not the issue. The main problem, as Ace already said, is that Cycles allows you to do things that just don’t work with BiDir - such as e.g. ray visibility or changing your shader depending on the incoming direction. In general, for BiDir to work, everything has to be fully symmetric, tracing the same path from the other direction has to produce the same path - but if you have e.g. the path A<->B<->C, where A is diffuse, C is glossy and B is only visible to diffuse rays, tr…

Caustics by photons in Cycles?

My understanding is light tracing / photon mapping would make sense to implement if Cycles was bi-directional. But making Cycles bi-directional would be a lot of work and the flexibility tradeoff would not be acceptable (no more light path node, …)

This is a bit old but i think it still applies. @lukasstockner97 correct me if i’m wrong.

It would still be interesting to know what could be promising next steps for Cycles. Lukas, path guiding was actually in the closing remarks of your Cycles talk 2 years ago ! We’ve come full circle

Introduction to Cycles Internals - Lukas Stockner