Your assumptions are pretty much correct. Unconnected light sources are IE, and the whole calculation is done in spectral (and converted to XYZ for the render output buffer), but then when it is transformed for display, we are adapting IE to D65. This means lights behave as if they were IE, but that will come out as achromatic in the resulting image. Further work could be done on this but it’ll depend on user feedback/demand. Right now I think this covers most use cases.
1 Like
Really cool image by the way. It’s interesting to see that really thin or diluted blood would be yellow, if I’m reading that correctly. Nice one.
1 Like
yup that’s right. You could already kinda see that in my earlier renders where I used absorption
Though this makes that more obvious.
1 Like
Just noticed Open Image Denoiser clips gamut or something. The results end up looking pretty much the same but if you use it, there are no negative RGB values. I wonder if that’ll lead to issues once proper wide gamut support exists.
I would expect a denoiser to only work with known light ratios, as such, I would not expect it to be able to do anything with negative nonsensical light values, given they are… nonsensical in anything other than a purely mathematical domain.
If the denoising is happening on the working space, it would need to clip them or find a useful way to bring those out of gamut values into gamut, as would any compositing. It gets a little tricky, as not all negatives can be considered out of gamut, such as when a resampling on an image happens, where deviations can push channel values negative following the resampling process.
Anyways, I don’t think it should matter, assuming it happens after the software has had a chance to gamut map / deal with negatives in a manner the creators need / want.
1 Like
I’m not sure whether this is a problem of the Spectral branch or a Master problem but I’m trying to build scenes and selections sometimes don’t work and sometimes go utterly haywire (stuff like, when I finally manage to select something, it’s a random collection of vertices rather than what ever was under my cursor)
I’m not sure how to make this reliable or what triggers this, because for a good while, stuff totally did work until suddenly it didn’t.
I did some, what amounts to, pigment-level color mixing, with RGB and CYM “pigments”
Everything within the triangle has individual pigment levels between 0 and 1. All three together always sum to 1. Outside, stuff will no longer make sense, as it may involve negative amounts of at least one of the base colors, making things go out of gamut.
You’re looking at a diffuse plane lit by a uniform white background.
I also provided the exrs in case they are of any use what so ever.
RGB:
https://www.dropbox.com/s/86i1bw7d8qooft3/rgb%20color%20mixing.exr?dl=0
CYM:
https://www.dropbox.com/s/k7umjimmyowwtsf/cmy%20color%20mixing.exr?dl=0
The material looks like this:
And the “Triangle Basis” node does this:
3 Likes
I suspect your selection problem is unrelated to the spectral changes we have made, but if you find it not happening on master while happening on the spectral branch it’s something we can look into. I think it’ll resolve itself with time.
Those pigment experiments are really interesting. Amazing to see how much darker RGB pigments would be when mixed, although it’s completely logical. Fascinating stuff.
I think it’s only “darker” because it only maxes out one color, so each of the base colors already only use half as much of the spectrum as in the CYM cases.
What I find really interesting is how the CYM variant has a region, right at the center where each color is used the same amount, that looks pretty clearly grey whereas the RGB version doesn’t really seem to have a clear grey point. The center looks brown. (although looks can be deceiving. I didn’t measure or anything)
Yeah it does seem to match anecdotal experience. I think it comes down to the fact that the RGB primaries as specta are much less ‘wide’ than CMY spectra. That means as you mix them, there’s much less overlap and therefore less light to reflect. This is a result of the upsampling process that’s happening, though, so it’s likely to have a different reasoning in why CMY is used in printing.
That’s most likely a bug from the master branch. There are almost no changes in the blender part except new nodes UI. You should check if this bug exists in master and report it if possible.
Actually, I have done this already, but it’s much slower right now (10-30x, depends on the scene) and the intensity doesn’t match that from master. I can upload the build if you want.
10 - 30 x slower is insane but I certainly could test it on a simple scene like that.
When you say the intensity doesn’t match, do you mean it’s not artificially darkened?
The spectral sky looks darker compared to RGB or the one from master, both with or without values fix. I’m not sure if I made a mistake somewhere or there’s an actual bug in the Spectrum->RGB conversion inside sky node.
I see. Well either way, I could certainly try
Do you want with the values fix applied or without?
The slowdown is due to removing the precomputation that’s happening in the version which is in master. The plan is to add some equivalent back in to the spectral version at some point.
As for the brightness, I think it can just be left with whatever it is now until we actually go through and verify that it’s correct.
Nice work on the spectral sky work so far @pembem22
2 Likes
Here’s the build https://blender.community/c/graphicall/Fnbbbc/.
You can compile CUDA kernels by yourself if you install CUDA SDK and MSVC. Blender tries to compile them when you enable rendered view and GPU is selected if there are no precompiled.
Heh, I don’t have a graphics card that Cycles likes, but thanks, I’ll try it a bit later
OK this is extremely weird. I’ll have to see how to properly explain what’s going on here.
So yesterday I built this:
Which is a world that Dwarf Fortress generated. I just exported the various textures it offers and composed them until I ended up with that.
The nodes were an utter mess. So I reworked them. Made them as pretty as I could (still not great but at this point it’s quite a complex material)
Now that I finished that:
- The render comes out in completely wrong colors (for instance, a blackbody with 1500K renders blue)
- Occasionally the material corrupts even further. Mild modifications in the node tree (such as unhiding a node) restore it though.
- The file is rather unstable. Constant crashes galore. For instance, I can’t open up an image in the image viewer.
- The weirdest part: If I try to append the material to another file, instead of just the material, I get the entire mesh (with material applied accordingly) imported.
Other than reorganizing the node setup, I changed nothing at all and now it comes out like this:
(The ocean material is unaffected - I can also just append that to another file as expected. So what ever this is, it somehow has to do with this island material)
I suspect it’s gonna be hard to locate what ever this bug is and it might even be multiple bugs interacting (since somehow Append is affected, which seems extremely unrelated), but something is seriously wrong with the current build.
Here’s the node setup for the material.
df pocket world buggy.7z.txt (892.4 KB)
Since you make use of many math notes,i remembered a strange behavior with the math notes a few days ago.If i copyed a math node with shift D and droped the node in a buildnoodle,the math node was inactive.After i selected the function from the menu again the function becomes active.
Here the 3 steps.
1 the copyed node,
2.droping the node and the renderpreview does not change,
