Deploying interactive Mathematica graphics

Interestingly, Wolfram still supports webMathematica. I was even able to run the Polyhedron Explorer example, which uses LiveGraphics3D 1.92.

Also, I had a look at the Wolfram Demonstrations Project. I like to think that LiveGraphics3D had an influence on the concepts behind this. However, when I tried some demonstrations, it wasn’t a very smooth experience: the frame rate of most of them was below 10 frames per second, the Wolfram CDF plugin wasn’t recognized at first, sliders didn’t work well in the external CDF player, and my Mac rebooted. Having the full power of Mathematica to drive interactive demonstrations is a great advantage, but if the overall experience is so unpleasing as it was for me then it’s not much fun. And with less and less browser support for NPAPI, I’m afraid that the experience for most users won’t become any better.

Apparently, Wolfram is now recommending Wolfram Cloud. That appears to solve some of the problems; however, latency (and therefore real-time interaction) is still a problem. Also, running computations in the cloud costs a lot more resources (i.e., money) than just hosting CDF files or notebooks.

The next thing appears to be Wolfram One. I’m not sure what it is. Maybe Wolfram Cloud with the Wolfram Desktop option for individuals?

Anyway, I’m not sure whether Wolfram is currently offering a good solution for deploying real-time interactive graphics on the web. Maybe the bottom line is that offering the full power of Mathematica for real-time interactive graphics on the web is just not a good idea, and web apps with limited computational power are still useful.




I’ve started to think about the name of the JavaScript port of LiveGraphics3D. Currently, my favorite is LiveGraphics3D 2.0. That might appear a bit boring (in particular considering that the current version is 1.94) but here is the twist: versions 2.x might support only the 2D context of the HTML5 canvas element while version 3.0 might then introduce support for the 3D context (i.e., WebGL). I keep getting ahead of myself.


The seductive power of libraries

While porting the token scanning of LiveGraphis3D from Java to JavaScript, I realized that one reason that this whole endeavor has a realistic chance of success is that I only used plain Java and the most basic library classes, e.g., Graphics from the Java AWT classes. (I.e., I didn’t use Java3D nor Swing, etc.) The functionality of the AWT Graphics class is similar to the functionality of the HTML5 Canvas 2D API, and in fact to any other 2D graphics API. Thus, I don’t have to reimplement any complex functionality. If this port to JavaScript succeeds then not relying on existing Java libraries was the key. I assume a lot of software projects die because of dependencies on libraries that are no longer supported or evolve without backwards compatibility.

Of course, the evolution of Mathematica’s graphics is an example: LiveGraphics3D supports only Graphics3D objects of Mathematica before version 6 (when the graphics were significantly revised) because I’ve never found the time to support the version 6 graphics of Mathematica. (Part of the reason is that the scanning of textual representations of these graphics requires a lot more look-ahead than the older graphics.) Thus, in the long run, LiveGraphics3D is doomed because it cannot keep up with the evolution of Mathematica (unless someone else picks up the task).

What alternatives are there to Mathematica? In particular, could LiveGraphics3D support an open-source computer algebra system? Probably, but the whole idea is that the applet (and in the future the web app) is not only able to read and display potentially complex 3D graphics but also read and evaluate potentially complex symbolic expressions, and that requires quite some programming unless someone has already implemented a computer algebra system in JavaScript. Anyway, I’m getting ahead of myself again.



I am Andy

While listening to “I Am Vaiana (Song of the Ancestors),” I’ve ported the character scanning of LiveGraphics3D to JavaScript. This includes mundane things like replacing comments by a white space and checking whether a Unicode character is printable, but the main part is mapping Mathematica’s special character names to Unicodes. Examples include “\[RightArrow]” (which is mapped to “→”), “\[Not]” (“¬”) , etc., but also some interesting Mathematica-specific characters, e.g., “\[Andy]”.

Anyway, I realized that my JavaScript is a bit rusty; I guess that’s to be expected since I haven’t done any serious JavaScript programming for about 3 years. Also, I realized that I have to implement parts of classes that Java offers but that are missing in JavaScript. Today it was the Color class and in particular the construction of an RGB color from HSB.

Also, I started thinking about interacting with parametrized graphics in virtual reality. But I guess I shouldn’t get ahead of myself.


The good thing about starting with a big pile of work …

… is that it doesn’t matter where you start because so much has to be done. So where to start with porting the applet?

It’s actually easier to decide where not to start: the class TextElement is for formatted text, which is secondary; the classes Expression, ExpressionElement, and Evaluator are for evaluating symbolic expressions, which is not essential for the basic functionality. Quaternion and Primitive are small classes that I can do whenever they are needed.

This leaves the main class Live, the Graphics3D class for representing and rendering the Graphics3D object, and the Parser class for parsing the textual representation of a Graphics3D object. Among those the choice is relatively easy: Parser can work without the other classes, but Live and Graphics3D cannot  be tested easily without Parser. Thus, Parser it is.


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.


So the journey begins …

Why do we decide to do crazy things? Often it’s because of other people. In this case, it was Maurice Starck who put me on this path. (Thanks for that! I’ll remember your invitation to New Caledonia when this project is done.)

This project is about porting the Java LiveGraphics3D applet to a HTML5 web app. I’m not sure yet, what that means, but that’s part of the journey, I guess.