Robert Kooima

In the summer of 2008 the Adler Planetarium hosted the annual meeting of the International Planetarium Society. At that time I had been working on a number of visualization projects with Adler staff, including the installation of a cluster of Linux PCs in the Adler’s digital dome theater. Our goal was to explore ways of generating custom real-time content for dome shows, which were (and largely still are) limited to the playback of pre-rendered movies.

I had prior experience with real-time dome rendering, having done early work with programmable GPUs in a 4-meter dome at NASA Langley Research Center in 2002. I had spent my years in Chicago adapting real-time visualization code to a wide array of display technologies, and the digital full-dome was another challenge in that vein. It was my further intention to adapt my doctoral work to the full-dome display and defend my dissertation interactively in the Adler dome. The convergence of these influences coincided with IPS 2008, and I was invited to present an overview of real-time dome rendering techniques at the conference.

The resulting paper gave broad coverage of real-time display and spherical correction techniques, targeted toward the non-technical planetarium crowd, and intended to teach them a bit about the nature of 3D graphics hardware and its incompatibility with domes. I recently decided to revisit and revise this paper. Here’s the PDF.

I’ve prepared a revised and updated print version of my previous post on Generalized Perspective Projection. Here’s the PDF.

Haskell is a great language, but it’s got a steep learning curve. Most of the Haskell examples and tutorials present trivial programs and, as when learning any new language, the best way to get your feet wet is to try to solve an everyday problem. Unfortunately, if your everyday language is imperative (which it probably is) then Haskell is going to leave you without many of the basic things you take for granted when you get things done.

In my case, I needed to run a computation involving numerical integration using IEEE double precision floating point values, and output the resulting table of values to a file for visualization. Implementing this computation in Haskell was great fun. However, when it came time to store the output I discovered that Haskell’s IO libraries are very much text-oriented. Binary IO functionality was not to be found… [Read More]

For many years, DrScheme has had a nifty feature called “Program Contour” that displays a microscopic copy of your source code along side your editor window. Each character is represented by a single pixel, which allows you to see the entire source file at a glance. This feature doesn’t seem to have gotten much attention, but recently the concept popped up on the radar when this reddit thread and this stackoverflow question pointed toward a similar image and raised the issue of the shape of good code.

I don’t claim to know what good code is shaped like, and I don’t know what impact an awareness of your code’s shape might make on its design, but I think the images are neato and I wanted to see the contour of my current project, which consists of around 34K lines of C++ code spread across 156 source and header files. The means of generating such images was not immediately obvious to me, so I developed the following technique using utilities commonly found on any Unix-like system. [Read More]

Perspective projection is a well-understood aspect of 3D graphics. It is not something that 3D programmers spend much time thinking about. Most OpenGL applications simply select a field of view, specify near and far clipping plane distances, and call gluPerspective or glFrustum. These functions suffice in the vast majority of cases. However, the field of Virtual Reality introduces circumstances under which they fail. This article discusses the limitations of these perspective projection functions, and describes a more generalized perspective projection formulation. Implementation and an example application using OpenGL are provided. [Read More.]

Despite being the easiest stereo technique to view, many people still have trouble viewing cross-eye image pairs. It is a skill that gets easier with practice, and some might need a little push to get started. This page exists to offer advice and explanation which will hopefully help some of those who continue to be baffled. [Read More]

I’ve been writing software for many years, and a number of habits have become ingrained. Among these is a general desire to have as much code on screen as is possible. Moderating this desire is the requirement that all code buffers be exactly 80 columns wide. Setting up a development environment that meets these needs is one of the first things I do with any new system. Recently, I got set up with a Macbook Pro. [Read More]

This article discusses a means to reduce the problems of near clipping distance and depth buffer precision by foregoing the usual near and far distance specifications and reformulating the perspective projection transformation in terms of the median of the scene. The result is a short GLSL vertex function that allows geometry to be transformed and rasterized arbitrarily close to the viewpoint, while maintaining an affordance needed by applications to influence depth buffer utilization. [Read More]