Octane Render How To: RGBSpectrum vs GaussianSpectrum
Which one do you prefer? Not sure? Don’t care? See why!
It’s a beautiful Monday morning. You are starting to feel the little rush after that first sip of good, strong coffee. It makes you feel like you got your shit together. You don’t, but it feels like it! A few unread e-mails in your inbox. Let’s see – social media notifications, a newsletter you never signed up for, new drugs that will make your sex life better, a new render by beeple and oh, wait, a job offer! Subconscious images of self-knitting Nike shoes, shiny car renders, explosions, transformers, or whatever else you define as “cool”, all projected in front of your eyes as you anxiously open that message.
“Hello, can you make me a red, glowing, neon tube?”
“For the love of mother and child!” As usual, you go scream into a pillow for 5 minutes. Better? Better! You know, every little project gets you one step closer to that awesome job you’ve been waiting for all your life. And so, you go with the freaking neon tube. Doesn’t take long before the first test render is complete:
Standard workflow – an Octane Material (with no Diffuse color) and Texture Emission. You assign an RGBSpectrum and reduce the watt power down to 1. Confidence starts building up again and you are secretly thinking that, with that skill set, you should be working at ILM. Nevermind, back to work.
Client feedback comes in and it goes like: “That’s cool and all but.. can you make it much, much brighter. We need more light!“
“Bah, that’s easy!” you say and pump the power up to 200!
“Crap.. What the hell is that?! Magenta? Noise? Fireflies? I am doomed!” And just before you start crying (usually online) how broken Octane is, swearing “I’ve never had these problems with V-Ray” and so on, you remember something important. Render engines do NOT really like “extreme” values like 100% black, 100% white, 100% saturated, 100% glossy etc, you get the point. Looking back at your RGBSpectrum – it’s 100% red with no information in the Green and Blue channels. That can’t be good. Wisely, you introduce some variation to break the perfect red.
“But, but, but.. where did my red go?! Why is this white? I am so confused. God, why do bad things happen to good people? That’s it, I am installing Arnold!”
To explain the behavior of RGBSpectrum, we need to understand (or at least have some idea) how the engine treats light. The way Octane renders the scene is via a method, called “Spectral Rendering”. This means, simulating light sources and object surfaces is done based on real-world wavelengths, as opposed to the more widely used RGB method. The resulting images are closer to real life, more precise and easier to clean up. That’s the essence really.
So, “What does this have to do with anything?” you may be asking. Well, it’s now obvious that the output of RGBSpectrum cannot be used directly for sampling. That’s why, internally, the engine converts RGB colors to their closest wavelength equivalents. Note, however, translating RGB to wavelengths (and vice versa) will never return perfectly matching values. This is clearly visible in the images above. Pushing a 100% red emitter to a power of 200, makes these precision artefacts visible. First, the color was clipped to magenta, then, after injecting values in the rest of the RGB channels – to white. That’s why it is nearly impossible to get the “red, glowing, neon tube”, the client is after, and still keep the light source as bright as it is. Well, not with RGBSpectrum anyway.
What’s the alternative for generating colors in Octane Render? GaussianSpectrum!
Hopefully, it is clear enough that the GaussianSpectrum interface above is used to describe a wavelength value from the spectrum chart bellow. It is worth mentioning that Octane remaps the length of the electromagnetic radiation (ranging from 380 to 720 nanometres for visible light) to a 0 to 1 gradient, labeled “Wavelength”. Mentally translating this to HSL, you can think of “Wavelength” as the “Hue” while “Width” and “Power” correlate to “Saturation” and “Lightness” respectively. This analogy is, most certainly, scientifically incorrect but helps to get the point across.
Alright, lock and load! Let’s try this one more time. Similar settings, just swapping RGBSpectrum for GaussianSpectrum.
Let’s see. Power of 4 watts? Check! Red color? Check! Moving on.
Power of 200 watts? You bet! Still red? Yes sir! The color is holding up much better now. Even if you go nuclear with the intensity of the light (as we did here), values will be clipped to the wavelength set by GaussianSpectrum. No magenta or firefly weirdness anymore. Perfect! Alright, we are back on track. Let’s send this and hope the client likes it!
“It’s red alright. Could you please add some variation? We are loosing detail in that area.”
“Hm..” you think, “maybe the emission could be stronger on +Y facing surfaces and weaker on slopes? Gosh, I am so creative!” One of the ways to achieve that is by swapping the float slider, representing “Power”, for a “Falloff” node. Make sure the mode is “Normals vs. vector 180deg”, set an appropriate “Falloff Direction” and play with the “Skew Factor” until you see distribution of values that you like. Send!
“It’s getting there! Maybe some areas should be “hotter” than other and thus appear brighter? That would be cool.”
Okay, so how are we going to solve this one? We already said that no matter how high we push light’s intensity, values will remain consistent with the wavelength color. Said otherwise, red will remain red no matter what. Reverting back to RGBSpectrum is certainly not an option. So how? “Saturate to white” to the rescue!
The coolest part is that “Saturate to white” is a Post effect. This means it can be applied and adjusted without triggering yet another render. You now have the best of both worlds – you can blow colors up to white or stay true to the wavelength value! Speaking of Post effects – this begs for a Bloom! Client should be happy now.
What’s the moral of the story? If you can get used to it – go with GaussianSpectrum. Cut the middle man (RGBSpectrum) and communicate directly with the mother-ship!
Credit: Shaderball by Raphael Rau. Check him out at silverwing-vfx.de