Awesome, thanks for those tests. The spectral result does indeed look a lot like Octane. I’ve always liked the look of Octane images, I wonder if this is part of the reason.
That being said it looks like there’s an environment light in the octane image, is that the case? It fades to a grey blue in the background instead of black
Hmm the difference (on the top of the head where there’s no direct illumination) seems very extreme. It seems like there’s a lot more ambient light, I wonder if there’s a difference in how Octane treats environment light strength?
Or it might be a tone mapping difference? 
No! You’re right! Checking here, there was a typo in the environment intensity. I’ve changed the images and now it’s correct! Sorry!
Awesome! This shows the difference really nicely. Thanks again.
The orange appearance of red materials under green light is definitely coming from spectral then. And by looking at how close the colours are I would say Octane is likely using a very similar RGB upsampling approach.
I’ve come to the realisation that the way I’m doing things now is going to make future developments more difficult. By converting the product of weight and eval (which currently represents RGB data) I’m retaining the assumption that eval is returning RGB data.
This shouldn’t be the case. For future development of replacing RGB colours with other spectral colours, it should be the pure RGB triplet that should be converted before it goes through the rendering calculations, rather than the result of the calculations. The output is identical and there’s actually less of a performance hit doing things the current way, but it is just going to have to be reworked when wanting to add in new spectral colour types such as Gaussian spectrum or sampled spectrum.
I think the current work is still useful but I’m going to revisit what I’ve done and push the conversion further down to the colour level.
The painful thing I’m going to have to deal with is figuring out in which cases it is the weight that carries the RGB colour rather than eval. @brecht what was the reasoning behind doing it this way in some cases? Would there be a performance hit to swap them over to all be consistent?
@Thiagodesul: Is there a different glossiness set for the Cycles render? Also, in my humble opinion, I find the LuxCore’s result more similar to Cycles’s result than Octane’s result is. In fact, I have always suspected that Octane cuts some corners (in favor of speed?). Taking into account that every implementation shall have its issues, my root question with regard to accuracy: which (multiple) are a good/proper/useful reference implementations?
Hi, I find this topic very interesting. Do you have any plan to share a working build on graphicall or elsewhere? I would like to see how this compares with “normal” cycles in some scenes.
I recommend not pushing the converison deeper, keep it as simple as possible and ensure the basics are correct. And to ensure correctness, I think the most important thing is to create a datatype for spectral color.
I’ll try to get a windows build up somewhere in the next 4 hours or so
Fair call. I might leave it as is for now. I agree, having a datatype would make the whole thing much more robust, but the current implementation just smells a lot like bolting spectral on to the existing system. Once the basics are all working I can set up a visual test suite to ensure I’m not introducing bugs when doing conversions at a lower layer.
Is there a way to create a datatype and inherit operators from float3 without allowing them to be mixed (stopping a SpectralColour being multiplied with a float3 for example)?
@lacilaci Here’s the folder I’ll be uploading builds to. I’ve a change log to highlight what has changed for each as I release them.
https://1drv.ms/u/s!Al91CjdrcExJwrQ6E7VfnFKn-CjjCw?e=Ounnfl
Oh wow. Thanks for that… aside the fact that the noise is a bit colored now (as expected) performance is pretty good… I’m also surprised that OIDN works well too… Any known big limitations or expected drawbacks in this build? I think you mentioned sss, maybe some features not working?
It’s a developer build so I’m not sure if that has some impact on performance, I’m sure some things aren’t enabled (for example I don’t think I can make builds with CUDA because I myself don’t have it?? Maybe)
Performance shouldn’t really be all that different to regular Blender. You might get slightly more noisy results for now but I’m planning to optimise the sampling so you might even get slightly less noise than RGB Cycles for a given sample count. I’m planning on prioritising lightness noise over colour noise since colour noise can fairly easily be reduced without a big impact to image quality.
Really the only thing that is working right now is the Combined output when not using coloured volumes or SSS.
That being said, if you don’t need those things, everything should “just work”.
If you have some scenes you could try it out on, I’d love to see the result.
Yeah I’m seeing pretty wild diferences right off the bat… Mostly in light distribution, bounced light is more saturated…
your build, with spectral rendering
I’m gonna run this on few scenes, i kinda feel spectral rendering should fair better on heavy overexposed areas that need to bounce strong light and maybe saturated sky and sunset vs interior…
I always felt something is wrong with how light or color is distributed throughout the scene with cycles, but at the same time I have no idea and maybe it’s all correct 
… Will get back with any interesting find and will share this build with few people to check it out.
By the way, is it even safe to just plug in regular texture into diffuse slot and expect correct result from spectral rendering? I expected way less of a difference lol
So that’s one thing which I might have forgotten to account for so far, I think there’s going to be a pink cast to all images (you can test by just rendering a plain white emitter) but you can either correct it yourself or wait for me to fix it properly 
Yeah, I think this might cause a difference. Bounce light, saturated colours etc will be the most different so far. Extremely bright lights on dark objects might appear slightly different too.
Yeah it is, the current implementation is entirely ‘invisible’ so all RGB colours are being converted to spectral, rendered in spectral, then converted back to RGB. Just use Cycles as per normal, it shouldn’t require any special attention.
If your ‘whites’ in that scene are indeed white then there must be a white point correction missing, if they do actually have a slight (very slight) pink cast then this is expected.
I can confirm there’s an issue converting colours back to RGB, I’ll upload a new build with a quick fix for now but it’s an area of the code which I need to give more attention to in order to do it ‘properly’.
