LittleBell and WebGL

LittleBell is the sweetest user on Rec Room. Just had to say that. Also, her name rhymes with WebGL.

When thinking about porting the Java applet LiveGraphics3D to JavaScript, my first idea was to use WebGL. Support for WebGL by web browsers is not perfect yet, but probably OK. I know basic OpenGL (including basic GLSL) and had looked into OpenGL ES 2.x and WebGL several years ago (when redesigning a course on computer graphics programming); thus, I was not afraid of the shader programming that would be involved. However, when I had a quick look at Three.js, I realized that text rendering in WebGL is probably a real challenge: not only do I need various fonts in plain, italics, and bold versions, but I also need mathematical symbols, greek characters, sub- and superscripts, etc. And I’m not willing to compromise on render quality of text because text labels are a crucial part of illustrations in text books. (That’s a lesson I learned the hard way when implementing dozens of text book illustrations with LiveGraphics3D.) Thus, at this moment, text rendering is a deal breaker for me. Maybe it’s possible to work around this with not too much effort and then I’m happy to look into WebGL again. But for now, WebGL is out.

The alternative to WebGL is to use the 2D context of the HTML5 canvas element. I have some experience with that from my wikibook “Canvas 2D Web Apps;” thus, I’m much more confident that a port from Java to the canvas 2D API is manageable. You might wonder why I even consider the canvas 2D API for 3D graphics. The answer is simple: the Java applet faced the same challenges and I already made my peace with all the compromises that this implies. This port will probably not improve anything with respect to faster rendering or better render quality, but hopefully the porting of the code from Java to the canvas 2D API will be straightforward. At least that’s what I hope currently.

Martin