I have a question, what happened to the sharp HDRI shadow?
Here is a comparison, both are using the “sunrise” HDRI that comes with Blender. The left is spectral and right is regular Cycles. I used the curve in color management to make the spectral look closer to filmic (also why no filmic?)
That’s very strange… I wonder why that would happen 
are the settings for clamping different between them? Or environment importance sampling resolution? I can’t imagine that anything changed in the spectral branch would have done this but I’m sure theres a reason.
Sharp HDRI Shadow.blend (1023.0 KB)
Here is the file if you want to take a look at it.
Also why is the filmic color management not in Spectral Cycles?
Looks like the texture gets clamped
Pembem22 (another dev working on this with me) highlighted a possible reason for this, related to background importance sampling. It doesn’t seem like a trivial thing to fix but it has been noted, so thanks for the bug report again @Eary_Chow.
In the meantime, you can use a sun lamp and clamp the background image (limit the values to what is needed for the rest of the sky) so that you don’t get negatively impacted by the lack of background importance sampling.
I think I’ve mentioned it some time before but Filmic and spectral rendering are a difficult combination. I’m working on what needs to be solved to get it to work, but in the meantime you can still export the EXR then load it into Blender or other software that supports Filmic (such as Affinity Photo) and apply the Filmic transform there. I know it isn’t ideal since you cant use it in the viewport etc, but it’s the best we have for now.
Please note that values which are out of gamut (this can be quite easy to produce accidentally with spectral rendering) will look wrong even with Filmic. You will need to manually handle these cases by desaturating or otherwise bringing those values into gamut. This is what I’m working on a good general solution for.
@smilebags Amazing work on spectral rendering you’ve done over the years! Is the idea that this will be added into the mainline at some point for general use? As a lighting artist, this possibility is incredibly intriguing 
Thanks for that @Scott_Warren. Thanks for the kind words. Certainly the intention is to get it merged at some point.
The focus now is on stability, performance and ironing out bugs, so I am hopeful we will have some progress on this in the coming months, although personal commitments have meant I have very little time to dedicate to this at the moment. The contributions of @pembem22 have been absolutely instrumental in the progress so far.
I am looking forward to what lighting artists like yourself will be capable of with spectral rendering.
Hi.
What does thin film effect on materials in this branch depend on? Any parameter related to the spectrum of the lamp? Any parameter in material?
Some .blend file showing the settings for a basic soap bubble example would be helpful.
Hi Yafu, the bubble example in the earlier part of this topic were created with an old technique I used to create spectral images, and the node group was based on the math regarding thin-film interference, but I think I had not accounted for all aspects of the equation accurately.
The spectral branch of Blender does not yet have a thin-film node, though I do hope to add one some day. I don’t know whether I still have the files in order to show the way the thin film effect was done earlier.
I noticed that the Windows build on Graphic All is updated, so I tried it, but Spectral version of Nishita is not right:
Update:
Update Again:
I recently found this Blender branch and I wonder if it even makes sense using textures like that MacBeth chart? Does that really work? Doesn’t look correct to me compared to the images. Maybe you need to create each tile with a proper tile and material?
The diver in the example pics,using something similar like a xrite chart who knows.We dont know the exact water absorption in this examples,further the water can have more salt or common particles what makes the water scatter or absorb slightly more.
However,As you can see even at 15m depth the Fotos haveing roughley the same light condition.especially 10m foto looks like it has some camera lighting.These factors can make different apperence of the Fotos taken.
The macbeth chart i have used is a well known chart i have placed on a sphere inside a sphere with the water material.
In the nodesetup you can see that i used a absorption amount similar to 5m (of clear water, without any additional scatterings what can further occur in nature).
The absorption equation (i have compared and checked with a excel calc) seems right,and the result added on a transparent shader looks quite close to a volume absorption.
What do you mean with each tile?
As sayed,if the camera was useing a light,then the fotos taken are bad for comparison,because the camera light bring back the whole spectrum from blue to red,even if the absorption in the water occurs.
Here are better real world examples,from a paper.
edit,i made another spectral testrender,with the same colorchart in as the reference pic on the left.at 10m absorption depth.you can see the absorption fits very nice although the reference foto was taken at a reef which has ofc some additional scattering from microparticles etc.you can see the amount of backscattering at the black parts at the ref pic.Since the rendering has only the absorption without the scatter,these are missing.
edit,i have found a scattercoefficent of pureseawater.here the same render as before but with the back scattering.
Spectral Rendering is submitting the patch to extend color data to be more than 3 channels, and the new data type will be called Spectrum!
https://developer.blender.org/D15535
Finally! After 2 or maybe 3 years of development we are finally seeing Cycles spectral branch merging steps. This will surely move Cycles closer to other production renderers. Good news!
It’s more than that. The whole project started at about 2017 to 2018, it’s been 4 to 5 years now.
With multi-light sampling and path guiding on the way, Cycles should now be more than fast enough to handle the slight increase in render time that will occur when spectral rendering goes in.
In addition, the reason why it has taken as long as it has is because the devs. were working on this in their spare time, I would think progress will go faster once all of it is in master and we have Brecht and Lukas looking at it.
Anybody knows if spectral rendering will be an optional mode that can be turned on/off?
I personally don’t care but I think people who do NPR have no usage for it and everything that slows down the renderer is something that maybe should be optional…
