The big “get” is that it gives programmers access to hardware-accelerated graphics from directly within the browser. There’s a lot of interest in this arena for game development as it would obviate much of the need for separate distributions based on operating system. (Skip to the end for more of an opinion on this subject.)

As such, I’ve been working with WebGL as opposed to the Google-proposed O3D. (I have every intention to explore O3D, time permitting, as there are some jagged edges to the current specification.) The result of this recent toil is a budding WebGL implementation of my OpenGLot project. It’s still in early stages, but in the coming weeks, it should develop even further. To whet appetites, I have a few pictures.

A scalar field, my persistent test function.

A 3D surface, again one of my usual test functions.

I seriously doubt that WebGL will every match the performance of OpenGL. Even though JavaScript interpreters are getting faster at a somewhat alarming rate, they won’t match the speed of C or C++. That said, if one can appropriately offload work onto the GPU, it won’t matter as much, but there will always be that overhead.

It won’t so much be a matter of having the same performance, but enough performance. If a person can go to a single webpage and get 60 frames per second performance in a game or tool without having to install software, that’s tremendous. Currently I’ve been getting between 60 and 90 frames per second with WebGLot, and I’m sure I can keep that number up as more features are added.

My hope is that this will be a tool and library that has a wide-enough feature set by the time WebGL is widely adopted that becomes often-used. But that’s just ego. The purer motivation is that if you’re a math teacher, and you want to have interactive demonstrations of Newton’s method, or parametric surfaces, or even flow fields, you can write an application in 20 minutes that does all the heavy lifting of graphing it for you. As long as you can describe the mathematical primitives, you should be able to render it. Of course there will be a general-purpose grapher available for any calculus student who’s having trouble visualizing this or that, too. Or a resourceful PDE student who need to solve his homework (the GPU-based PDE solver will take a little bit more time, but it’s very nearly complete).

In short, the strength of WebGL is that is has respectable performance, and in a year’s time, half the browsers (well maybe not half) on computers will support it, giving the average internet-user access to a wealth of media.

And they support time dependence.

It can plot virtually any function in x, y and t, and on my MacBook with its NVIDIA GeForce 9400M it has been getting 10k+ fps. I’m still a little surprised by this number, but it seems to be running at that speed.

Flow (vector) fields appear as advected dye. They're currently streamlines, but in the near future I hope to support streaklines and particle flow as well.

Scalar fields appear as a mapping of height onto color. If this function were to be plotted in 3D, it would like a sheet rippling, but sometimes it's more useful to see it in 2D.

On of the great thing about implementing this on the graphics card is that it doesn’t require much CPU time on the machine running it. Even at 10k frames per second, my MacBook never uses more than 30% of a single core’s time. A place where this particularly shines is on tiled displays – a bunch of HDTVs tiled together to run as if it were one large screen. In such setups, a computer will control 2-4 screens, and each computer’s graphics card has enough power to run the animation for its portion of the screen. There are still some bugs to be worked out, but I ran a proof-of-concept on one of the tiled displays at KAUST.

Running a demo of OpenGLot on a KAUST tiled display

Lately I’ve been working on getting the 3D analogs of the various 2D primitives working, again all with time dependence (it’s the support for animation that really makes this shine in my mind). So far it’s surfaces, parametric curves and surfaces and flow fields, but the flow fields have some work yet. It turns out that while modern hardware is definitely capable of handling 3D flow fields, it doesn’t actually make much sense when you see the result – it’s just too busy. To be able to easily visualize flow in 3D is very much an open problem.

3D streamlines end up just becoming confusing more than they are helpful.

In order to get some interesting shapes working, I had to add support for cylindrical and spherical coordinates which is actually providing an interesting challenge – how best to generate the shaders. The shader source code (that runs on the graphics card) is generated and compiled when you run OpenGLot, and I’ve not found an altogether easy and intuitive interface for adding simple coordinate transformations to it. Still, it works, but the programatic interface will likely change.

This is a torus of sorts, which I got as an example from Grapher.app

This is the same torus, just colored by using its surface normals as RGB values

In order to determine surface normals (which are something usually determined when one defines the geometry of an object), the vertex shader approximates various derivatives numerically. So far, the shading results have been pretty decent.

A trigonometric function, colored by mapping the surface normals to colors

The superimposition of two trigonometric functions, lit based on their surface normals and a texture to give visual clues about distortion

I’m still working on making video of this in action available, but so far a number of the tools I would usually use have come up short. I’ve been trying to integrate a video encoder into a utility library for OpenGLot so it can record video straight out of the box, but the framerate is still too low.

At any rate, I originally wrote in Ruby, but have been slowly porting it to C++ with high hopes for its use and applicability. I still have a bunch of interactive demos for numerical methods (from Newton’s method to the trapezoidal rule for numerical integration) in the Ruby version, but I’ll be bringing those to the C++ version one of these days. I started a sourceforge project for it a while ago, which was kind of exciting.

At any rate, as a brief (albeit nerdy) respite from the academic onslaught today, I added a class for parameterized curves.

A demo of a parameterized curve in openGLot

I’ve got a bunch more primitives to add to it (scalar and vector fields, for example), but those will surely come one of these days. I’ve added adaptive mesh refinement (so that “busier” functions require more sampling to get a more accurate visual representation), but I’m still not quite happy with it.

A "busy" function with no adaptive refinement

The same "busy" function with recursive refinement.

I’ve also got a 3D version, but that’s not been polished or formalized, but everyone loves a pretty graph: