> I do expect benefits in all areas that include colored distance-based
> attenuation, such as with fog, absorbing media (including the extinction
> effect of scattering media) and interior fading.

Won't it also vastly improve any scenes where the "light" is not 
broadband, eg street lights, LEDs, lasers etc. Would fluorescent 
materials be supported?

In theory colometrically correct renders could be produced which I 
imagine would open up new markets for POV use (especially if combined 
with an unbiased tracing option). We need something to keep increasing 
those render times to keep up with new hardware :-)

Post a reply to this message

Am 17.04.2013 11:42, schrieb scott:
>> I do expect benefits in all areas that include colored distance-based
>> attenuation, such as with fog, absorbing media (including the extinction
>> effect of scattering media) and interior fading.
>
> Won't it also vastly improve any scenes where the "light" is not
> broadband, eg street lights, LEDs, lasers etc.

I guess so. Though I suppose such scenes are rather uncommon (especially 
Sodium street lamp scenes tend to look ugly ;-))

> Would fluorescent materials be supported?

Not right from the start, but it's a possible option for the future.

> In theory colometrically correct renders could be produced which I
> imagine would open up new markets for POV use (especially if combined
> with an unbiased tracing option). We need something to keep increasing
> those render times to keep up with new hardware :-)

:-) Don't worry, we'll find something :-)

Post a reply to this message

> > I do expect benefits in all areas that include colored distance-based
> > attenuation, such as with fog, absorbing media (including the extinction
> > effect of scattering media) and interior fading.
>
> Won't it also vastly improve any scenes where the "light" is not
> broadband, eg street lights, LEDs, lasers etc. Would fluorescent
> materials be supported?

Yes, it will give more physically correct render for strange lights. But the
most important aspect of spectral rendering is more "natural" color behaviour.
The problem of rgb illumination model is that the primary colors are
"orthogonal". So when you say "blue", and "red" they have absolutely nothing in
common. So a red light will give no illumination to red object, and red and blue
objects will have no radiosity effect on each other at all. This is a bit
unexpected usually - you put a primary colored object in a scene, and it seems
almost monochromatic, even if you have reflections and colored lights in a
system - it does not "take" other colors. So in essence, radiosity has too
strong contrast, colors are too sharp, and primary colors don't mix well.

I usually "fake" color overlap by having colors such as <1,0.1,0.1> for red and
so on. But it's not the same. Only spectral rendering will give you true
richness of color - you can have a pure intense color, but it can still react to
environmental illumination in a correct way. A typical example is a car in a
street.

Spectral rendering gives you subtle differences that you don't notice, but you
do notice it looks better. Just like focal blur, HDR environment mapping and
difference between flat ambient and radiosity.

> In theory colometrically correct renders could be produced which I
> imagine would open up new markets for POV use (especially if combined
> with an unbiased tracing option). We need something to keep increasing
> those render times to keep up with new hardware :-)

Sure :) But in this case, I don't even think it will affect the render time that
much. Most of the rendering cost is the raytracing (finding intersections and
normals). Color computation is only a small part of the process, so unless you
have color dispersion in refractions and reflections, you will get a small
overhead (especially if the C++ core behind it is written efficiently).


About flourescence: it seems like a very nice idea. But somehow this opens a
wide array of options (every spectral input color could potentially produce a
different output color of different intensity). It smells more like a
custom-made shader. Having a pigment that is actually a function of input light
color, direction and coordinates, would make more sense in this case, and would
allow flexibility for users to design funny materials (like angle-dependent
colors, fluorescence, anisotropic BDRF functions, color-dependent specularity
angle and possibly a nonlinear response). This is quite a lot to ask from
developers, but it would get easier, if LLVM support actually happens at some
point in the future.

Post a reply to this message

> Yes, it will give more physically correct render for strange lights. But the
> most important aspect of spectral rendering is more "natural" color behaviour.
> The problem of rgb illumination model is that the primary colors are
> "orthogonal". So when you say "blue", and "red" they have absolutely nothing in
> common. So a red light will give no illumination to red object, and red and blue
> objects will have no radiosity effect on each other at all.

