It will ‘work’ in such a simple case, but only by taking advantage of negative emission. I suspect the way objects of those colours would interact with a scene may be somewhat unpredictable. The goal is to be able to cover a larger gamut while staying within 0-1 reflectivity across the spectrum
2 Likes
Right, I understand it doesn’t work as good as how a potential “final solution” would. I am just happy that if AgX decides to use P3 as working space, it will not cause significant problem for the spectral reconstruction.
So to summarize where we’re at as I understand it right now:
There are roughly four different but related topics covered in this thread so far:
(click or tap to expand)
1. Spectral Rendering via Hero Wavelengths
This is the base package, the minimum viable product.
Unless something changed, we are quite close to done with this, however a few shaders require some love. For instance the hair shader still does not work correctly.
2. Spectral upsampling
This is important to make it possible to use regular image textures as color input for shaders, so it’s also gonna have to be in the base package.
We currently have a method that works adequately for sRGB color gamut. Anything beyond that will not work correctly, featuring wavelengths of negative amplitude. For an initial release this probably would be enough though.
That being said, there is a superior replacement, drastically expanding the gamut of possible input colors, already being worked on, but it’s currently buggy.
3. Filmic Update
This does not really affect the rendering process. It probably is not necessary as a first release as the current Filmic would be somewhat fine for now. - It only matters for final images. If you intend to do your own processing of exrs in compositing, this may not come into play at all.
However, if no compositing is desired (or you want to apply the Filmic LUT to your result after compositing), implementing a new version of Filmic that can deal with extreme saturation would be a huge improvement for high saturation scenes that currently would throw away information by clipping instead of attempting to smoothly compress the image to the target range.
It seems to me we would actually need multiple versions of this for different target gamuts.
However, at first a version just for sRGB, replacing current Filmic, would be fine.
this turned out to be wrong. See:
Really, imo, it would be great if we had like a LUT editor in Blender for proper lookdev work. There is a lot of artistry going into designing a LUT and Filmic is, as I understand it, designed to be a solid neutral default, attempting to give “good” results no matter what. As such it’s important as it will inevitably be the most commonly used LUT (much like current Filmic is the most common choice).
There is an early beta version of wider gamut Filmic. - I have not tested it myself yet but early results look promising if maybe a bit pale. (Somewhat inevitable I suspect, as compressing saturation is the whole point, so I don’t want to overstate that without first doing my own tests)
Can an OCIO config and such be hidden behind the Experimental Features flag? If so it could be nice to bundle this preliminary version but warn, that it is subject to change.
All that said, it’s not strictly about Spectral Rendering and could be seen as complementary. I don’t think a first release of Spectral Cycles would necessarily need this bundled.
4. UI for Wide Gamut colors or spectra
This is concerned with letting people actually pick colors outside sRGB using color pickers, or fiddle with spectra directly.
Some of that just amounts to exposing spectra as values and a lot of this has already been done (though I think the latest version stripped out some functionality for the sake of maintainability?)
But other parts are trickier. It would be good to be able to distinguish metamers for instance, and it would also be nice to have a few ways to pick high saturation colors beyond the gamut of sRGB in a decently intuitive way.
IMO most of this can be postponed until the core is in though. In fact it may well be easier to wait until basic spectral support exists and we get more people testing all this stuff and giving proposals accordingly.
Like, it’s fine to think about it already now, but it’s not unlikely that we aren’t even aware of all the use cases we ideally want to support until more people get a hand on this.
As far as I can tell, the only thing stopping this project from getting submitted as a patch for review right now is the remaining broken shaders in 1., right? All the other things should be possible to figure out later, in independent patches
4 Likes
That’s pretty much correct.
I think it’s also necessary to have spectral reconstruction not limited to sRGB, so that means the new method must be finished and included in the base package.
Another question is how spectral rendering should be integrated into Cycles. Replacing RGB rendering means it must be thoroughly tested and be production-ready, while having a runtime switch between those two requires doubling the amount of bundled GPU kernels and considerably increasing the size of the installation. Adding spectral rendering as a build option can also be done, but that means most of the users won’t use it anyway.
2 Likes
I think having it parallel / as a build-option for now is a good start though, at least getting a patch in for now, so there could be a first core blender dev review
5 Likes
I think we can have it as a run time switch for now. Size increase is expected I think, Blender has been increasing its size every release, so…
2 Likes
I don’t understand… Isn’t the different target space already specified by the Display Device setting in CM panel? Currently we have sRGB, Display P3, and BT.1886 these three display devices. Not sure what you mean by “multiple versions of this”
I would actually think of it as a separate but related patch. I think which one goes first would depend on which one finishes first. My personal idea is if we can have AgX in the master first, and Spectral branch merge it from master, then we can have it no problem. Having it first can also avoid the mass audience having negative first reactions to the glaring spectral skews. But again I think this depends on which one finishes first. It’s totally fine for Spectral to be merged to master first, since they probably will be separate patches anyway.
1 Like
Yeah, and Filmic as it stands, afaik, targets only sRGB. It’s not meant for gamuts larger than that. Current Filmic assumes colors encoded with sRGB primaries as source and sRGB as target.
The new Filmic will targets the full spectral locus as source and some color space, likely sRGB, as target.
( @troy_s please correct me if I’m wrong. )
That said, I suspect going from the largest (spectral) to the smallest (sRGB) gamut is gonna pose the biggest challenge. If that works reasonably well, all larger spaces are gonna work as well if not better, as less compression has to happen.
I don’t think Spectral Filmic has much of a point without spectral colors. As it stands, with current sRGB Cycles as source and target, making Filmic work for spectral colors would simply crush saturation unnecessarily. It will absolutely be good to have, but it only really will have a point once spectral rendering is actually in.
Regarding submitting patches, as I’ve explained before this should be done incrementally in multiple smaller patches.
That also means not everything has to be fixed before the first patch is submitted, because presumably that would be just refactoring to introduce a new color data type without any functional changes. And even if all patches are submitted, it’s better to do it sooner than later so that problems in the design can be spotted before more work builds on it.
25 Likes
Actually the Filmic Blender on GitHub has support for P3 display, it’s just the FIlmic in current Blender master that doesn’t have it.
I would think the target depends on the display device setting. Again, both Filmic and AgX has P3 support.
No… AgX sort of works for Spectral doesn’t mean it is a dedicated Spectral Filmic that only works for spectral. It is significantly better than Filmic even with regular Cycles.
This is the Filmic in Blender master, I swear the light color in the setting is orange, why does it look so yellow?
Okay, that’s better.
5 Likes
That’s the version of Filmic I meant as that’s the version of Filmic I have used so far.
That said, on the other points, thanks, I did not know this
@smilebags @pembem22 in light of Brecht’s post, once you get the current version to build again on the latest patch, do you think it could already be submitted?
The caveats of what’s known to be missing could presumably be added in the review patch notes
1 Like
The updates from Cycles X are completely unrelated to, and independent of Spectral rendering. All Cycles X features should still work more or less unchanged with Spectral rendering.
2 Likes
I definitely think that submitting some prerequisite changes like refactoring types as Brecht mentioned would be a good first step. I’ll look at getting a patch with those changes ready in the next month, hopefully.
I hope that as more parts of the changes make their way in, the remaining required changes and decisions to make will become clearer. The current bugs might take some more investigation, but discussion in the initial patch reviews might be a good place to better understand the code in which the remaining bugs exist.
15 Likes
Sorry I didn’t know that was against the community flags. But I am very thankful for the hard work to make this spectral branch. Keep up the good work 
, and I hope you guys all the best and that I would be a part of the testing people .
Now that Shadow Caustics are in Blender (coming 3.2 if I understand right, so a fresh build should already include that), it would be really cool to get another working build of the Spectral Branch. Especially if there can be a version of the Fresnel node that takes spectra for the IOR parameter
1 Like
I hope MNEE works with spectral dispersion, the current MNEE in Blender seems to use diffuse color for the color of the caustics (tested with light path node). But since the original paper was using brute force spectral sampling, I think it should work.
With that being said, I think dispersion is planned for after the main merge, so it is not the priority now. It’s best to focus on the incremental patches and work our way to the master first.
Also it is important to learn the limitation of MNEE and understand that things like Prism Dispersion is not going to work with MNEE since the majority of prism’s caustics are outside of the shadow area.
3 Likes
Any progress on this?
1 Like
No news yet, I have been jumping back into the code and re-familiarising myself with the changes which have been made.
9 Likes
I’ve been trying to get an up-to-date master for a couple of days now, I think I know what the issue is. It also seems to stop (and not start again) if the computer sleeps. Is there a faster way to get a majority of the files needed for lib (a zip, stored on a high-speed CDN for example), then just let SVN deal with the recent changes?
I know it has been a while since I’ve run this, but considering lib is currently 5.6GB at this point, I wonder how many more weeks I’ll need to wait for it to update.
Edit: Well would you look at that, complaining appeases the programming gods again! It finished!
13 Likes