Lux measurement using Irradiance feature

[Dade]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

[pro]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

Do you think it´s theoretically possible to readapt those pieces of code to output lux (somehow reusing directLight/indirectLight variables and than devide by m²) or did I totally misinterpreted this (my physics knowledge is not that strong in this topic)?

[pro]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

.IES files carry only information about visible light, so if there is no radiation in other non-visible spectrum, illuminance should be equal to irradiance in that case. I hope that's the case in LuxCore and that heuristics in irradiance feature doesn't include radiation in other specturms? If that's right, obtained "irradiance feature" output should be just multiplied by a precalculated scalar to get illuminance.

Another question that I have related to optimization - is it possible to render only irradiance pass without rendering default passes i.e. Combined aka RGB_IMAGEPIPELINE (by commenting out lines in C++ code and recompiling)? Or Irradiance feature somehow depends on calculation of those passes?

Thank you very much for your time and help!

[Dade]

Another question that I have related to optimization - is it possible to render only irradiance pass without rendering default passes i.e. Combined aka RGB_IMAGEPIPELINE (by commenting out lines in C++ code and recompiling)? Or Irradiance feature somehow depends on calculation of those passes?

Both irradiance AOV and RGB_IMAGEPIPELINE are the product of the same process so disabling the second AOV will have no tangible benefits.