Thoughts on making Cycles into a spectral renderer

Interesting.
Emission looks practically identical.
Absorption ends up being quite a bit less saturated with the chosen color. However, it also looks more hue-constant if compared to the emitter version.
Scattering clearly has the biggest difference and I feel like there gotta be a bug there, but it still looks nice and not too noisy

That’s amazing! What exactly changed to make that work?

I have quickly redone one of my earliest tests wherein I tried out spectral absorption by faking it with nodes. Here’s the same thing with proper volume absorption. It’s not the most informative of tests and the conclusions don’t change from last time, but I figured why not redo something “properly” which I previously only could fake?

Also it just looks really pretty.

RGB:

Spectral:

You can clearly see how the spectral version preserves the hue of the absorption color (RGB 0.9 0.5 0.1) much better than the RGB version in which the blue contributions very quickly fade to 0 whereas the red contributions stay pretty intense.

__

One more I’d love to redo once proper spectral color input exists. In this one, the only light source is a plane light source which varies along the y-coordinate with a spectral color node which, of course, isn’t actually spectral color. It sits in a box which scatters light, fully white, density = 1.5.

Spectral looks more greenish which, I assume, is due to how strongly green spectrally overlaps with red and blue.

RGB:

Spectral:

1 Like

Yes there seems to be a bug in indirect light in volumes which leads to the lack of coloured shadows and introduces significant error in the scattering.

Some optimisations were made to the functions responsible for converting between spectral and RGB, removing some of my very inefficient code.

Thanks for those tests, I’ll definitely try to get more progress on the spectral input front - pembem22 actually mentioned he was experimenting with it, I’m excited to see how things go from here.

6 Likes

One more quick test: Something that might be Ametrine. For the most part, the RGB version looks brighter and more reddish than the Spectral version. But íf you look carefully, one of the biggest differences appears to be an internal reflection near the bottom right of the Gem, which doesn’t appear at all in Spectral version. Only in the RGB version is there a purple shine. Other spots nearby feature a blue region in the RGB version that should quite clearly be purple, which the Spectral version maintains.

RGB:

Spectral:

Other than the overall more pronounced reddishness, you’ll likely mostly just see these differences if you actually look at it at full resolution.

Honestly, the enhanced hue-stability of indirect or absorbtion-colored light is one of the biggest benefits of spectral rendering thus far. Because unless we’re talking about some really weird spectrum, deeper bounces in the purple region should definitely not become blue.

I’ll have to think about clearer volume rendering examples, probably ones including scattering, which don’t at the same time destroy my computer…

A massive thank you to @pembem22 for submitting a PR enabling spectral data transfer between nodes, and converting the Blackbody to output spectral data. This is a huge milestone. Hopefully some sort of custom spectrum input method will be coming soon, that’s where we’ll start to see the biggest differences, but already this is quite a stark difference. Images by @pembem22 from the PR.

Master
image

Spectral ‘RGB Blackbody’
image

Spectral Blackbody
image

14 Likes

WHOO! Now we’re talking! This looks excellent!

1 Like

Huge props to @pembem22! Here’s to hoping more Stealth Lurkers come out of the woodwork and contribute to shape this into a fully finished facet.

7 Likes

@pembem22 is looking more and more like a god each day. He spotted the bug I had written in the volume code and I think everything is working predictably now. The next daily build should be feature-complete for path-tracing Cycles. :tada:

The same scene as above - I might have changed the settings since the previous test, I can’t remember.

The same scene with a lower scattering density.

20 Likes

amazing. Thank you @pembem22 and @smilebags and everyone who has tested. Looking forward to this :+1:

5 Likes

That means it’s time to start testing on existing scenes for performance comparisons, and time for me to start working on the missing migrations such as in BPT, material previews and baking

13 Likes

Sorry guys this might have been a false alarm, I’m still seeing some issues in scattering which are really difficult to pinpoint.

6 Likes

Looks like we’re getting closer for this to be relevant now: @troy_s is there any update on the horizon concerning a “Spectral Filmic”?

1 Like

Been in a bit of a holding pattern waiting to see the direction that some other gamut mapping discussions evolve toward.

It’s not an easy problem to solve in a way that generates stellar looking imagery by default, and anything less would be problematic.

4 Likes

I can only imagine that it’s difficult. Other discussions? What are the options so far?

It’s wide open, with as many gotchas as there are options.

I always side with the image maker, which means that the display rendering transform bundle should produce a decent image, no matter how hard the image maker pushes the material. Similar to the sort of output you can expect from other mediums such as emulsion film stocks.

Not everyone has the same goals though, so there are a plethora of different contexts.

2 Likes

I can only imagine the funky results you’d get exposing film to pure wavelengths of light. I guess film emulation would be one way of approaching this but as Troy said, there are a lot of different contexts in which ‘best’ could be defined so it’s a very difficult problem.

There seems to be another bug with volume lighting: Apparently, for emission volumes, you need a regular non-black light source with non-zero emission somewhere in the scene or else the color won’t work.

Both of these are rendered in the spectral branch. Exact same scene with a single difference. The white one is when the default light source is either removed, set to 0 power, or set to black.
The material is purely volume emission.

Here is my material, applied to a cube scaled up 10x in object mode. The camera is above it looking straight down.

3 Likes

Ok there are some big differences here. I’m pretty sure there must be some sort of bug but I’m not sure what it is.

I made this scene in Spectral branch first so it’s made to look good there.

Rendered to 1024 samples (adaptive on), and denoised

Spectral: Rendertime a little over an hour:

RGB: Rendertime a little under 11min:

Now obviously the spectral version looks way better.
I noticed a few things there:
Using blackbody temperatures under about 223K (should simply appear black or, for volume emitters, fully transparent), things appear to go wonky. Like, big chunks of the volume go black. Even stuff that’s well above that limit. I’m not quite sure but it seems as if maybe cooler blackbody radiation suddenly just blocks light?
This does not happen in the RGB version. However, there I get this red glow. Which is weird because I also have a gradient on the emission strength. That stuff should render black/transparent there as well!
And as said, huge discrepancies in rendertimes. Like, to an absurd degree.

I honestly feel like something is wrong in the RGB version and something different is wrong in the Spectral version? I’m not sure.

The scene is barely different from the shown node setup. That should already suffice to get these results.

I will say that I did some probably suboptimal things such as cranking light bounces to 1024 and such, so I’m confident that hour long render time could have been a lot shorter. But even so, this seems a bit absurd. Especially seeing as to how I also did that on the RGB version.

3 Likes

Yeah there’s definitely still issues in the Volume rendering. The hard thing is firstly specifying exactly what the correct behaviour should be in the context of spectral rendering, then being able to test that is actually occurring. Thanks for the test. I’m curious to know what’s causing the huge difference in render time, it could just be un-optimised code in my branch, but I wonder if the adaptive sampling threshold meant a lot more samples were used on the spectral one, given that there’s more detail in a lot of the image.

3 Likes