The ins-and-outs of different visualisation software.
Each of the visualisation strategies employed by our group reveals a different natural fit for the exploration, visualisation, and interaction with data. Unity occupies a unique position because it offers a degree of ‘real-time’ interaction and performance not matched by the other approaches. As a game engine, it is designed from the ground-up for this purpose, thereby offering a unique range of benefits:
1) It offers a modular approach towards “assets” and “resources”, allowing for the flexible arrangement and combination of data, 3d models, settings, and scripts;
2) It separates ‘real time’ from the frame rate, which means that the frame rate is constantly optimized for a device’s computational performance, without leading to wildly fluctuating time-step changes;
3) It is capable of handling a serious quantity of objects in real-time. Testing with minimal rendering requirements indicated the ability to manipulate well upwards of 3,500 objects depending on computational power and the time scale;
4) It is further capable of offering suffiently high-quality graphics rendered in real-time, therefore distinguishing itself from traditional rendering and animation engines which can be notoriously slow at rendering, albeit with increased realism.
5) Due to these and other reasons, it is inherently well-suited to the creation of dynamic and interactive visualisations that actively respond to user inputs.
Unity’s capabilities stand in contrast to our experimentations with Blender (per the video developed by Stelios) which favoured a more traditional approach towards modelling and animation. Blender doesn’t offer the naturally interactive format and its scripting API is difficult to understand, as well as weakly documented. We also experimented with Rhino, though didn’t pursue it beyond initial experimentation in which we imported data to animate CSV data, and wherein we found it’s abilities more suited to generative and form-based modelling and less so to the creation of rich and dynamic scenes.
The data preparation for Unity was done in Python and took three inputs:
1) The tube lines with each of the stations. This was developed out of work done by Katerina, in which she identified all neighbouring stations on each tube line;
2) The stations names with the station coordinates;
3) The data file prepared by Katerina with assistance from Stelios, consisting of all trips.
The script creates a station index, and a station coordinates list, which it then uses to create a weighted adjacency matrix of all stations on the network. The scipy.csgraph package is then used to return a solved shortest path array. Subsequently, the data file is imported and the start and ending location for each trip is then resolved against the shortest path array, with the resulting waypoints for each trip written to a new CSV file. A further CSV file is also generated, containing each station’s name and coordinates.
This approach proved more computationally feasible than earlier approaches using Nav Meshes, as explored and tested by Gianfranco.
The Unity implementation consists of various components:
1) The 3d models for the London landmarks were found in the Sketchup 3D warehouse. Their materials were removed and they were imported to Unity in FBX format;
2) The outline for Greater London was prepared as a shapefile by Gianfranco, which he subsequently exported to FBX via City Engine;
3) An empty game object is assigned with the main “Controller” script that provides a springboard to other scripts and regulates the timescale and object instancing throughout the visualisation. This script allows numerous variables to be set via the inspector panel, including the maximum and minimum time scales, the maximum number of non-disabled trip objects permitted at one time (to allow performance fine-tuning), a dynamic time scaling parameter, and the assignment of object prefabs for the default disabled and non-disabled trip objects. Further options include a movie-mode with preset camera paths and a demo of station selections;
4) One of the challenges in the creation of the visualisation was the need to develop a method for handling time scaling dynamically to reduce computational bottlenecks during rush-hours, and also to speed up the visualisation for the hours between midnight and morning to reduce the duration of periods of low activity. The Controller script is therefore written to dynamically manage the time scale;
5) The controller script relies on the “FileReader” script to load the CSV files. The stations CSV file is used to instance new station symbols at setup time, each of which, in turn, contain a “LondonTransport” script file, with the purpose of spinning the station symbols. It also sets up behavior so that when a station is clicked, the station name is instanced (“stationText” script) above the station, and trips only to and from that station are displayed via the Controller script. The FileReader script also reads the main trip data CSV file, and loads all trips at setup time into a dictionary of trip data objects that include the starting and ending stations, as well as the waypoint path generated by the Python script. The trips data objects are then sorted into a “minute” dictionary that keeps track of which trips are instanced at each point in time. The minute dictionary is in turn used by the Controller script for instancing trip objects.
6) The “Passenger” and “SelectedPassenger” objects and accompanying script files are responsible for governing the appearance and behavior of each trip instance. Since thousands of these scripts can be active at any one point in time, they are kept as simple as possible, effectively containing only information for setting up the trip interpolation based on Bob Berkebile’s free and open source iTween for Unity. iTween is equipped with easing and spline path parameters, thereby simplify the amount of complexity required for advanced interpolation. The trip instance scripts will further destroy the object once it arrives at the destination.
7) Other script files are responsible for managing the cameras, camera navigation settings, motion paths for the movie mode camera, rotation of the London Eye model, and for setting up the GUI.
Visual and Interaction Design
It was decided to keep the London context minimal with only selected iconic landmarks included for the purpose of providing orientation, and a day-night lighting cycle to give a sense of time. Disabled Freedom Pass journeys consist of a prefab object with a noticeable bright orange trail and particle emitter, in contrast to other trips which consist of simple prefab objects with a thin white trail renderer and no unnecessarily complex shaders or shadows due to the large quantities of these objects. The trip objects are randomly spaced across four different heights, giving a more accurate depiction of the busyness of a route, as well as a more three-dimensional representation of the flows.
Interactivity is encouraged through the use of keyboard navigation controls for the cameras, as well as a mouse “look around” functionality, switchable cameras, and the ability to take screenshots. When individual stations are clicked, then only trips to or from that station are displayed.