I have now read up to chapter 4 of that paper and can say it is definitely the most comprehensive summary of all of the spectral upsampling methods I am aware of. It also covers a lot of other related topics in an approachable-as-possible manner; it’s a truly priceless resource for anyone who wants to learn about the topic.
5 Likes
Reading the last chapter in that linked PDF, I came across a quote which made me smile. Although I’m sure they worked hard to ensure this was the case, I think this is a suitable reason to start the transition to a more spectral-aware workflow.
Finally, given that the overhead of rendering spectrally is essentially a rounding error
in the sort of scenes we render, why not use the most accurate colour representation
available?
This is referring to Manuka, Weta Digital’s in-house spectral renderer. The last line in the PDF then says:
The overhead of uplifting from RGB to spectral is negligible compared to shading and
light transport in a typical production scene, so we firmly believe the right question isn’t
“why should we go spectral?”, but “why not?”
Great read. Thanks again @lorenzoangeli for posting it.
16 Likes
Most scenes can be rendered now, but somehow if the scene contains a portal light:
Or if your scene uses the sky texture node:
It would still throw errors to me:
1 Like
About the greenish tint in the spectral result, I don’t know whether it is caused by some bug in wavelength important sampling or the currently not-so-perfect RGB to Spectra conversion, but I tried to match the result in the compositor with the “Difference” Blend mode on. I am not sure whether I am doing this correctly, if not, please tell me where I did it wrong.
I used two scenes in one file, one rendered with Spectral switch on and the other one off. The two scenes have nothing but pure white world background. Then I used the compositor to try matching them. I consciously chose to use divide, so that the result I get can be directly apply to the white level under the color management section. So I got this result:
I tried my best to match them, you can see the output is not pure black, but I think it is close enough. The result is [0.9614, 1.02, 1]. So for now, if I want to get rid of the spectral greenish tint, a temporary workaround is to either do this in the Color Management panel:
Or do it in the compositor, so that you can turn the “use nodes” on and off in a per render slot basis for comparison:
Again, I don’t know whether I did this correctly, I might be completely wrong.
Here is a test scene:
First the unadjusted Spectral result:
Then the RGB result:
Then the adjusted Spectral result:
I think the adjusted one gets pretty close now.
Multiplying the channels isn’t quite the correct operation to be doing here but for now it’s probably close enough. If it reduces the difference in simple scenes, it’s useful as an interim method of comparing the two.
1 Like
The hair bsdf is still busted right?
RGB (regular Cycles, non-X)
Spectral (latest build)
Sorry about the background, that’s meant to be transparent and I guess converting to jpeg makes it white but the more important part is whatever the heck is going on with that bottom half in the spectral version
This txt is actually a blend (you may want to lower the render settings to get faster results. I maxed out the bounces)
fuzz test.txt (1008.4 KB)
1 Like
That’s right, I haven’t figured out what’s causing that yet.
In the viewport I don’t get it apparently, but also, I got another memory error:
But rendering the final result gives me this
Hallo everybody,
I have stumbled across this forum/thread when looking for ways to simulate the appereance of dyed plastic foils. Reading through the thread, I find it amazing to see the development of this renderer!
I’d like to consult you about the application of spectral Blender for the simulation of laminated, dyed plastic films (dyes evenly distributed). Imagine a stack of two layers (some red and some blue dye beeing used) for which both the transmittance spectra and film thickness are known.
- How is a read-in spectrum curve (suceeded to do this and assign it to volume absorption nodes) related to the thickness of the assigned volume (layer thickness) by spectral Blender?
E.g.:
Do I need to read-in the spectra of 10 micro meter thick films and build them with the same thickness in spectral Blender? Does changing the thickness of films in spectral Blender change the absorption of the modified layers by Lambert-Beer’s law?
Thanks a lot for your help!
1 Like
Hi @chrw, thanks for the comment.
This is a perfect application of spectral rendering - great to see people working on projects like this.
There are two approaches here:
- Set up a volume absorption spectrum according to your dye and measure the transmittance through a solid object
- Create a plane which contains a transparent BSDF which you assign a calculated transmittance spectrum to, accounting for the depth in the calculation of the total transmittance.
As you’ve pointed out, volume absorption depends on the thickness of the volume, I believe it transmits the specified colour after 1BU of volume when the density is 1.
If you aren’t looking at spatially varying effects such as different transmittance due to ray length at grazing angles, I think the second approach will be simpler and render more quickly. You simply take your transmittance spectrum (which is calculated based on some reference depth) to a power equal to the multiple of the reference depth which you wish to calculate. For example, if your transmittance spectra are specified for transmittance through 10 micrometers of the material, and you want to view how it would look through 50 micrometers of the same material, you simply raise the transmittance spectrum to the 5th power.
As for how to get a tabulated spectrum into the material editor, the tedious way is to create a spectrum curve node and manually specify the points, but I believe @pembem22 might have previously built a script to load in files of a particular format as a spectrum curve node. Will need to wait for him to clarify that.
I hope that helps, and please post your results here, I’m curious to see what you find!
2 Likes
@smilebags
Thanks a lot for the input, I’m going to try things out later today. It will take me some time - discovered Blender only a few days ago.
I have sucessfully used the plugin prepared by @pembem22 reading *.csv spectra. Could it be an option to integrate an input field therein for the film thickness in some metric unit? Maybe it could also be specified in the first line of the *.csv file.
@pembem22
Is there a way to use your plugin via the script window (load *.csv spectra and assign it to nodes via Python)?
Hi, I modified the script to support the usage as an operator. Change the extension of the file to .py and replace it in the 2.93\scripts\addons directory.
import_spectrum_csv.txt (3.5 KB)
Here’s an example of usage:
bpy.ops.node.import_spectrum_csv({}, 'EXEC_DEFAULT', False, filepath="C:\\path\\to\\file.csv", ignore_top_rows=2, spectrum_column=3)
It’ll add a new node to the active material of the active object. You can change both programmatically. The node will appear as the last one in the list of nodes of that material:
As far as I understand, the first three arguments are necessary for every call of any operator, but I’m not sure what exactly they mean.
You can also see all available parameters by pressing TAB when you start entering arguments:
You can write a custom script to import additional information from *.csv files and add the “Value” nodes with corresponding values to the node tree, if that’s what you mean.
Just saw a news in the render meeting notes and I think I may mention it here
It seems Cycles X will be merged to master around September 20, and it is also mentioned that this is probably when " the 3.0 like merge window is likely to close." Don’t know how Spectral Cycles X is doing but if we are still not ready I guess we can wait for 3.01 3.1 or something (not sure about the version naming in 3.x series). (Just checked the previous blog post, next version is 3.1)
1 Like
Any news here? This came so far, I hope it hasn’t just died now…
1 Like
Hi @kram1032, definitely not dead. There hasn’t been many updates since we have all been busy on other things (for myself, my day job has demanded a lot more of me lately) but the hope is to get a spectral ‘core’ merged after we iron out some issues with colours not matching where they should, and after we ensure feature parity with regular Cycles X. A new spectral upsampling method which @pembem22 has worked on recently seems hopeful but has posed some challenges.
I’ll spend some time with the existing sRGB primaries upsampling method to see where the issues are - if we can solve them, I think it would be worth merging with that method, then looking to replace it with the more advanced method later.
24 Likes
Hi, @smilebags is right, it’s not dead. I’ve been working on a new spectral reconstruction method based on the implementation from the colour library. It’s not perfect yet though as there are artifacts in certain cases. Also, there have been lots of improvements to Cycles lately, but they cause merge conflicts that take some time to resolve and may accidentally introduce new bugs.
So the main objective right now is to fix bugs and make spectral rendering compatible with all Cycles features.
20 Likes
A question, when I am digging the past posts on this thread, I have come across things about @troy_s talking about a Spectral version of Filmic with proper gamut mapping for solving the out of gamut blue turning purple problem. And he once said this
This was a post from last year. I vaguely remember back then Filmic was not present in the Spectral branch at the time (I hope my memory is not wrong), so I am sort of confused about it’s current status, is Spectral Filmic with proper gamut mapping still WIP or is the Filmic currently in Spectral Cycles X already the Spectral Filmic? If it’s WIP do we have any hope that it might make it along side with the initial “core merge” that smilebags mentioned? If the current Filmic is already it, why do I still see the blue to purple effect? Does it has to do with the Spectral Reconstruction as well?
This is quite a complex topic. Simply put, the Filmic in the spectral branch is still the regular Filmic, and because we are feeding it input it wasn’t designed for (wide gamut) it will show some issues that are usually non existent in regular Filmic. It is still significantly better to use Filmic than not.
5 Likes