I mean that’s what conversions for? I’m just saying I’d rather not have invisible conversion happening I’m not aware of as an end user.
I’m thinking of a situation where if I’m dragging a connection from one socket type to another it would automatically place a conversion node in between. Effectively also making me aware that conversion needs to be and is happening.
There is no meaningful conversion to happen. It’s just converting from spectrum to spectrum - the conversion is one of context, which can’t happen automatically without getting it wrong in some contexts.
This happens literally every time someone connects a colour node to value, and it isn’t always the correct transform.
And plenty of users have probably no idea it’s even happening. But this is becoming a bit of a offtopic discussion I suppose so I’ll leave it at that.
There is no change in how you can modify a spectrum with this change. The only thing that changes, really, is the way a spectrum is reconstructed from color. In all other cases this would be identical for the user.
Once the data is a spectrum, it stays a spectrum.
Perhaps putting in a whole new spectral type is overkill. But if the automatic conversion node doesn’t know about what node that socket actually belongs to, it can’t really decide whether it needs to go emitter type or reflectance type, can it? - That’s the main concern here. If there’s a simpler, more pin-point way to do that, that’s absolutely fine.
Even so though, just for artistic freedom, it’d be good to then have a standalone node that can take an RGB color and convert it into an emission spectrum if you want it to. (Most of the time you’re gonna want reflectance, so that should be the default)
The ability to use D65 sRGB in lights while retaining the constraint that (1 1 1) white means 100% reflection in reflectance based closures.
I think the actual end user differences are gonna be too small to warrant this. Like, the data is literally the same. Literally the only difference is the shape of the spectrum after you plug in an RGB color.
I believe this is taking the idea of things a tad literally. This is solely for RGB reconstruction, and the above can be trivially accomplished with a spectral input.
The display is a creative surface where insisting that the colourimetry be taken absolutely in all cases seems a bit iron fisted. The relative adaption is a legitimate creative point.
I’m basically thinking of maximum backward compatibility here.
And as said, I don’t consider the current spectral upsampling to necessarily be final. It might even be worth to provide different models for different situations. It’s a thing that can be gradually expanded upon, once the option exists. - Either way, having the distinction is a good idea, I think.
For actual light sources you put in the scene, sure.
For, say, HDR image based lighting though? Such workflows need to continue to work in a sensible manner.
I have been thinking about this, I don’t think it makes sense. As far as I know, the Asset Browser is a local .blend file reader that reads all datablocks marked as “asset” of the .blend files in a certain folder on your hard drive. I don’t understand how spectral cycles is going to use that as an official spectral material library. I mean, you still need to download the .blend files and put it in the folder for it to work, right?
It’s supposed to be able to search network blend files as well
Oh it would be cool, didn’t know that, thanks
Those are governed by the encoding, and everything works in accordance.
I just saw this today: https://developer.blender.org/D10978
The spaces are defined as empty classes. The idea is that they will be extended to add
metadata like white points and CIE 1931 coordinates of the r,g,b components.
Will this help with the white point problem we discussed ealier?
No it won’t help.
There isn’t really a problem.
So, Cycles X, how does it affect this effort?
I’m yet to look fully into it. It might make things easier, it might require a rewrite of the spectral changes (I really hope not), it might make things much harder/impossible.
A new build based on Cycles X is up on GraphicAll. Spectral rendering itself should be on par with the previous build. Additional features like spectral nodes or custom wavelength importance sampling won’t be included anymore. The focus now will be on polishing and getting this ready for review and merge.
Known bugs/limitations in this build:
Also, 4 wavelengths per ray are now used instead of 8.
The previous build can be downloaded from GitHub.
Great news! Really hoping this makes it into master with 3.0 or, if Cycles X does not happen to land in 3.0, with 3.1.
Incredible work on getting this running. Can’t give you enough praise for the awesome work you’ve put into it despite my quietness around it lately.
Based on Cycles X?! Previously it was asked on this thread what impact Cycles X would have on Spectral Cycles, and the answer was
I took that as “not sure”
So now the build is based on Cycles X, is it now safe to conclude that Cycles X does not negatively impact Spectral Cycles’ development?
Also so excited to see that it has hope to be merged in 3.0 with the extended 3.0 release date, such a good news!
I wasn’t sure, but it turns out @pembem22 got it working - I haven’t been able to dedicate much time at all to this recently but Pembem22 has pushed things forward by themself.