84 replies to this topic

[Jens]

Hi Mario,

I have a simple question on your fourier construction of the colors yellow, cyan, violet.

Your code is

// convert single rgb color to rygcbv
void rgbToSpec6(color rgb; export float r,y,g,c,b,v) {
   float R=rgb.x, G=rgb.y, B=rgb.z, 
		 R2=R*2.0, G2=G*2.0, B2=B*2.0,
		 w = 1.0/6.0;
   assign(r,g,b,rgb*0.5);
   y = (R2 + G2 - B) * w;
   c = (G2 + B2 - R) * w;
   v = (B2 + R2 - G) * w;
}

It looks so fast, nice and simple! However, when looking at the formulas I started writing down for a fourier reconstruction of the wavespectrum it gets a whole lot messier (not equidistant sample points in the first place, calculating all those coefficients...). If you take those coefficients for r,y,g,c,b,v add them together and compute from these values directly it's coresponding rgb value. Is it still the same color (or at least fairly close)?

I guess I'm missing something here , so I'd be glad for any hint.

... time for  

[Mario Marengo]

Jens, on Nov 24 2006, 10:26 AM, said:

It looks so fast, nice and simple! However, when looking at the formulas I started writing down for a fourier reconstruction of the wavespectrum it gets a whole lot messier

The derivation of that model can be found in this paper. It *seemed* to make sense so I trusted it implicitly (namely because it also seems to work as adverticed), but please let me know if you find some flaw with it.

Speaking of simple and fast (and seeing as you're starting to look at spectral representations). I remember back when I was doing all this, thinking "what about HSV?". What I mean is: if, instead of converting to XYZ, then chromaticity (x,y), then finding the angle w.r.t violet (~440nm), then using this angle to index into a lookup table to get the locus position at that wavelength (and thereby the distance to the locus), *then* finally lerping P to find the saturation of the dominant wavelength, then using said saturation value to switch between the Fourier and Gaussian representations (the fact that it's a thresholded switch seems a little awkward as well).... 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?

Cheers!

[Jens]

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?
Cheers!

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.

[jonp]

Hi Mario,

How hard would it be to implement your glass shader as a VOP?  I'm relatively new to Houdini and haven't quite gotten building a VOP myself down yet, but I assume it's possible, using the VEX code you've already written.  Cheers,

Jon

EDIT:  I found the Create VOP command to convert it... sorry for the basic question.

Edited by jonp, 11 July 2007 - 12:00 PM.

[gaucho]

Is this shader working for PBR ?

[stevenong]

Sadly, no. Mario will have to rewrite it for PBR. Well, someone will have to.

Cheers!
steven

[gaucho]

stevenong, on Dec 3 2007, 04:04 PM, said:

Sadly, no. Mario will have to rewrite it for PBR. Well, someone will have to.

Cheers!
steven

Could be good to have it working on PBR.

[Esperient]

This whitepaper is for glass in a real-time engine, but it might be interesting to this thread:

Dynamic translucent colored soft shadows for real time 3D applications

http://www.esperient...SoftShadows.pdf

Enjoy!

Attached Thumbnails

• 

[Mario Marengo]

Esperient, on Jan 26 2009, 03:58 PM, said:

This whitepaper is for glass in a real-time engine, but it might be interesting to this thread:

Dynamic translucent colored soft shadows for real time 3D applications

For real-time, that's very nice indeed. Congrats Michael!

[Esperient]

Mario Marengo, on Jan 26 2009, 08:39 PM, said:

For real-time, that's very nice indeed. Congrats Michael!

Thanks Mario.

If anyone is interested in playing with our shaders, a demo version of Esperient Creator (w/ shader source) can be downloaded here:

http://www.esperient...=...&Itemid=196

(again all real-time 3D no rendering)

Regards,
Mike

[artzor]

hey mario,

has this shader been tested at all in H9.5?

thanks,

[stevenong]

Hi,

I've been using this shader in production for 1.5 years using H8.2 to H9.5 so you can say the shader is tested.

If you're not getting any refraction and reflection in H9.x, go to the shader's Transmission & Reflection tabs and put an "*" (asterisk) into the Object Scope parameter.

Cheers!
steven