Thoughts on making Cycles into a spectral renderer

Oh wait I’m sorry I didn’t specify this correctly perhaps. Both renders are in Acescg, no AgX here and they both share the same ocio config file. Now regarding color selection, I might have screwed up any chances for proper comparison, since I chose colors from sRGB via a color ramp that went into emmision(I’m quite new to color spaces and light/render theory so I’m sorry for any confusion). But in my opinion, light bounces in the spectral version seem more plausible? I can’t exactly describe why or how but everything in spectral cycles just “feels” nicer. I might be completely wrong but this is just my unexperienced take hehe. EDIT* Okay so I have to ask, if the colors are from sRGB and wrongly interpreted by cycles in Aces, isn’t the comparison still a bit valid since both versions wrongly interpret colors the same way?

The question is, whether this misinterpretation actually is happening in the first place:

If you look at the config (literally open it up in a text editor), you might see stuff like this:

roles:
  color_picking: BT.2020 2.4 I-E
  color_timing: sRGB 2.2
  compositing_log: sRGB 2.2
  data: Generic Data
  default: sRGB 2.2
  default_byte: sRGB 2.2
  default_float: Linear BT.709 I-D65
  default_sequencer: sRGB 2.2
  matte_paint: sRGB 2.2
  reference: Linear CIE-XYZ I-E
  scene_linear: Linear BT.2020 I-E
  texture_paint: sRGB 2.2
  XYZ: Linear CIE-XYZ I-D65

or this:

roles:
  reference: Linear

  # Internal scene linear space
  scene_linear: Linear
  rendering: Linear

  default: sRGB

  # Distribution of colors in color picker
  color_picking: sRGB

  # Non-color data
  data: Non-Color
  
  color_timing: sRGB
  compositing_log: sRGB
  matte_paint: sRGB
  texture_paint: sRGB

  # CIE XYZ color space
  xyz: Linear XYZ IE

  # Specifed by OCIO, not used in Blender
  color_timing: Filmic Log
  compositing_log: Filmic Log
  default: Linear
  matte_paint: Linear
  texture_paint: Linear

or something to that effect.
And this defines which specific settings use which things use which colors.
In particular, I think the scene_linear and XYZ roles are the one to care about.
If your scene_linear role reads something like ACEScg (I haven’t looked at the ACES config so I don’t know the exact names), it should interpret colors you pick as ACEScg rather than sRGB.

However, the Spectral branch afaik would not do that, as only sRGB colors actually work (for now - this is not a fundamental limitation but rather a temporary one until we get a better model in place).
Or if it does, then it would give very saturated colors negative components where the ACES versions might still be all-positive. And that causes all sorts of issues for rendering.

I can’t say for sure what’s happening as I’m not familiar with the config. I’m just saying, they might not be so straight forwardly compatible as you might hope.

That said, yes, I also think the spectral version looks better, giving more plausible reflections.

Ah yes, you are indeed correct. The scene_linear role is in Acescg so the comparison is not worth much, or so regarding colors. Colors aside, it’s nice to know I’m not the only one that finds it just looks “right” hehe. It also seems quite stable, just a very nice build all-around!

In principle, spectral rendering works within the entire spectral locus, but ACEScg have primaries outside of locus, so strictly speaking ACEScg is never a good choice for spectral rendering. Though Octane another spectral renderer does claim they support ACES, I wonder what they are actually doing, maybe their spectral upsampling/reconstruction is just as hacky as our current one (rely on negative spectra for out-of-sRGB values), or they don’t actually take ACEScg primaries input, or they have some tricks up their sleeves that make it possible. Who knows.

Heh, since you mentioned it, I tried monochromatic lighting with a pure red area light on top of 3 purely colored rgb balls, one in octane and one in spectral cycles. The result was nearly identical, plus even an image as simple as that just looked absolutely gorgeous. On another note, I remember seeing a lot of fuss regarding Octane looking good out of the box while mentions of cycles stating it seems “plasticky” or a bit more dull in certain aspects. With this build though I was met with a certain “this looks real” feeling also present in Octane, that to an extent was missing in stock Cycles. Is this something valid? Or am I insane and in need of some sunlight…

2 Likes

I am not sure, the discussion of “which renderer looks better” never really narrow down to measurable points so related arguements sound abstract to me.

Need to know which primary the pure red is, otherwise no point of comparing.

Also need to know which view transform they are using.

Spectral Cycles with BT.709 I-E working RGB space and regular Filmic will yield orange-red ball, purple-blue ball etc., AgX should yield something that makes more sense.

If we are talking about other set of primaries, then it comes down to how these spectral renderers handle the spectral upsampling/reconstruction, as said, the current spectral cycles is hardcoded for BT.709.

