An anaglyph is a combination of two images into one, in such a way that they can later be separated by viewing the image through appropriately colored transparent filters. The objective is to present slightly shifted views of the same 3D environment to each eye, in order to achieve depth perception (i.e. really perceive the 3rd dimension).

I’ve never dealt with anaglyphs in the past, but during my recent week-old obsession with stereoscopy, I’ve stumbled upon a pair of free anaglyph viewing glasses (made out of cardboard and cellophane of course). So I couldn’t help but try to find out how I can use them with my own programs.

I dug up a small dungeon editor I’ve written some time ago, and hacked stereoscopic rendering into it. I implemented various stereo rendering modes including cross-eyed (side-by side images), quad-buffered (the native OpenGL stereo mode), and anaglyphs.

Quad-buffering is of course the ideal method to present stereo views in OpenGL, but it requires support from the graphics driver and expensive hardware such as shutter glasses or a pair of polarized projectors and polarized glasses.

The problem with the glasses that I’ve got is that all articles regarding anaglyphs I’ve found on the internet talked about either red/blue or red/cyan glasses, while mine was obviously neither. It turns out my glasses are for a new variety of anaglyphs which go by the name ColorCode3D and are supposed to be able to keep more color information than previous red/blue and red/cyan methods (which generally only work for grayscale images).

This color-code thing is apparently patented and there’s no mention anywhere on how to combine stereo images for viewing with color-code glasses. The company who owns the patent has released a program for converting stereo pairs of images to colorcode anaglyphs, which is of course proprietary and doesn’t come with source code, ergo useless.

Then I remembered that there’s an upside to a patented algorithm if you choose to completely disregard patent law, which I definitely do. In order for an algorithm to become patented, it must be described in detail in a patent application which must be filed at the patent office. All such patent documents are publicly available at the web site of the US patent office. So I just got the patent document, and implemented the algorithm from that description.

It turns out the process is extremely simple, although just outside the reach of the OpenGL fixed function pipeline, which can be used to handle red/blue and red/cyan anaglyphs easily by employing additive blending and color masks. To combine the left/right stereo pair into a single color-code compatible image:

• The red channel of the left image is used as the red channel of the output image.
• The green channel of the left image is used as the green channel of the output image.
• All three color channels of the right image are converted to grayscale as follows: , and are used as the blue channel of the output image.

Here’s the small GLSL program I used to combine the two left and right images, previously rendered into two textures:

uniform sampler2D tex_left, tex_right;

void main()
{
	vec3 left = texture2D(tex_left, gl_TexCoord[0].st).rgb;
	vec3 right = texture2D(tex_right, gl_TexCoord[0].st).rgb;

	vec3 col, coeff = vec3(0.15, 0.15, 0.7);
	col.r = left.r;
	col.g = left.g;
	col.b = dot(right, coeff);

	gl_FragColor = vec4(col, 1.0);
}

The result is fantastic, I’m using the space navigator to navigate in the 3D dungeon without taking my eyes off the screen, and the stereoscopic effect is very evident indeed, creating the illusion of depth quite effectively.

Here are a few of screenshots in both color-code and the more common red/cyan anaglyph variety (note that I don’t have red/cyan glasses, so I can only assume that the red/cyan rendering works correctly, I haven’t tested it).

The second one with the jutting pillar is particularly nice. The geometry crosses the zero-parallax plane into the negative subspace, making the pillar seem to “come out of the screen”.

References

1. Paul Bourke, Calculating Stereo Pairs
2. Paul Bourke, Creating Anaglyphs using OpenGL
3. US Patent #6,687,003: Method for recording and viewing stereoscopic images in color using multichrome filters

The original GLUT library used to support some less well-known input devices under IRIX, such as the Spaceball, a true 3D input device which can be used to control all 6 degrees of freedom (3 axis of rotation and 3 axis of translation) simultaneously. Unfortunately, nowadays, the more “exotic” input callbacks of GLUT such as the spaceball are left unimplemented.

So, yesterday I sat down and implemented the missing spaceball bits of FreeGLUT, which is the most widely used free GLUT implementation.

To avoid adding any extra dependencies to freeglut, I just ripped the relevant code from libspnav, which is part of my free spacenav driver project, and added it directly into freeglut.

Here’s the patch against the current freeglut svn head, as well as instructions on how to check out freeglut and apply it.

I’ve also submitted it to the freeglut-devel mailing list, so hopefully they’ll merge it and we’ll have spaceball input callbacks available with the prepackaged glut that comes with any GNU/Linux distribution in the future.

S-ray is a photorealistic off-line renderer I’ve been writting on and off for the past few months. It’s basically a monte carlo ray tracer using the photon mapping algorithm to simulate global illumination effects, such as indirect diffuse lighting and caustics.

So, it’s time to open up the code and continue development in the open. The code is available only through subversion at the moment, no official “0.1″ release shall be made until at least the most important outstanding bugs are fixed. However, feel free to checkout the code and play around all you want.

The project is hosted at googlecode, and you can find it at: http://code.google.com/p/sray
As always, ideas, comments, or bug fixes are more than welcome.