This is what happens IRL though, isn't it? An sRGB red light source will 
have a very narrow spectrum and almost no overlap at all with the 
reflective spectrum of an sRGB blue surface, so it will appear black.

I always avoid zero terms in rgb colours too, not because I'm trying to 
fake anything but I think it is genuinely more realistic for natural 
surfaces and lights.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> This is what happens IRL though, isn't it? An sRGB red light source will
> have a very narrow spectrum and almost no overlap at all with the
> reflective spectrum of an sRGB blue surface, so it will appear black.
>
> I always avoid zero terms in rgb colours too, not because I'm trying to
> fake anything but I think it is genuinely more realistic for natural
> surfaces and lights.

Mostly, a colored light means a tinted glass, which has a broad spectrum (except
for LED). And even if you do have such a light, the material you are
illuminating will certainly not have a narrow reflective spetrum. If you
illuminate with a red light, you will usually be able to get some red component
from a blue material, especially since there is no blue reflected light to
overshadow it. I'm not saying the effect is strong, but it is enough to create
more natural lighting. You can approximate this by just having nonzero
components, but spectral response gives you more flexibility.

It's also easier to get a realistic illumination with different color
temperature light sources. For instance, a dim tungsten light looks quite
orange, but if you just use rgb, you don't notice, that the far-spectrum blue
light is extremely dim - most of the "blue" component comes from more central
wavelengths. This will affect appearance of blue surfaces.

Post a reply to this message

> Mostly, a colored light means a tinted glass, which has a broad spectrum (except
> for LED).

It is incorrect to model such a light as srgb <1,0,0>. It should be 
modelled by something like <1,0.2,0.1> as you suggested. That isn't a 
fake or a hack, that's the sort of srgb value you would get from a broad 
spectrum light if you measured it with a colour meter. You'd only get 
something like <1,0,0> if you measured an LED or laser.

> And even if you do have such a light, the material you are
> illuminating will certainly not have a narrow reflective spetrum.

Same as above, you shouldn't be modelling surfaces with a colour of 
<0,0,1>, that corresponds to an extremely narrow reflective spectrum 
that doesn't normally occur IRL.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Yes, it will give more physically correct render for strange lights. But the
> > most important aspect of spectral rendering is more "natural" color behaviour.
> > The problem of rgb illumination model is that the primary colors are
> > "orthogonal". So when you say "blue", and "red" they have absolutely nothing in
> > common. So a red light will give no illumination to red object, and red and blue
> > objects will have no radiosity effect on each other at all.

> This is what happens IRL though, isn't it? An sRGB red light source will 
> have a very narrow spectrum and almost no overlap at all with the 
> reflective spectrum of an sRGB blue surface, so it will appear black.

OTOH if you have eg. a pure yellow light, it will look to the human eye
the same as a light with red and green frequencies in appropriate
proportions, but they will illuminate surfaces in radically different
ways. (White surfaces will look about the same under both lights, but
eg. red surfaces won't.)

-- 
                                                          - Warp

Post a reply to this message

>> This is what happens IRL though, isn't it? An sRGB red light source will
>> have a very narrow spectrum and almost no overlap at all with the
>> reflective spectrum of an sRGB blue surface, so it will appear black.
>
> OTOH if you have eg. a pure yellow light, it will look to the human eye
> the same as a light with red and green frequencies in appropriate
> proportions, but they will illuminate surfaces in radically different
> ways. (White surfaces will look about the same under both lights, but
> eg. red surfaces won't.)

The difference with yellow (or any colour other than pure red, green or 
blue) in the current RGB system is that it needs at least two non-zero 
components (R and G in this case). This means it will illuminate any 
surface with a non-zero component in R *or* G in this case. The effect 
of this is to simulate a relatively broadband spectrum - only surfaces 
with R *and* G zero (ie a pure blue) would appear black.

Obviously this is a limitation (that no colour other than the sRGB 
primaries can be simulated as a narrow-band spectrum) - which is what I 
meant when I suggested that spectral rendering would improves scenes 
with narrowband lights (or even lights with an "interesting" spectrum).

Post a reply to this message