Thanks so much for this.
If you need anything else along those lines, I’d gladly provide. A bunch of the more recent tests got significantly more out of gamut than that one, for instance. The render of pure water, say. It also ends up looking pretty darn purple in deep depths which, due to how blue is handled right now I’m not sure it actually ought to.
It’s quite a rabbit hole. There is a part of me that is starting to believe that any linear transform from one colour space to another is fundamentally flawed in that it comes with an Abney complimentary light approach implicit in the math.
You’d be quite right. The downside is that this is more or less, gamut compression aside, a by-the-book transformation.
Not sure what it’s doing here but it’s clearly not right 
Different outcomes between viewport and final render (both have problems) when plugging a generated texture’s Fac into a Shader’s Color.
1 Like
That’s weird indeed. That’s meant to be grey, right? I’m guessing there’s a bug in the float -> spectrum conversion code. Thanks for reporting @kram1032
It goes even more haywire if you start mixing materials. Although if not for the biasing artifacts (the clearly visible squares), it’s actually really pretty lol (though actually the viewport somehow ends up way prettier and more consistent than the final render)
Freaky. Yeah definitely something funky going on there. Looks cool though!
I wonder if what’s going on here is, like, an accidental, buggy version of spectral noise wherein, essentially, you’d add the spectrum as extra dimension for noise, therefore giving you random spectra at different points. If that’s what’s effectively happening here, it could be cool to have that directly implemented, though without the artifacts 
I can’t reproduce the issue, what build are you using? The builds on GraphicAll were not updated for a while.
That’s a great idea for a new node! I wonder what could be done with it.
1 Like
I think I’m on the latest one on GraphicAll. Indeed there hasn’t been a new build in a good while…
I think that build was made before float->spectrum conversion was added. I guess I’ll upload a new one.
Oh neat! Any other new stuff I can expect with that change? Aside of, like, master stuff?
Pretty much all the things I mentioned after the float->spectrum conversion:
- Fixed wrong socket type in “Subsurf Scattering” node
- Added more operations to “Spectrum Math” node
- Separated “Blackbody” and “Spectral Blackbody” nodes
There also will be a new simple plugin to import CSV tables directly into the spectrum curves node.
4 Likes
New build available on GraphicAll. https://blender.community/c/graphicall/Cnbbbc/
You can enable the new plugin in the preferences.
No GPU kernel for now, my system runs out of memory when compiling them.
4 Likes
@LazyDodo do you know if there are any errors compiling this build at the moment for you which might be getting in the way?
I stopped providing builds a few weeks ago, the only ones still on there are the GSOC ones since i promised i’d provide builds for the GSOC. Once that ends i’m retiring from GA builds for at-least the near future.
9 Likes
Ah no problem, I really appreciate what you did for us, thank you!
3 Likes
A render that wouldn’t have been possible before:
Suzanne has a simple diffuse material with gradients to interpolate between the two spectra of oxygenated vs. oxygen poor blood. Front to back the ratio of oxygen poor blood decreases, left to right the ratio of oxygen rich blood increases.
Top to bottom the ratio of blood with or without oxygen is kept the same. What changes is how dense the “pigment” is. At the bottom there is no pigment, at the top there is quite a lot.
Without spectral rendering, I’m pretty confident these exact results would have been nigh impossible: If you look at any concave region, where you get multiple bounces on the material before the light is reflected away (check the mouth, nose, ear, and eyes), you can see that the color in those regions shifts exactly like if you go a bit further up, white turning yellow, yellow turning orange, and orange turning red.
Here’s the material which requires taking powers of spectra to do this “right” (because these are reflection spectra. With absorption spectra the same could be accomplished by linear interpolation)
The wonderfully programmer-art-y plane, meanwhile, uses a similar idea to make it different amounts of water-colored based on a noise texture:
Finally, the lighting actually comes from the new sky texture (which, of course, isn’t yet spectral)
Didn’t yet make use of the CSV importer since I already had these spectra at hand.
5 Likes
Question about how lights are currently handled:
So if I don’t use nodes on light sources, and just set the input there to actual white, they will appear neutral white. (So presumably something like Illuminant D65, right?)
Now as far as I know, the base color of a light is simply multiplied by the color that the node setup yields, right?
But if that’s the case, wouldn’t that bias the light output a bit? Because multiplying by anything other than Illuminant E would cause a change to the spectrum, right?
But clearly you’re not using Illuminant E for neutral grey/white lights anymore, since otherwise you’d get that pinkish effect you had early on.
So are you compensating for that shift somehow, or are light source colors currently slightly shifted?
Comparing non-spectral renders to spectral ones suggests that you’re doing it right (in that render output looks consistent), but I’m not sure how that could be. I must be making some wrong assumptions here, right?