We have always thought that oGFx should feature lights, because they open the way to a lot of resources to play with when using textures and shaders. Bump maps, highlights and all kinds of other effects depend on the ability to calculate how light bounces over a particular vertex or fragment, and light in motion is enough to enhance the experience of a digital environment, just because a change in lighting can be understood as a transition between spaces, the passage of time, or both. Control over lighting models is an important feature to consider when thinking about the creation of a language for interactive graphics.
I recently finished the first iteration of glLight support for oGFx , and already experienced a lot of pleasure playing with it in some of the scripts we have made in the past. Following the advice from J. Popovic, teacher of the MIT Computer Graphics undergraduate class, I wrote some code to turn on and off graphical representations of some of the objects in the oGFx context, making it easier to debug otherwise hard to track things like light directions, light positions and surface normals.
Here is a very rough (and I mean it) video where you can see the influence of the light in motion over a scene where I was manipulating an interactive animation I made using quadratic Bezier curves from Apple’s Quartz2D, and here is another one, same degree of roughness, and a different use of the same curves.