First the Brickbats...
I’d love to be able to say that I keep coming back to Processing because it just works, but quite often for me lately it doesn’t. When I started playing a bit again over Christmas I hit the ‘unexpected token void’ bug and none of my previous code would work with 0192. After getting around that, something in the graphics had changed and the 3D code I built up last year was producing garbage. Processing isn’t the ideal debugging environment and I lost many hours tracking that one down. To top it off, I spent most of my recent holiday recoding my user interface and 3D modelling classes in v1.5, only to find out that there is absolutely no way I can get a v1.5 produced applet to run while embedded in a web page or started with JNLP. Exactly the same code/sketch works fine in v1.09 in both instances, so that’s the version I’ve had to use to create the web applets I’ll be uploading over the next few days.
Update 08 May, 2011
This seems to be a known bug in Processing ( Issue 666 ). For me, it seems to be Windows-specific or something to do with my Java 1.6.0_XX configuration. Exporting exactly the same sketches from v1.5 in MacOSX works fine, embedded in a page and via JNLP. I replaced my Windows generated v1.09 JAR files with the Mac v1.5 ones and they seem to run fine even on my Windows machines. Of course, for some reason now Safari on the Mac has decided that the first mouse click should send the model view into some weird upside down orientation, but you can quickly reorient it so I can live with that for now.
Then the Bouquets…
That said, Processing is a fantastic environment to play in. The work on OpenGL2 (unfortunately removed at the very last minute from v1.5) looks really great and the experimental Shape3D class was an inspiration. Even the P3D graphics improvements are really impressive, especially when the camera is inside a model and there is geometry behind it.
What I do really like about Processing is how well it allows you to combine it’s own graphics functions with raw calls to OpenGL and JOGL - this really helps with the experimentation process (and - before you ask - no, I’m not doing any of that in the web applets that won’t work in v1.5). All of which brings me to the main theme of my holiday experiments…
3D on the Web
WebGL looks great, but it’s implementation still varies a bit between Chrome and FireFox - with the version of Chrome I was testing on having all sorts of problems rendering form items on the same page (see Chromium Issue 71624). However there is no doubt that it’s the future so I’ve been experimenting fairly widely, and also with x3dom which is a great technology. But neither run in IE or on the iPad, and Fennec on my Android tablet seems very picky about the code that it will actually display. Thus that particular basket is worth a few eggs, but not too many just yet.
To mention some non-WebGL options, there are quite a few HTML5 Canvas based 3D frameworks such as three.js and pre3d which do a reasonably good job, but no hardware depth buffer or GPU effects. Also the Unity games engine is a great commercial write-once run-anywhere option but runs inside a browser plugin on desktop platforms and within wrapper apps on mobile.
However, I really wanted to experiment with fast OpenGL and GPU shaders, yet still have the opportunity of creating a web app that anyone could use if I wanted. Thus, my main aim over the holidays was to develop a common infrastructure that I could use on the web, in mobile apps and as applications for all three major operating systems.
It’s hard to look past Processing for this as it’s pretty well all there already. Android mode in v1.5 works surprisingly well (even if it sometimes likes you to grovel and beg quite a bit first) and Processing applications already work locally across all major platforms and as web applets. The latest version of Processing.js now supports WebGL as well as HTML5 Canvas, and the Processing For The Web project bodes well for an interesting future.
The only missing link is the iPad, but I figured that if I stuck mainly to raw OpenGL displays, for both user interface and modelling, there probably wouldn’t be too much work required to wrap that in an Xcode-generated window. Moreover, I recently purchased MonoTouch, the iOS component for Xamarin Studio, which means even less work - basically converting Java to C# and using the standard OpenGL ES canvas.
For me, at least for the moment, Processing is great as the core of my personal experiments with 3D on the web. By keeping my classes simple and OpenGL-specific, I can quickly use most of the same basic code to create web, mobile and local applications. Now I just have to work on the problem of having absolutely no time to write them.
Click here to comment on this page.