Why does traffic microsimulations need a facelift?
The traffic microsimulation tool Vissim is one of the most advanced traffic simulation software. Vissim offers great possibilities to reproduce extensive urban traffic situations including public transport, individual cars, trucks, bicycles and of course, pedestrians.
The software is mainly purposed to quantitatively evaluate traffic scenarios with regards to vehicle and pedestrian densities, road and intersection capacities, as well as travel times or delays. But traffic simulations are also instrumental to illustrate possible design scenarios in pictures or videos to decision makers and the general public.
However, while the 3D visualisation capabilities of microsimulation tools such as Vissim have considerably improved over the last few years, there are still limitation when it comes to the realistic rendering of 3D environments (Figure 1).
The roads and objects usually can’t be represented by varying surfaces and the animated models of pedestrians and cyclists are quite clumsy. While such restrictions are of minor importance in conventional applications, the 3D display options are insufficient if we aim for creating Virtual Reality environments. For this reasons, we decided to combine the strengths of Vissim in simulating complex traffic interactions, with the strengths of a 3D rendering engine: Unity.
Our pipeline so far
The logic behind the pipeline is quite straightforward: from Vissim, we only need to export the trajectories of the simulated interactions between pedestrians, bicycles and cars and the commands related to the traffic lights, but use Unity to animate the respective 3D models. The export functions of Vissim allows to do so. Indeed, the coordinates of pedestrians are written in a ‘.pp’ file, while bicycles and cars are saved in an ‘.fzp’ file. The traffic light programme is written in a simple XML-file, and therefore easily exportable.
Basically, the files with the pedestrian and vehicle trajectories are simple CSV (Comma Separated Values) text files and can be read in Unity with appropriate scripts. The information exchanged is: simulation second, number of pedestrian/vehicle, type of pedestrian/vehicle, x-, y- and z-coordinates. For the vehicle, two coordinates (front and rear) are required in order to extract the size of the object.
The creation of these files in Vissim is simple. Before to run the simulation, the option ‘evaluation’ in the toolbar should be selected and, after some settings (see Figure 2), the text files will automatically be created. To ensure that file sizes remain easy to handle, we restricted to a time resolution of 4 simulation steps per second, but included an interpolation feature in our Unity import-scripts. Otherwise, the text files will grow to some billion lines, depending on the number of pedestrians and vehicles simulated in the network.
Apart from the trajectories, the files related to the traffic lights should also be exported (‘.sig’ files). There, we also needed an appropriate script to read the times and the colours of the traffic light and represent it correctly on a new 3D model with different street lights in Unity.
Great possibilities with Unity
There are many great 3D engines available out there, but we chose Unity because of its fantastic visual capabilities and Virtual Reality features, ample range of file formats and ease of use.
Some of the more noticeable visual improvements when going from Vissim to Unity are:
- Physically based lighting and shadowing
- Global illumination
- More realistic skies
- Better texture filtering and antialiasing
- Post-process effects (Depth of field, motion blur, bloom, etc.)
Other more subtle details, for which we had to write scripts, also contribute to a more realistic experience:
- Rotation of vehicle wheels according to their speed
- Vehicle brake and turn lights
- Interpolation of vehicle, cyclist and pedestrian movements for a smoother animation.
- Speed-controlled walk animation for pedestrians
Unity with its tons of features allowed us to create various types of content such as scripted screenshots, videos and 360 videos. The making of videos was possible thanks to its animation capabilities, which we used to create a few camera animations to glide through our 3D environments.
Some of the scripts (which are available in our GitHub repository) we wrote in Unity weren’t dedicated to the final visual appearance, but still they played a crucial role in our development. These scripts, for example, helped us to identify issues outside of Unity by visualizing the problem within Unity. E.g. one script generates a traffic movement heat-map, to observe which areas are more/less frequented by simulation agents, or to identify if an agent takes an undesired path which helps to verify the simulation setup (Figure 4).
When we started importing the first simulation files from Vissim, Unity ran quite slowly due to the large traffic simulation. We finally had to reduce the number of agents in order to keep a real-time interactive experience in Unity.
Since we’re aiming for a Singapore-like environment, we not only need streets and buildings that look like Singapore ones, but we also need a wide range of 3D assets (e.g. road signs, street furniture, buses, cabs, trees) all of which are very specific to Singapore. These are not ready-made assets that can be found for download or sale, but required new 3D modelling efforts.
Aesthetics aside, another associated problem with 3D assets is the quality: too high and it can bring the performance to its knees; too low and it will look horrible.
Unity gives numerous possibilities for exporting visualisations, but of course also to interactively engage with the 3D model in Virtual Reality. For a start, we will use Unity to render out still to be used in stated preference surveys.
Futhermore, we started to play with 360-degree videos which have great potential to communicate design scenearios to various infrastructure project stakeholders, certainly as you can publish nowadays such videos on Youtube and watch them not only with fancy head mounted displays such as the the HTC Vive and Oculus Rift, but also cheaper options such as the Samsung VR Gear or Google Cardboard.
The bright future of VR in urban and transport planning
We are convinced that the Virtual Reality environments that are based on the integration of an urban environment (CityEngine) and a proper traffic simulation (Vissim) with a game engine like Unity offers new possibilities in terms of communication, visualization and evaluation of planning scenarios. Not least it permits to a non-technical audience to easily immerse themselves in the future environment of proposed project and to have the possibility to compare different scenarios. This allows various stakeholders to provide valuable feedback that can improve the planning process and lead to a better final project before even a single cent is spent in construction and also can avoid expensive alterations works to address usability issues.
For Vissim, the aim will be to hone the interactions between pedestrians and bicycles, especially in shared space conditions. A realistic representation of these interactions is only possible with extended programming works.
To enhance the virtual reality experience, it is planned to integrate Vissim and Unity using Vissims Driving Simulator and Multiplayer interfaces to allow for so that the traffic simulation can react on user input from the game engine. Reconfiguring a cycling trainer as a controller will allow the user to ride through a virtual environment with 360 visual freedom and interact in real time with the simulation. Colleagues at NHTV Breda have already prototyped such a setup as part of their Cycle SPACES project and Alex already had the opportunity to test it (Figure 7).
But there is still a lot of things to be improved and we look forward to collaborating with them and Atlantis Games on it and keep you posted on the progress.