Thoughts on making Cycles into a spectral renderer

Since there’s a new build and I was curious I thought I’ll join the fun.

RGB Cycles / sRGB Standard:

RGB Cycles / AgX:

Spectral Cycles / sRGB Standard:

Spectral Cycles / AgX:

Encountered bugs on the spectral build:

RGB input crashes build:

Map range outputs single “channel” scalars, gets rendered colorful:

The test scene is based on krams test images above. In case anyone wants to grab it, feel free:

19 Likes

Note on AgX: The Spectral branch uses a different whitepoint to render images. It’s based on I-E rather than I-D65.
The reason for that is, that we want the default conversion of an sRGB Red 1 0 0 plus Green 0 1 0 plus Blue 0 0 1 to add up to a completely uniformly flat spectrum (so that, say, a color of 1 1 1 means 100% reflection) which implies that the whitepoint needs to be I-E. (That illuminant is literally defined to be the flat equal energy spectrum)

As a result, by default, the config is going to be slightly off.
To fix this, you have to

  • go into the config.ocio file (just open it up in notepad),
  • find the roles section (line 10 and onwards) and
  • locate the line XYZ (line 23)

change that line to XYZ: Linear CIE-XYZ I-E
(so just change the last bit to I-E)

Then the colors will end up looking a bit more comparable

An easy check if you did it right:
Does the default scene in Cycles look kinda yellowish or pinkish? You’re still on the wrong whitepoint.
If it looks the same grey as regular Cycles, you did it right.

You’ll have to restart Blender each time you change the config though. It only gets loaded at launch

7 Likes

I am curious if this is something that can eventually be changed so that one does not have to restart Blender. Would it be possible to eventually have a dropdown in rendering preferences that tells Blender to use I-E or I-D65 without restarting (likely with a note specifying that I-E is for spectral and I-65 for non-spectral)? I would suppose that if the spectral branch replaces the non-spectral Cycles, this might be unnecessary.

EDIT: Please bear with me if such a question reveals the great depth of my ignorance on the topic. I am simply a curious bystander.

I’d very much love a more interactive/dynamic support for OCIO, yes. I think it’s on the radar in theory, but at a very low priority?
At any rate, it’s entirely independent on the Spectral branch

1 Like

Is it possible to support hip in the future?

The Blender developer documentation says there’s no publicly available HIP SDK for Windows yet, which means I can’t compile the kernels myself. But that shouldn’t be a problem on Linux or later on Windows. I expect the HIP kernels to work without any additional modifications, the spectral rendering is implemented in a platform-agnostic way.

2 Likes

A new build is available with the following fixes:

  • Background MIS works on GPU
  • Fixed a crash when connecting an RGB node to a spectrum input
  • Fixed colorful results when connecting a value node to a spectrum input
  • 8 wavelength per ray are used now
22 Likes

Is there a MacOS (Intel) version of the build available?

For context this should make for an ever so slightly slower render but color noise should disappear more quickly, right?

For those looking for it, it’s here:

Do you think it could also be made into one of the builds that lands in the branches menu on Blender Builds - blender.org ? It seems like there are talks of basically ending graphicall in favor of that place in the near to mid future

Also, this by default of course still ships with Filmic as is generally the case, but due to the ability of spectral rendering to produce out of gamut values for sRGB screens, it might be a good idea to use AgX instead, which is built with such possibilities in mind. You can find a recent version of that here:

Basically just drop these files into the colormanagement file and “replace all” (or backup the old files if you intend to use them still)

Note that by default the whitepoint of this is set to I-D65 though, as regular Blender will render with that as a target. Spectral Cycles instead uses the whitepoint I-E, so you will have to:

  • open \blender\3.x\datafiles\colormanagement\config.ocio in notepad or your favourite text editor
  • find the roles section (line 10 and onwards)
  • find the XYZ role (should be line 23)
  • change it from Linear CIE-XYZ I-D65 to Linear CIE-XYZ I-E
  • save and restart Blender

If you don’t do this, “pure” grey will render with a yellowish/pinkish cast. If you did it right, it will render in the same grey you’re used to from regular Cycles

8 Likes

That’s right.

Thanks for the info, I’ll look into it.

I’ll include it in the next build.

8 Likes

Oh I’m actually not sure already including AgX is the best of ideas yet, as it’s still kinda subject to change. That was less for you and more for others?

I mean I’m not opposed to it by any means, but people might be confused.

Also, did another test:

Looks like the hair shader works now, nice! - That was one of the long standing issues of the old builds

9 Likes

still sometimes getting the weird artifacts except they are no longer reddish but rather greenish

CPU and GPU results still doesn’t match:


The above two are Filmic results. CPU has the blue light purplish (what we are expecting to see with Filmic) but the face is somehow broken. GPU has the face fixed but the blue light looks cyan instead of purple.

And here is blue monkey under blue light:
CPU:

GPU:

Both are noise threshold 0.01 with 4096 max sample and Filmic View Transform.

Though CPU also has artifacts sometimes, it seems overall more reliable than GPU in the current state.

4 Likes

Just found out about this build yesterday and opened up an old test scene, then rendered a frame with OCIO. Absolutely astonishingly bonkers!

3 Likes

Can you post a Cycles Filmic render as well so that we can compare?

Yes of course, but sorta hehe. I don’t have a cycles filmic install but here’s the stock cycles aces version.

Did you take care to set the colors to the correct saturation? In ACES, 1 0 0 Red is gonna be a different value than usual, right? - Not sure what the config does.

It looks like the grey in the tunnel is slightly more bluish, and whatever color the debris is, it’s less to the red light reflective than in the spectral version

Hmm, good one. I’m not sure if this is an issue since both versions share the same ocio config, so even if one version is not exactly purely red, the other shouldn’t be purely red either(or so I think). Also I noticed that in the spectral build with ACES, I’m getting pure white lights being shown with a pinkish tint. So either I screwed up ocio with the spectral build or it may be a bug?

In how far are these the same config? I thought one of those is ACES and the other is AgX? Those should have different roles, I suspect

In the ACES version, are you still selecting colors from sRGB or are you selecting them from ACEScg or something?

In the Spectral version, currently you can only select from the sRGB gamut (though with white point E) because of the relatively simple spectral reconstruction - assuming it’s still the same reconstruction as in the old build.
In regular Cycles, the colors are normally selected from sRGB (and whitepoint D65), but that’s different from ACEScg (more saturated colors as the primaries, i.e. the values you get for RGB 100, 010, and 001 respectively, in fact they go beyond spectral and don’t represent actually visible colors)
I think the whitepoint of ACES is D60 rather than D65 which might explain the bluish cast of neutral grey.
The fact that that isn’t correct makes me think the primaries are also similarly affected.