LuxCore and the elephant in the room

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: Dade, jromang, tomb, zcott, coordinators

LuxCore and the elephant in the room

Postby Dade » Tue Oct 06, 2015 4:58 am

Introduction

There is a huge pink elephant in the room of LuxCore, no one ever talks about: spectral rendering

LuxCore is an RGB renderer and the path toward spectral rendering has not yet been set. This is my opinion on the problem.

My premise is that spectral rendering has a cost (more in term of noise than speed) and it must be an option. Something to enable if you want to increase the rendering realism at cost of rendering time. Having to pay the cost of spectral rendering all the times, even if the realism of the rendering doesn't need it, is very inefficient (i.e. like in classic Lux).

LuxCore is establishing few solid legs (i.e. rendering modes) with (BIAS)PATH for fast rendering of normal and simple scenes, while BIDIR is for accuracy and realism. It seems pretty obvious to further specialize BIDIR toward accuracy and realism and to implement there (and only there) spectral rendering.

There is a beginning of convergence in the 2 path tracers currently available (i.e. PATH and BIASPATH) and I hope to reach the point where there will only one path tracer with all the options of both PATH and BIASPATH. (RT)(BIAS)PATH(CPU/OCL) in my crazy nomenclature :lol:

Differentiating BIDIR as the more accurate and realistic rendering mode makes a lot of sense. It is going like having Arnold and Maxwell in the same envelope :shock:

The software engineering problem

This kind of solution poses some problem as both (BIAS)PATH and BIDIR share a lot of code: materials, lights, textures, etc. The shared code should be able to work both with RGBColor and SWCSpectrum. I assume that C++ templates should be the solution to this kind of problem (i.e. Matte<RGBColor> and Matte<SWCSpectrum>) however I'm not sure if there is any kind of performance impact (i.e. the compiler resolve everything statically :?: ).

Conclusion

In general it sounds like a lot of work and a long term project, I'm not sure when it is going really to happen.

P.S. BIDIR in OpenCL is another elephant we don't talk very much but it is going to happen only when NVIDIA release OpenCL v2.x drivers or it becomes irrelevant (i.e. Intel has bought the entire world).
User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: LuxCore and the elephant in the room

Postby jeanphi » Tue Oct 06, 2015 6:51 am

Hi,

I have thought about it a few times already and the best plan I have is the following.
You can keep almost all the infrastructure unchanged for spectral rendering, you just need to consider that the colour triplet is no more RGB but 3 arbitrary wavelengths of a spectrum. Then you basically only need to implement a sampling strategy when starting a ray so that you can transform from the RGB or full spectral representation to the triplet and a reconstruction algorithm to transform the triplet into an RGB colour. For the non OpenCL case it would be pretty trivial to implement a do nothing scheme (RGB rendering) and a spectral conversion scheme using derived classes, the OpenCL case might be a bit more tricky but shouldn't be impossible to handle.
The other major feature would be dispersion, but even that can be implemented into an RGB renderer, either in a dumb way (consider that RGB are 3 fixed wavelengths and choose randomly one of them) or in a more clever one (sample a wavelength and interpolate the IOR).

Jeanphi
jeanphi
Developer
 
Posts: 7943
Joined: Mon Jan 14, 2008 7:21 am

Re: LuxCore and the elephant in the room

Postby Dade » Tue Oct 06, 2015 7:41 am

jeanphi wrote:I have thought about it a few times already and the best plan I have is the following.
You can keep almost all the infrastructure unchanged for spectral rendering, you just need to consider that the colour triplet is no more RGB but 3 arbitrary wavelengths of a spectrum. Then you basically only need to implement a sampling strategy when starting a ray so that you can transform from the RGB or full spectral representation to the triplet and a reconstruction algorithm to transform the triplet into an RGB colour. For the non OpenCL case it would be pretty trivial to implement a do nothing scheme (RGB rendering) and a spectral conversion scheme using derived classes, the OpenCL case might be a bit more tricky but shouldn't be impossible to handle.
The other major feature would be dispersion, but even that can be implemented into an RGB renderer, either in a dumb way (consider that RGB are 3 fixed wavelengths and choose randomly one of them) or in a more clever one (sample a wavelength and interpolate the IOR).


Aside from 3 Vs 4 transported wavelengths (when compared to classic Lux) in SWCSpectrum, isn't there the problem of carrying around SpectrumWavelengths class ? Passing around SpectrumWavelengths is by far the most a annoying and intrusive part of spectral rendering in classic Lux.
User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: LuxCore and the elephant in the room

Postby jeanphi » Tue Oct 06, 2015 8:42 am

Dade wrote:Aside from 3 Vs 4 transported wavelengths (when compared to classic Lux) in SWCSpectrum, isn't there the problem of carrying around SpectrumWavelengths class ? Passing around SpectrumWavelengths is by far the most a annoying and intrusive part of spectral rendering in classic Lux.

I forgot to talk about it: since all data structures are currently RGB, the less intrusive way of implementing this would be to have an application wide spectrum sampling, the drawback is that it would introduce synchronization points. Otherwise we need to find ubiquitous data structures to hold the data like ray or hitpoint (or use a field in the Spectrum structure to hold a pointer to the SpectrumWavelengths, but that might be more tricky).

Jeanphi
jeanphi
Developer
 
