Mario Marengo, on Nov 24 2006, 08:51 AM, said:
what if, as a hack, we went RGB->HSV (where the [0,6/7] range in (1-H) represented the ~440-to-780nm range of the xy chromaticity locus), and just use S directly for saturation... how much inaccuracy would we be introducing? and is it acceptable given that it would be a lot faster?.... I didn't have time to look into it, but maybe youcould experiment a bit?
I guess there are some good reasons people have tried such complex aproaches. Your proposal seems very intresting too however. Basically we'd convert RGB to HSV (this should be safe to do). Now we could try to map hue to wavelength. We'd sort of open up the HS/circle... and now use a distribution function such as the gauss one around our dominant wavelength and stetch the curve depending on our 'S' value. At the same time we'd ensure the area below the curve remains '1'. Now from that spectrum we could do wavefrequency sensitive caluclations and take as many samples as needed. We'd have to do a bit juggeling around the borders (~400 and 700 nm). But with such weighting we could have sharp peaks for hightly saturated colors and nice soft curves for less saturated ones.
We'd do something like this:
From the wavelength spectrum back to rgb could be done either directly according to CIE (now we'd notice if we have introduced any mistakes) or calculate the new centroid of our spectrum and arrive in rgb space via HSV using our H --> f mapping as done before. At least the later method would have the advantage that if we have no changes in the spectrum we'd not introduce an error and it's obviously faster.
Physically this is undoubtly wrong, but we'd have some nice interpolation and the main reason for entering the spectral color space is to avoid those 'gaps' we have when working with only 3 samples --> we want a spectrum with multiple samples. All models are approximations anyhow and besides we start with rgb colors in the first place --> are wrong by default
At least are limited in representing colors.
If we allow the input of an frequency spectrum directly for the shader for something more accurate we'd not have to worry about getting a spectrum in the first place. (Guess it shouldn't be that timeconsuming to write a small app that allows to draw a spectrum with rgb color feedback, safe it as texture --> Houdini). Guess this would be a nice option. The core algorithms wouldn't need to be altered.
Update: Did a bit of reading and those color conversions as suggested by Y.Sun are very fast. You just need to carry around a few tables with the pre-calculated data. If there is a good reason to have more then 6 frequency samples I assume it's a fair choice. The fourier approximation from here
that has been implemented in your glass shaders equals the one from Sun (if you make a few assumptions and simplifications. In that paper the derivation is a bit short). The one currently implemented has a rather distorted sin wave while Sun's version is 'properly' made. Once you have any dispersion effects the one currently implemented gets increasingly inaccurate. But more importantly if there are no such effects the transformation to rgb introduces no new errors due to transformation inaccuracies.
Sun's version though has always this small error margin... so even if there is no dispersion at all, due to that error we'd get a color shift!
For iridecense effects this doesn't matter much.. but I don't think this is exceptable for any sort of glass shader. Likely to make this properly you'd need some sort of least square fitting --> too slow.
The members of the Guild of Assasins considered themselves cultured men who enjoyed good music and food and literature. And they knew the value of human life. To a penny, in many cases. (T.P.)