1 Like

I also get that feeling when looking at spectral renders, especially ones with high saturation. The lighting just makes sense, it could be a photograph.

2 Likes

The saturation part really hit home. Octane ships with an abundance of luts to play with, that really establish that “oh now this looks great” feeling. And with this cycles build after playing with the compositor a bit, I got the exact same feeling.

1 Like

got this error now:

Invalid value in cuCtxPushCurrent(device->cuContext) (C:\blender-git\blender\intern\cycles\device\cuda\util.cpp:13)
Invalid context in cuStreamCreate(&cuda_stream_, CU_STREAM_NON_BLOCKING) (C:\blender-git\blender\intern\cycles\device\cuda\queue.cpp:20)
Invalid context in cuCtxPopCurrent(NULL) (C:\blender-git\blender\intern\cycles\device\cuda\util.cpp:18)
Invalid value in cuCtxPushCurrent(device->cuContext) (C:\blender-git\blender\intern\cycles\device\cuda\util.cpp:13)
Invalid context in cuCtxPopCurrent(NULL) (C:\blender-git\blender\intern\cycles\device\cuda\util.cpp:18)
Invalid value in cuCtxDestroy_v2(cuContext) (C:\blender-git\blender\intern\cycles\device\cuda\device_impl.cpp:126)
Caching exr file, 1722x1218, %AppData%\Local\Temp\cached_RR_weaire phelan correct scaling_Scene_e140c7cb1ded96b6a8c8d72fab2282bf.exr
Error: Failed to create CUDA context (Illegal address)

Also, I got an upgrade and it looks like the Spectral build isn’t yet RTX enabled? Cuda and HIP only

2 Likes

Hey guys I’m using Gengo Uney’s ocio config https://drive.google.com/file/d/1lubk… which bundles filmic and Agx and ACES and a couple others in one config from this vid: Blender Default, ACES, AgX & TCAMv2 in 1 config - YouTube .

But I can’t find XYZ in the roles section:


roles:
  reference: Linear
  scene_linear: Linear
  rendering: Linear
  default_byte: sRGB
  default_float: Linear
  default_sequencer: sRGB
  color_picking: sRGB
  data: Non-Color
  aces_interchange: Linear ACES - AP0

  color_timing: Filmic Log
  compositing_log: Filmic Log
  default: Linear
  matte_paint: Linear
  texture_paint: Linear

Is it there no way to use CIE-XYZ-IE whitepoint with this config then? Do I just add that line and it will work?

That config has the XYZ space there, just change the space name to something else and add the XYZ role (I believe OCIOv2 doesn’t allow role and space name to be the same), I think it should work.

EDIT: Wait, no, don’t use Blender’s own XYZ space, use the FilmLight one, that one is I-E.

The ACES in that config was actually “wrongly done”, we discussed about it on Twitter and he has been working on a second version.

Nevertheless, the nature of mix-and-match these “all-in-one” type of config still creates messy situations (like people are not supposed to use Filmic Looks on other view transforms). I recommend checking out my version of AgX, all you need to do is change XYZ role to I-E and done.

2 Likes

Thank you. I’m currently using your version and it works wonderfully.
Though I do notice some difference between your agx and sobotka’s agx:


is it normal to have some difference in the renders or did i mess up somewhere? Thank you

2 Likes

Not sure, If I understand correctly, the left one is spectral branch and the right one is blender main branch? Might have to do with spectral branch’s long standing green-tint issue…

My version is indeed different fron Troy’s initial version, but spectral branch itself also produces difference.

1 Like

I’m interested to test your version of AgX. What is the best source of documentation (written, or otherwise) for understanding how to work with the different View Transforms and Looks?

1 Like

Yes the left is spectral and right is main branch. I didn’t know there was a green tint issue in the spectral build. Guess some manual compositing will help. Thanks.

1 Like

There is no documentation at the moment. For View Transforms, there are mainly two, AgX is to replace Filmic, and Guard Rail is to replace “Standard”. The looks are artistic grading choices, you can choose based on preference.

EDIT: @Austin-Berenyi Documentation is out

4 Likes

You can now download a build for macOS or any other platform here.

The Linux build should have HIP support now. It’s not yet enabled on Windows due to compiler bugs.

2 Likes

Awesome, I will test. Is there anything that needs to be done to enable spectral rendering? Or is it on by default in this build?

No additional setup required.

Ok. When I try it in GPU mode, I get errors.

I’m testing on a 2019 MacBook Pro with AMD Radeon Pro 5500M 8 gig, running MacOS Monterey.

2 Likes