Hybrid Back/Forward path tracing (aka BiDir without MIS)

[Dade]

Could not ELVC be replaced with light tracing?

Try do do a normal rendering with LIGHTCPU and check how noisy it is

[epilectrolytics]

Yes, you are right: LightCPU is a lot noisier.

Also still some kind of importance sampling would be necessary to sort different light intensities out.
Just another stupid idea

[CodeHD]

I think I'm a bit losing your point... Are you suggesting that raytracers should move towards the simulation of real camera systems, with real lenses and sensors?
Wouldn't this be computationally a lot more expensive?
The "thin lens" camera model has limitations for sure, but is very effective.

As much I see you got my point. I don’t mean to simulate real optics system. [...]

Diffraction and interferences would be pretty cool but is a completely different story. [...] (Could be something for Version 3.0 )

Actually, a benefit of simulating real lens systems could be a realistic lens flare effect
However, for this purpose, it would probably be much more computationally efficient to implement the camera by sequential ray tracing, i.e. geometric raytracing using matrix calculations.

Diffraction is just outright hopeless, at least if you want to compute general effects To give you an impression:
I currently work in a projcet to develop an instrument where the scattered light is highly diffraction limited. Naturally, we needed simulations for that.
The final simulations (that have been verified quite well experimentally) we did were made using an open source package called PROPER (http://proper-library.sourceforge.net/), which you can download for python and try out if you are interested. It was written for stellar coronagraphs, where you observe with very large focal lengths and are interested in diffraction at angles of arcseconds or below. This works quite easily. We needed to simulate for a full frame sensor and around 100mm focal length. The computation requires 500GB RAM and takes a few hours. And that wasn't even enough to simulate our full instrument, as a wider input beam diameter would mean larger angles and even more RAM ^^ (Also, one such simulations is only for one wavelength and a plane wave (i.e. infinity light, size 0). I'm not sure if you can easily do point sources or something else with this method?)
The scientist who does all this just implemented another semi-analytical method that uses less RAM, but takes longer. It has been running for 4 weeks now on 60 cores, and has not yet finished

[B.Y.O.B.]

Dade, if it's not too much work, I think it would be great if light tracing would work in RT engines.

[epilectrolytics]

Could not ELVC be replaced with light tracing?

Try do do a normal rendering with LIGHTCPU and check how noisy it is

I made a mistake in my first answer above comparing LightCPU Sobol with PathCPU Sobol and indeed light tracing was noisier.
But then I remembered that in Hybrid engine light tracing uses Metropolis Sampler and repeated the test:

To my surprise LightCPU+Metro ist faster and much less noisy than PathCPU Sobol

You may try and test how Hybrid engine with direct light (1.bounce) enabled on the light tracer together with caustics and path tracer only doing indirect light (2. and further bounces) compares with the current implementation where direct lighting is done by path tracing enhanced with single map or cache.

Here's the test file.

[Dade]

To my surprise LightCPU+Metro ist faster and much less noisy than PathCPU Sobol

"Apples Vs Oranges", compare LIGHTCPU+Metro Vs PATHCPU+Metro, like you did with LIGHTCPU+Sobol Vs PATHCPU+Sobol.

[epilectrolytics]

Yes I did that too and it is in the GIF image above:
PathCPU Sobol - LightCPU Sobol - LightCPU Metro - PathCPU Metro ...
LightCPU Metro looks much better than PathCPU Metro.

But my proposal was to render direct light in Hybrid with LightCPU + Metro instead of PathOCL + Sobol like now.

PathCPU + Sobol + Env. cache looks a bit better than LightCPU +Metro.

These tests were done with path depth 1 = direct light only.
I have rendered the scene also with normal path depth (8) and LightCPU + Metro and found that it is way faster than PathCPU or BiDir, even with indirect light. Only direct specular is missing by design.

Probably the hybrid approach has much more potential than only adding fast caustics to PathOCL.
Options for direct and indirect light could be added too.
It would not be as fast as PathOCL + PGI but faster than PathOCL alone and still unbiased.

This is not urgent and meant as a proposal for later when version 2.3 (material release) is finished.

[kintuX]

Dade, if it's not too much work, I think it would be great if light tracing would work in RT engines.

Yes, please

[epilectrolytics]

I tested several engines with path depth = 8 and 100 samples:

LightCPU performs far better in terms of noise and speed than all other engines, even BiDir, for caustics, direct and indirect light!
It only lacks display of specular bodies and lights which it cannot do by design.
I'd like to see an option for full light tracing in the new hybrid engine where the path tracer only provides those missing parts.
Like PGI light tracing seems to be a gold mine ready to improve all kinds of things with

Disturbing finds:
BiDir looks different (strange dark corners) than Hybrid, that should not be the case given both are unbiased.
PathMetro is not able to get reflective caustics which I think it should do.

[B.Y.O.B.]

But is LightCPU faster than PathOCL? I doubt it.