Modifying LuxRender to model diffraction

[sharlybg]

It is in the TODO list but no one is working on this topic at the moment. My plan is to have spectral rendering support available only for CPU in order to reduce the complexity of the job

Is there any visuals quality defference between RGB and Spectral to go slower ? After a looking at maxwell gallery i really think Corona RGB renderer do better quality work.

I know it is a bit off topic but do someone know what nasty trick is behind this defference between corona glass and other renderer ? look yourself it's like light is scattering hundreds of time before get out :

And when people ask why there are so much difference between to path tracing based algo look what happen here :

https://corona-renderer.com/forum/index.php?topic=1975.0

Glass are so bright in this renderer that you can't believe it

https://i.pinimg.com/originals/1b/92/0a/1b920a3484a79acf1c582bf856b42706.jpg

[B.Y.O.B.]

Is there any visuals quality defference between RGB and Spectral to go slower ?

I'm also wondering that: is it even worth it for normal artists?
Granted, for material simulation etc. like asked in the first post it's needed.

But I have the feeling that for most people a simulation of dispersion and mabye thin film coating (oil on puddles) is all that's needed.

About that chandelier: I know nearly nothing about Corona's render engines, but maybe they have some kind of vertex merging or SPPM behind the scenes?
Or they are using that new microfacet model for glass (though I think it was only for rough glass)? (Can't find the paper right now)
Also, the testscene is not the same in both renderers as users in that forum have pointed out.

[sharlybg]

I'm also wondering that: is it even worth it for normal artists?
Granted, for material simulation etc. like asked in the first post it's needed.

For me anything able to add faster render (fast denoise) and perceptable Visual quality are welcome : something maybe in the range of GDPT : https://mediatech.aalto.fi/publications/graphics/GPT/

[jantschek]

Hi,

I quickly want to add something to the spectral VS. RGB discussion.
I think that spectral renderings have some more advantages - not only the dispersion effects.

As far as I know the spectrum ist able to describe any existing color. RGB is valid for a triangle out of all of those colors - so less than all.
RGB is very optimized for today's displays. That's why all the viewers to kind of RGB conversion before they show the image on our screens. That can be done perfectly if you have more information in your image than it is necessary like spectral data.

Another point is the safe real world data transfer
A red light LED light source from NICHIA has a special spectrum that is emitted:
http://www.nichia.co.jp/en/product/led_ ... SR119B-V1'
Only this allows us to be sure that the high quality (spectral) defined materials (glasses, diffusers etc.) interact in a correct way.

So watching an image and judge the "quality" of rendering only by a visual impression might work with RGB. But doing some kind of virtual prototyping (even real architecture-vis without magic light sources) requires spectral stuff.

One more sentence - also the handling of diffractive actions by coding them into shader (witch is a great idea - professional ray trace software does the same - please do so) will require spectral data.
Having all those features makes lux somehow unique - the common RGB renders are already available.

BR

[burnin]

same, for me features are more significant than the speed or artistic skill
spectral is one of the reasons why i started with lux in the first place, even if it's not the fastest around i am able to get the job done up to HQ ind. standards which can be verified by anyone at anytime (as oppose to M~R or other closed source )

[sharlybg]

Just to clarify. I'm not against the possibility to add more features to Luxrender as it will benefit and serve a wider range of users and specific scenario. But as in any long time project you need to target a good priority balance. What do i want to say: Each added features have a cost ( Time,human ressources, and money ). features have impact in software usability and productivity. Features also have targeted users size. In a better world the best will be to have strong to adress all theses kind of parameter equally in term of priority. Why ? because some features can be more expensive than others and sadly most of the time cost isn't directely proportional to generated impact. And in our case (Lux community) a small Devs team will be inclined to work on costless features able to generate wider and deeper impact while gathering more users and popularity. you can feel it here :

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

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

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).

But that said this can attenuated by the nature of opensource project. I mean that every users is supposed to thinks in an activ way to make the project more valuable ( we need more Devs / more users / more donator and sponsors /better idea to improve).