I thought I’d exercise my left brain a little with this post and write on something a bit more technical. Actually, this was triggered by a chat I had over dinner last night with our 3D graphics development manager and a client. As you may have guessed math is intimately related to computer graphics of all sorts. My PhD thesis so many years ago was on the topic of creating funny surfaces that smoothly join two complex surfaces with a relatively small number of shape control parameters: such surfaces are called blend surfaces. This required the development of a bunch of algorithms that related either implicitly defined surfaces (i.e. f(x,y,z) = 0) or parametrically defined surfaces (i.e. each point is defined by the triplet (x(t), y(t), z(t)) ). That was twenty years ago and I always thought that any problem that I was wrestling with would have been resolved twice over by now. My ego was pleasantly surprised that indeed such problems are still the stuff of heated debates and vigorous research.
The basic engineering problem is pretty simple. Parametric surfaces which are excellent for creating free-form complex shapes are the de facto standard in surface modeling systems (names like Bézier, B-spline, NURBS are famous examples of such surfaces). But they generally require often hundreds of “control points” or shape parameters, and any modification you may wish to do for engineering reasons required extremely tedious and time-consuming manipulation of these points. Conversely, implicit surfaces (e.g. spheres, cylinders, planes, etc.) are much simpler in their mathematical definition and management but lack the expressive power of parametric surfaces. So my research group looked into developing more elaborate forms of implicit surfaces with still manageable numbers of parameters (maybe an order of magnitude fewer) but with “good enough” shape control.
The original motivation was from an aircraft manufacturer. On one of their models, a particular surface had so many control points that a single change (regardless of how subtle) would take literally a few months to implement. So they established a relationship with my university and we began exploring both mathematical and computational techniques to resolve this challenge. The computational side for us was Maple. It was, and still is, the best system for manipulating polynomials, rationals, and implicit equations (i.e. the bread and butter of computer graphics) and its programming environment allowed for very quick prototypes of algorithms.
In the end, I did not solve the world’s problems … and our aircraft manufacturer got acquired twice after flirting with bankruptcy. I’m pretty sure that my work had nothing to do with it. But I fondly reflect on this application of symbolic computation because it is yet another example where a robust symbolic platform simplifies the task of managing your algebraic information and buys you time to explore various analytical options. In many ways, the techniques emerging with the latest generation of symbolic systems such as Maple 12 and MapleSim continue to carry this theme and continue to extend the potential of rich mathematics in modern engineering. In the process, they make solutions more accurate, and more manageable, and for the purists among us, even elegant.
Today, Maple (and soon MapleSim) is widely used in the aerospace industry and also by the computer graphics industries. Many animation houses continue to use Maple to explore new surface types; compute generalized trajectory models for animated characters to fly through the air only to run flat into a brick wall; or figure out what kind of liquid flow representation would look like a menacing wave of water ready to annihilate a colony of ants. In fact, math is becoming important in the entertainment biz more than in many industries where you would expect math to dominate … go figure.
I’ve attached a simple example of blending algebraic surfaces using Maple 12. I was pleasantly surprised that after 20 years, I was able to lift code out of the dusty pages of my thesis and the thing worked … actually it worked much better because we now have nice lighting models, it is easy to enter math, and computers don’t choke on the required computations. Among the reams of Maple code that I wrote, this super trivial example is really the only one that is replicable here because all of the others were trapped inside subroutines and code files that are now lost to the ages. If only someone could invent a system that could actually capture complex mathematical information in a live document format that seamlessly combined both the computation and the thinking behind the application … but that’s a topic for another posting :-)