GLSL HSB to RGB function

I'm sure it could be optimized, but here it is..



vec3 HSBToRGB(vec3 colorIn)
{

float h=colorIn.x;
float sl=colorIn.y;
float l=colorIn.z;

float v;
float r,g,b;

r = l; // default to gray
g = l;
b = l;

v = (l <= 0.5) ? (l * (1.0 + sl)) : (l + sl - l * sl);

if (v > 0.0)
{

float m;
float sv;
int sextant;
float frac, vsf, mid1, mid2;


m = l + l - v;
sv = (v - m ) / v;
h *= 6.0;
sextant = int(h);
frac = h - float(sextant);
vsf = v * sv * frac;
mid1 = m + vsf;
mid2 = v - vsf;

if(sextant==0)
{
r = v;
g = mid1;
b = m;
}
else if(sextant==1)
{
r = mid2;
g = v;
b = m;
}
else if(sextant==2)
{
r = m;
g = v;
b = mid1;
}
else if(sextant==3)
{
r = m;
g = mid2;
b = v;
}
else if(sextant==4)
{
r = mid1;
g = m;
b = v;
}
else if(sextant==5)
{
r = v;
g = m;
b = mid2;
}

}

vec3 rgb;

rgb.r = r;
rgb.g = g;
rgb.b = b;

return rgb;

}

A case for Interface Builder

There is a lot of hatred for Apple's UI tool Interface Builder among many programmers. I was firmly in that camp but lately have seen some advantages.. Especially as our last project spiraled over budget.

I've released 8 apps without using a single XIB. But the next one I'm planning on relying heavily on the tool. Here's why:

- Design/implement GUI graphically, right brained like you will use the program
- LESS LINES OF CODE to debug, write, remember to think about retain counts and spend dozens of lines setting up, say text field properties
- Less memory management! The whole XIB is loaded/unloaded behind the scenes
- Share the XIBs so DESIGNERS CAN LAY THEM OUT. No more time spent pixel pushing from a PSD comp, the designer will create the VERY LAYOUT U WILL USE! :D
- Less buggy code. IB makes sure you are initializing, configuring and disposing properly. (Not that *I* need that)
- FASTER development of a complex UI. If you have 10+ styled elements on a view, it takes probably 50 lines of code to set them up right. With IB it takes zero.

Now, the shortcomings.. (Rumored XCode 4 with integrated IB might fix some of this)
- Terminology is confusing. Outlets, "File's Owner" etc are never used in non-IB code, so pure coders don't know what they do
- Seems difficult to style/configure certain things. Attaching a UITableViewCell to a UITableView for example.
- The magic of how the elements interact with the code is a hurdle for many at first.

Ultimately I wouldn't recommend newbies using IB. Get a firm grasp on the codez first and then you will see how IB can help you.

Sneak preview music video stills

Topographic Shader V2 and a happy accident

Ever since I first posted the Topographic Contour shader, I have been trying to figure out how to smooth out the lines in that effect. Eventually I came up with the solution to write a function similar to smoothstep() but instead of smoothly transitioning from 0.0 to 1.0, it transitions from 0.0 to 1.0 back to 0.0 over the same input domain. This was perfect for antialiasing the contour lines! I think this function could be helpful in other areas too..

During the development, I came across a strange shader by accident that was actually pretty interesting looking. I called it Disco Snakeskin and it's the last one pictured above (best viewed large). I think there's potential with that shader.

Lastly, I'm still learning a lot about GLSL every day, and graphics/vector math in general as I do. Screen space derivatives, and fwidth() have been on my mind as I see the power it can bring to antialiasing, and special effects. A new rule of thumb will be for every varying parameter, consider what could be done by looking at its screen-space derivatives. I think some crazy effects are possible with this.. And I'm stoked at the possibility of discovering some of them! In fact, overall I'm really stoked on GLSL. After being involved in graphics coding for so long, finally getting into shaders has been like a rebirth for me- once again learning a ton and feeling low on the totem pole. But seeing some of the things people are doing through this technology is extremely inspiring (and a tiny bit frustrating, I'll admit). With that in mind, I've added a column over there on the right side of the blog, containing any brilliant blogs or sites discussing GLSL.

Just an update on what I've been working on the last week or two.. The first image shows studies for a music video I'm working on. The video will feature MIDI and audio triggered/modulated 3D forms and all the shader work I've been cranking on. Pictured are some paper cranes and a 'paper' shader, still very much under construction.

The next image shows the multi-light metal/phong shader I've been working on. The results seem really nice, and about exactly what I wanted. Should be a good basis for other shaders too.

The last two images show screen shots from the latest version of CFGR8R program built for live performance with Plaid, the legendary UK electronic duo. Audio reactive environments feature a hybrid OBJ/Generative geometry engine and lots of different dynamic effects. Here you can see the metal/phong shader in action, as well as a fresnel/Xray shader.

A fun distraction - Topographic Contour Shader

While working on the normal re-calculation for my spherical deformer vertex shader, I got distracted by an idea I had. Thinking about Avatar, and virtually any other movie with high tech 3D displays of terrain, I thought it would be cool to develop a fragment shader to draw the object as stacked countour lines, like those found on a topo map.

I developed a simple version using modulus of one spacial dimension, but the results weren't quite the "wireframe" look I was going for. With the help of this thread I learned about smoothstep() and was able to get exactly what I was going for.

GLSL mesh deformer in spherical coordinates - part 3

Getting closer on properly re-calculating the normals after radial deformation in GLSL. To recap, I built a radial deformer like a jellyfish or spore type form when applied to a sphere. While displacing vertices is fairly easy, re-calculating the normals has been tricky. The visual appearance is getting very close to the phong-shaded deformed sphere I'm shooting for.. However it still isn't perfect.

Since last time, here are the advancements that have brought me closer to the goal:

- Don't normalize any vectors in Spherical coordinates. Since they're measuring angles & radius, a normalization doesn't make sense. This was causing all kinds of crazy problems.
- Cartesian-to-spherical function modified to check for bounds of asin and check hemisphere for atan. Holes in mesh have been fixed.
- Now using the proper built in GLSL matrix functionality.

The current method for calculating normals for deformed vertex is as follows:

- Convert incoming vertex to spherical
- Displace this vertex by 3 component (r, theta, phi) deform function
- Find unit tangent vector U (in Cartesian coords)
- Find binormal vector V (in Cartesian coords)
- Convert these to spherical coords
- Find Jacobian matrix for current vertex (in Spherical coords)
- Multiply U by Jacobian to get U' (transformed unit tangent vector)
- Multiply V by Jacobian to get V' (transformed binormal vector)
- Convert these back into cartesian
- Transformed normal, in Cartesian is normalize(U'X V')


With this method, the shading/highlights still don't look perfect when deformed. I'm almost positive that the culprit is my Jacobian matrix, since when the deformation amount is zero, the object looks perfect: In other words, when the deformation is zero, the whole process of renormalization is still happening, but just coming out identical to the inputs. I'm wondering if my method of simply replacing x,y,z with r,t,p in the Jacobian is legit.. Maybe I have to convert the functions somehow. More reading to come..