The main feature set that I had planned for my new s-ray renderer is almost complete. The renderer is now capable of producing caustics, that is light being focused on surfaces by curved mirrors or lenses (or otherwise transmission through refractive objects).

Standard recursive ray tracing is incapable of producing caustics; instead a two-pass algorithm called photon mapping is used. Photon mapping works by tracing random photons as they leave the light sources and bounce around the scene, finally ending up on various surfaces. The second pass works just like regular ray tracing, with the difference that on every ray hit, the density of stored photons around that point is used to estimate the amount of light that has arrived there after being reflected or refracted.

Here are a couple of images produced by s-ray, showing both reflective and refractive caustics:

reflective caustics

refractive caustics

I just released version 0.4 of my spacenavd user space driver for 6dof input devices, which fixes some long-standing reliability and ease of use issues.

First and foremost, I cleaned up the code, which started initially as a hack, and ended as an unmaintainable mess. I’ve split and isolated the linux specific parts so that I may add support for other operating systems in the future (specifically I’d like to find the chance to add freebsd support soon).

I’ve also dropped the dodgy 30sec polling cycle to aquire the device if it’s disconnected, which had the effect of being able to use the device at some seemingly random time after plugging it in, and started using the KOBJECT_UEVENT netlink socket to get asyncronous notification of hotplug events from the kernel. Now the device lights up and is ready to use immediatly upon plugging it in the USB port.

More importantly, I lifted the responsibility of notifying the daemon that X has started and it may connect and start listening for X11 clients from the user. By using the excellent inotify API to detect when the X server’s socket is created in /tmp/.X11-unix, the daemon is now able to wake up and connect to the X server automatically as soon as it’s started up.

And finally, now spacenavd actively grabs the device when it starts, which solves the problem of the X server trying to use it as a mouse, without having to resort to messing around with the user’s HAL config files, to make hald ignore it.

To celebrate this milestone release, the free spacenav project now has a newly redesigned web site, which may help attract more attention compared to the previous plain-text web page. Thanks go to cybernoid for the new web site.

My new ray tracer is starting to look good, even though there’s still quite a lot of work to do before its first public release.

Anyway, I was bored today, so I thought I’d upload a video of an early test. It’s a test of the keyframe animation system, and of the motion blur effect produced through monte carlo (distribution) ray tracing, when a non-zero shutter speed is selected.

Here’s a link to the video on youtube.

A long time ago, I stumbled upon a couple of strikingly odd images on Jim Arvo’s web site, which are apparently called “anamorphic”. The idea behind an anamorphic image, is that it’s distorted in such a way, that its true shape can be seen only when viewed in a particular manner. In the case of these images, you’re supposed to print the image and place a highly reflective cylindrical object, such as a chrome pipe, at a specific marked location in order to see the geometric shapes correctly.

I kept the images back then, with the purpose of either finding an appropriate cylindrical object, or raytracing them to see what they look like, but for some reason I’ve forgotten all about them until I accidentally found them again yesterday, in a dusty corner of my filesystem.

So I decided to hack some code to add perfect () cylinder primitives to my raytracer and do a couple of renderings with those images texture-mapped onto a ground quad (I could just do the same thing with another raytracer such as pov-ray but where’s the fun in that?).

So anyway here are the anamorphic images along with the renderings (click on the images for the full rendering):

The third part of my OpenGL graphics programming series for the greek linux format magazine is available for a few days now. So make sure you don’t miss the January-February issue of linux format, if you wish to learn about texture mapping. A technique which, when used properly, can greatly increase the realism of our 3D objects, at virtually no extra processing cost on modern graphics hardware.

This time the accompanying source code for the examples is not included in the magazine’s dvd, so go grab a copy from my website.

Finally, I forgot to mention that the first of these articles is now available for download in PDF format.

Just a short notice, the second part of my “introduction to 3D graphics with OpenGL” series should be available as we speak. This time, we’ll perform the full set of transformations that we described while discussing the rendering pipeline in the previous issue. We’ll use the matrix stack to separate the model from the view parts of the modelview matrix, and render multiple objects properly. And finally we’re going to explain the mathematical model of shading and illumination, and we’ll apply lighting to our object in order to increase the realism of our simple 3D environment tremendously.

So, go and grab a copy of the november-december issue of the greek linux format magazine, and let me know what you think. As always I look forward to your comments, suggestions, corrections, etc.

By the way, due to popular demand, I will upload the first tutorial of the series in a couple of weeks, after the previous issue of linux format goes out of circulation.

I recently started writing a series of introductory tutorials about graphics programming with OpenGL, for the greek linux format magazine.

The articles are written for the complete begginer, who hasn’t had any previous exposure to graphics programming. However, familiarity with the C programming language is definitely required.

What I’m aiming for, is to thoroughly explain the underlying theory, in order to provide a stepping stone for someone who would like to eventually delve deeper into graphics algorithms, rather than just present raw examples for doing this and that with OpenGL.

In any case, the first article of the series will be published in the september-october issue of the greek linux format magazine, which should be available during the next few days. Any feedback, is greatly appreciated.