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 few months ago, I bought a really nifty input device called “space navigator”. These devices, produced by “3dconnexion”, a logitech subsidiary, enable the user to intuitively manipulate a 3D object or viewport with 6 degrees of freedom (thus commonly refered to as 6dof devices). For instance, one could rotate around a 3D object while at the same time zooming in and slightly panning to the side to inspect a detail hidden there, all in simple fluid motions produced by manipulating a weird knob-looking thing.

3Dconnexion does provide a linux driver, called 3dxsrv, in the form of a user-space daemon. Applications talk to tha daemon and get motion, and button press events from the device, through an X11-based protocol. The problem is: it’s proprietary, and it doesn’t work. Either one of these is problematic in its own right, but the combination demands drastic measures. Thus, I decided to write a free drop-in replacement of the daemon myself. The daemon is called spacenavd, it’s compatible and transparent to any application that used to work with the 3dconnexion driver, and it also provides an alternative non-X11 interface through UNIX sockets.

3Dconnexion also provides a library, called magellan, which is supposed to make interfacing with the daemon easy. Unfortunately, the library is also proprietary (the code is there, but with nasty restrictions in the license text), and is utter crap API-wise. So, I decided to replace the library too, with a free library called libspnav. It’s got an orthogonal much easier to understand and use API, and supports both spacenavd, and the 3dconnexion driver. When working with spacenavd, it can optionally use the simpler alternative interface which doesn’t require an X server to be running or any Xlib code in the application. A magellan source-compatibility wrapper is also provided, to easily port existing applications to the free replacement library, thus freeing them from the shady licensing terms of magellan with zero effort.

The whole project is called “free spacenav”, not very imaginative really, and I just released version 0.2 of both the daemon and the library. You can find everything, and more details on the project itself, at the spacenav website. The daemon is released under the terms of the GNU GPLv3, while the library is available under the 3-clause BSD license.