Curiosity question about LuxCore development and light tracing

Discussion related to the LuxCore functionality, implementations and API.
Post Reply
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Curiosity question about LuxCore development and light tracing

Post by juangea »

Hi there.

This is mainly for Dade I imagine.

There is a discussion about BiDir and Cycles and caustics at devtalk, and I was wondering, in the case of LuxCore, how hard it was to implement something like Light Tracing, I'm not considering SDS / caustics cache, just the part of the work done by Light Tracing.

Was it a completely new algo developed by you or was it based in a paper?

Also was it something very complex, or relatively simple? (for you... for me it would be impossible XD )

Thanks!
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Curiosity question about LuxCore development and light tracing

Post by Dade »

juangea wrote: Wed Mar 03, 2021 2:26 pm There is a discussion about BiDir and Cycles and caustics at devtalk, and I was wondering, in the case of LuxCore, how hard it was to implement something like Light Tracing, I'm not considering SDS / caustics cache, just the part of the work done by Light Tracing.
LuxCore LIGHTCPU (i.e. the light tracing-only render engine for testing) requires something like 50 line of codes. However this is true because materials, light sources, cameras and film infrastructures support tracing light backward and forward.

Cycles has the code only for tracing light backward.
juangea wrote: Wed Mar 03, 2021 2:26 pm Was it a completely new algo developed by you or was it based in a paper?
It is a new algorithm developed by me but it is the result of combining standard building blocks: path tracing, light tracing, Metropolis sampler, CPU and GPU rendering. So it isn't exactly rocket science for people working in this field.

I have the feeling iRay may have done something similar but you can never know with closed source stuff.

The most interesting part is probably the CPU+GPU work setup more than combining "path tracing + (light tracing + Metropolis sampler)".

It is nearly the only case I have ever seen where heterogeneous computing do something CPU alone or GPU alone would be vary slow to do.
juangea wrote: Wed Mar 03, 2021 2:26 pm Also was it something very complex, or relatively simple? (for you... for me it would be impossible XD )
It is basically a simplified form of BiDir, I can explain it in 15 minutes to anyone who has ever written a BiDir.

However I doubt it is ever going to happen in Cycles because: you have to add the support for forward ray tracing to Cycles materials, light sources, cameras and film infrastructures. It is a lot of code: we are talking of something like duplicating the amount of code there. It is really a lot of work to do.

P.S. there also the not exactly trivial problem to find someone familiar with the following topics: path tracing, light tracing, Metropolis sampler, CPU rendering, GPU rendering and Cycles sources.
Support LuxCoreRender project with salts and bounties
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Curiosity question about LuxCore development and light tracing

Post by juangea »

Thanks a lot for this insight, it's very interesting and informative!

You helped me to understand the difficulty of implementing something like this on Cycles and I think this will make others understand to :D

Again, thanks!
Post Reply