Posts: 7943
Joined: Mon Jan 14, 2008 7:21 am

Re: LuxCore and the elephant in the room

Postby Dade » Tue Oct 06, 2015 9:06 am

jeanphi wrote:
Dade wrote:Aside from 3 Vs 4 transported wavelengths (when compared to classic Lux) in SWCSpectrum, isn't there the problem of carrying around SpectrumWavelengths class ? Passing around SpectrumWavelengths is by far the most a annoying and intrusive part of spectral rendering in classic Lux.

I forgot to talk about it: since all data structures are currently RGB, the less intrusive way of implementing this would be to have an application wide spectrum sampling, the drawback is that it would introduce synchronization points.


Emm, on my dead body :lol:

jeanphi wrote:Otherwise we need to find ubiquitous data structures to hold the data like ray or hitpoint (or use a field in the Spectrum structure to hold a pointer to the SpectrumWavelengths, but that might be more tricky).


The Sampler (there is one Sampler for each thread and a SharedSamplerData object for all threads) could be the place where SpectrumWavelengths is initialized and hold, than the HitPoint inside the BSDF could old a pointer to SpectrumWavelengths. Both Material and Texture interfaces already pass HitPoint around. However Light interface would still have to be extended.

Anyway, it looks like a reasonable amount of work and solution.
User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: LuxCore and the elephant in the room

Postby patrickwalz » Thu Oct 08, 2015 6:19 pm

We could implement SWC or Hero Wavelength Spectral Sampling as drop in replacements for RGBColor by holding the energies (as we already do in swc) and just adding one float to the Spectrum class (for the hero wavelength). The downside would be that we would no longer be storing the buckets used to speed up the SPD lookup, but it should make the implementation simple. I've been working on this in c# for my own personal project renderer and it's not too shabby.
patrickwalz
Developer
 
Posts: 106
Joined: Sun Mar 07, 2010 12:54 pm

Re: LuxCore and the elephant in the room

Postby Dade » Fri Oct 09, 2015 4:17 am

User avatar
Dade
Developer
 
Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: LuxCore and the elephant in the room

Postby jeanphi » Fri Oct 09, 2015 9:14 am


That's the technique implemented in LuxRender (without importance sampling of the spectrum, in LuxRender the spectrum is sampled uniformly). There are only 2 important values to store: the base wavelength and a flag telling if light has been dispersed or not. For efficiency it is better to store the other wavelengths so that you can easily access them.
In the SpectrumWavelengths class, w is the table holding all the wavelengths, single_w is the index of the hero wavelength in that table and single is the dispersion flag.
The other data is for fast RGB->spectrum conversion. You could eventually remove the single_w data member by having unordered wavelengths in the w table and assuming the hero wavelength is w[0].

Jeanphi
jeanphi
Developer
 
Posts: 7943
Joined: Mon Jan 14, 2008 7:21 am

Re: LuxCore and the elephant in the room

Postby Theogott » Fri Jan 15, 2016 5:25 pm

I have seen that in mitsuba Render there is "ready made code" available to render a number of spectral samples.
Currently Mitsuba uses RGB and they do not even say that this is "spectral render".
For this you have to recompile Mitsuba and tell it "how many" spectral passes it should make ... 15 or 30 is what they most often use.
Taking a look there, the "spectrasl render mitsuba" is nowhere available to download. Only those people who can compile it themselves can use it.
I'm always using the self compiled version of Mitsuba because i compile it as full spectral with SPECTRUM_SAMPLES=30

To make really good spectral render, i assume that its needed to render several rays of different spectrum, also the material needs to be defined for all these spectrums.

To get a HQ-Spectral Render, wether 3 nor 4 wavelenghts are enough.
You need more. How many?

15? 30? 75?

Possibly it should be an all new renderpath with variable settings of 3,12,24, or 48 spectral colours.
And i have been talking with Professionals who wanted even more spectral "passes" up to 70 or 80 around.

However - none of these wheels needs to be discovered new.
You can get all needed material data for example here, from these free (downloadable) POV-Ray include files:
http://www.lilysoft.org/CGI/SR/Spectral%20Render.htm

The code for the spectral render is available at Mitsuba also ready to download.
The problem is then to get it to parallel OpenCL Code, because i believe that THIS needs to be in GPU.

Because you have 30 parallel Jobs, in CPU it will be 30 times slower, while GPU's can render it fast enough.
Also i assume that all future tracers will only use GPU's.

Because the workflow is just better, if you can see the result immediately.

This video will demonstrate in a practical sample, why spectral render as well as GPU rendering are the way to go:
https://www.youtube.com/watch?v=ByJGkSzh4eQ

Imagine the same with a slower system ...


At the moment spectral render is an overnight job, if not over several days.
2016-01-15 23_28_16-LuxRender - F03.Scene.00146.lxs.png


Rendered 6.40 hours on a 12 core CPU (at 10197x6798 px) :-)
Theogott
 
Posts: 142
Joined: Mon Nov 30, 2015 3:59 pm

Re: LuxCore and the elephant in the room

Postby burnin » Fri Jan 15, 2016 7:49 pm

burnin
 
Posts: 287
Joined: Mon May 03, 2010 8:04 pm

Next

Return to Architecture & Design

Who is online

Users browsing this forum: No registered users and 1 guest