Please note that this is a fairly old post and I have no idea whether any of this is still current! I’ve since moved-on to visualising mostly in the browser using a combination of
D3, which is the direction to go IMHO.
Visualising the visualisation landscape
I’ve spent the last several weeks investigating options for visualising spatial information. Lets just say its been surprisingly frustrating and rewarding at the same time. In a perfect world I’m looking for a visualisation package that is tightly integrated with code, allowing for dynamic user input and on-the-fly visualisation of computational processes as they unfold.
My journey started with the ‘ol classic: Processing. But its a bit of a love-hate relationship. Processing is a really good way to learn how to program while churning out surprisingly powerful visualisations, but its messy (Java) syntax and somewhat constrained ecosystem are what originally sent me searching for greener pastures.
Having recently learned Python while working on a GIS assignment (Python + ArcGIS’ arcpy), I found it incredibly clean, well documented, and productive. It is really a fantastic programming language for solving complicated challenges because it lets you focus more on how to solve the challenge rather than how to implement a solution within the constraints of the spaghetti syntax typical of many programming languages. Presumably for this reason, it is increasingly being adopted by the science community (think numpy, scipy, matplotlib, pandas, etc) and IMHO is the one to watch.
(UPDATE: Feb 2015 -> there is now a built-in Python mode for processing!)
I was unable to find anything remotely like a Processing equivalent in Python, but did find Processing.py, which is effectively a Python port of the Processing language. You have access to all of the standard processing functions and libraries, and you run the code by dragging and dropping your file onto an app that uses Jython to translate the Python into Java. But while this is a great solution for basic sketches and experimentations, the workflow tends to start feeling constrained for anything more complex.
Looking for something more directly coupled to Python, the next port of call was Blender. I’m still not sure what to make of it. On the plus side, it offers a tight synthesis between Python and visualisation. But the API is quite difficult to understand and the GUI interface is hugely unintuitive and complicated. And even after playing around with it for a while, the right mouse-click for selecting objects remains the most incredibly unintuitive bit of interface design I’ve ever encountered. I did manage to use python to import a csv file with more than 700,000 trip events and to convert a portion of these into animated objects, but the amount of effort to reward sent me packing. Whereas blender leaves me somewhat dazed, I suspect that if one has several months to really learn and tinker with it, it could become a very potent tool that could conceivably be fully customised.
Next, I went knocking on Rhino’s door. What drew me to Rhino is that its a well respected package in the Architecture community, and is often combined with Grashopper to allow the creation of generative design workflows. Furthermore, it has an extensive API which now interfaces with python. I was again able to create a python script to import a csv file with data, and to animate some of these objects in space, but I did encounter some issues. Firstly, I discovered that some python modules didn’t work in Rhino, and the reason is that it actually uses “IronPython” which is integrated with Microsoft’s .NET…and although most Python modules have been incorporated, some, such as the CSV reader module, are conspicuously absent. The other issue I ran into was that trying to move lots of objects in real-time was slow, presumably because Rhino is designed for modelling, rather than real-time animation and visualisation. If one were to learn the ins and outs of RhinoCommon, then it should be possible to find ways to speed it up, but for now, it was time to move on to the next port of call.
I was initially rather dreading the thought of learning to use C# but, in retrospect, this fear was unfounded. For those new to programming, C# is distinct from C as well as C++. It is understandable why these languages are all called “C something”, but for newcomers this gives too much of an impression that they are all quite similar. They are actually all quite distinct. A brief (and by no means comprehensive) history is that C came along first. It is a low-level and potent language. Then along came C++ (C “incremented”) which added things like object oriented programming (i.e. classes). Although it effectively grew out of C, it is at the same time completely different due to the revised patterns introduced by object-oriented thinking. C#, the most recent addition, was created by Microsoft for its .NET framework. In spite of the “C” in the name, its syntax is very similar to Java… There is yet another widely known C language; “Objective-C” which is used for Mac and iOS development. (And again, quite different.)
For anyone that has messed about with Processing (which is built on top of Java), the good news is that if you know rudimentary Java it is easy to master the C# syntax and logic. But whereas Processing does some of the work for you behind the scenes, in C# it is up to you to explicitly state whether variables are public or private and it will also push you towards a more strict object-oriented programming approach.
What floored me about Unity 3d is that, not only was it able to import over 700,000 trip events relatively quickly, but for the most part it was also capable of animating these in realtime as the trips unfold across time. In this case, the animated instance of a trip object is created when a trip starts, and is destroyed when the trip ends, so there can be multiple thousands of trips occurring at any point in time. (The trips are of tube journeys across the span of a week in London, and only when visualising the week-day rush hours did it start choking my system. And this because it only used one out of the eight available processing cores.) Because Unity is a game-engine, it uses some clever behind-the-scenes technology to make sure that the playback is as smooth as possible. For this reason, it distinguishes between actual time and frame rates, and it will display animated objects in such a way that their movement remains smooth, even though the frame rate could be lagging or varying greatly. But the clincher is that unity also allows the creation of a fully customised GUI, direct user interaction, and it ports to all different operating systems and mobile devices.
If you want to do quick and (relatively) simple visualisation sketches, use Processing. (Or Processing.py.)
If you want to use pure python to create animations, use Blender.
If you want to do interactive form generation, use Rhino.
But if you want to blow your socks off with large amounts of data, smooth and real-time playback, and easy user interaction, then use Unity 3d.