Thoughts on making Cycles into a spectral renderer

One thing I’m not sure about is how absorption plays into thin films. As a result I can’t necessarily get everything to work as I’d hope. For instance, if I attempt to use silver’s refractive index as the bulk material, I get these strange results:


Because the IOR of silver comes out to be less than 1 for large parts of the spectrum.
I think the reason is, that silver also absorbs light, which is stored in the ks of silver, which I’m not accounting for right now.
@pixelgrip do you have insights into that? I’d love to rebuild the full-featured up-to-three-layer complex IOR thin film shader but that node setup is an inscrutable mess so it’s unclear to me how to easily translate it into a spectral setup.

You need the Fresnel Conductor equation for this then.
The easyest would be to left N0 for dielectric air,N1 dielectric for thin film fluids,glass and transparent plastics,and change the equation only for the substrate to Conductor.
There is a reason that (like this case you have posted with the silver) that some equation combinations (Dielectric-Conductor or Dieclectric-Dielectric exists).
(The Thinfilm eq with Conductor calc at substrate would add the k value to the calculation as you know.High absorptive mats like metal have mostly a k value over 1.You can guess that the reflection calculation have the right amount then(n+k²)

A thinfilm eq of conductor film makes only sence if the thickness is a few nm thick,otherwise its gets realy quick absorptive.
As sayed for the substrate is fine and makes the most sence.

IIRC i have changed the Thinfilm Fresnel parts with this equation,(mainly added the k²)
conductfres
Here another eq for the same result
fresneqcon

2 Likes

Been playing with Spectrum Curve, it is really interesting how different materials look like they have different colors despite using the same spectrum curve. The first one is diffuse material, the second one is glass (spectrum in volume absorption), third one is metal.

One thing though, the curve is kind of hard to control. It is hard to reconstruct a curve to be excatly the same as another curve I previously used, a little bit difference in curve makes a huge differece in the view.

3 Likes

I think that problem is gonna be much improved once the asset manager is fully in place. You could just simply have libraries of materials to reuse.
For now, you can also use the append feature to get a material or even copy and paste to get materials from one blend file to another.
These look lovely by the way. But you need to be careful to set the handles of all those points to Auto Clamped or something like that (you can do that by clicking on a handle and then on the down arrow and select the option) - right now I’m pretty sure you’re going beyond 1 and 0, yielding unphysical, overly bright results that are gonna break energy conservation and lead to stuff like the extreme amount of fireflies you’re seeing.

2 Likes

I just found a problem with RGB version of Nishita in the Spectral branch RGB Cycles mode:

Considering this is RGB Cycles mode and RGB Nishita, it should have been the same as the master, but now the Spectral branch looks greener

yeah this is presumably a result of the spectral upsampling which appears to not be quite right yet. That part of the spectral branch is going to be replaced eventually. It’s a known issue.

But this is RGB Cycles, the spectral switch is not even on

Oh I see! That is interesting. I didn’t try this before.
I think that would suggest there is a problem with the color management rather than the spectral upsampling?
@troy_s what do you think?

A few folks have reported problems to me. Apparently using the config at my GitHub works, so unsure where it’s been bungled up. Haven’t seen A / B comparisons to be able to make a diagnosis.

What kind of test would you need? A rendered exr of regular and Spectral Blender?

If it has nothing to do with Spectral, just an A / B of what the current config in main is mangling up, versus what the config at my GitHub does. EXRs won’t have the transforms baked in, so aren’t useful, unless the data is actually being rendered differently which a diff would reveal.

Generic output referred files would suffice, assuming folks can describe how they are different.

https://imgur.com/a/DqLUwDs will this do? (Uploaded to imgur so you hopefully get the full quality)
All three of these use Filmic. It’s quite clear that the reds feel weaker in the Spectral branch

Here is a complete comparison using stable master and the latest Spectral Build:

Master:

(bottom row requires Spectral branch to work)

  • Standard: Master Stable RGB Rendering Filmic

  • Filmic: Master Stable RGB Rendering Filmic

Spectral Branch:

  1. RGB:
  • Display Native: Spectral Branch RGB Rendering Standard

  • Filmic: Spectral Branch RGB Rendering Filmic

  1. Spectral:

Diffs:

(Diffs performed in Master)

  • Master vs. Spectral Branch (RGB):

  • Master vs. Spectral Branch (Spectral):

  • Spectral Branch RGB vs. Spectral:

Thanks for putting the work in Mark. I think I have identified where the bug is in the official config. Will try to fix it when I get home.

Thanks again for putting the effort into this.

3 Likes

I made a small mistake in that imgur story and accidentally uploaded the spectral version twice. It should now be fixed though. (You get the same green tinge either way, modulo the differences that actually really are because of the spectral upsampling. For instance, the spectral version of green looks more yellowish, and red is darker)

Can you do me a favor and comment out the aces_interchange role in the official configuration and let me know if the white balance goes back to normal in the test?

if that’s in config.ocio I can’t find any such line. This is the file as it’s currently in the build:
config.ocio.txt (10.7 KB)

In the official 2.92+.

I don’t see such a line in 2.92 either:
config.ocio.txt (8.4 KB)

I thought the discrepancy was 2.93?