Gussy up Vissim with the rendering power of a game engine.

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).

Figure 1: examples of simple 3D street views rendered in Vissim
Figure 1: examples of simple 3D street views rendered in Vissim

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.

Figure 2: Settings needed in order to create text files with pedestrian trajectories
Figure 2: Settings needed in order to create text files with pedestrian trajectories

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
  • Reflections
  • 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.

Figure 3: graphical user interface of Unity3d
Figure 3: graphical user interface of Unity3d

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).

Figure 4: simulated traces of pedestrians (blue), cyclists (yellow) and vehicles (pink) projected on 3d model
Figure 4: simulated traces of pedestrians (blue), cyclists (yellow) and vehicles (pink) projected on 3d model

Encountered Challenges

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.

Outputs

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.

Figure 5: prototype renderings from Unity to illustrate different street configurations and traffic  levels to be used in stated preference surveys.
Figure 5: prototype renderings from Unity to illustrate different street configurations and traffic levels 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.

Our roadmap

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).

Figure 6: Alex testing VR cycling simulator developed by Atlantis Games and NHTV Breda
Figure 6: Alex testing VR cycling simulator developed by Atlantis Games and NHTV Breda

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.

How to model pedestrians and cyclists interactions with out-of-the-box features of Vissim?

The growing importance of multimodal traffic simulations

As transport and urban planners around the world consider cycling as an important mode of transport in the urban mobility mix, there is also a growing interest in software tools to support the planning of cycling infrastructure. While macroscopic transport demand models are commonly used to estimate future travel demand and loadings on a network level, microscopic traffic simulation software packages are a widely used for traffic engineering, e.g. to evaluate the performance of different street and intersection designs or traffic signal plans. While those models originally have been developed to model motorised individual traffic and public transport, more recently researchers and practitioners started to adapt those model to also feature active transport modes.

Limits of current microsimulation tools

The current traffic microsimulation software packages such as PTV Vissim, Caliper Transmodeller, Sumo or TSS Aimsun offer great possibilities to model complex but realistic multi-modal traffic situations and some of them also offer remarkable 3d visualisation features to communicate different planning scenarios to a non-technical audience. However, when it comes to the representation of cycling and shared space situations, there are also quite a few limitations.

Heather Twaddle, a researcher at TU Munich an here colleagues recently reviewed existing approaches (Twaddle et al. 2014) for modelling cycling behaviour in traffic microsimulations. While some of the existing software packages allow to model cyclists using the same behaviour models as for motor vehicle traffic, simply adapting the parameters of the vehicle behaviour models to reflect the lower speeds of bicycles does not work for all conditions. Since there exist several unique characteristics that are difficult or impossible to represent with such models, researchers have investigated in adapting car following models, cellular automata and the social force model to better fit the behaviour of cyclist.

However, for our research project that investigates our street design impacts the propensity for cycling, we are also interested in the simulation of mixed traffic conditions on shared spaces or sidewalks that include both space for pedestrians and cyclists.

While simulating two traffic flows (whatever if pedestrians, bicycles or cars) crossing with a sufficient angle can be easily modelled by specifying a conflict area (Figure 1) or a priority rule, the correct representation of interactions lengthwise (with an angle equal to 0 or 180) is very challenging.

Figure 1: 3D view of an intersection between pedestrians and bicycles managed with conflict areas
Figure 1: 3D view of an intersection between pedestrians and bicycles managed with conflict areas

To explore what can already be achieved by adapting the behavioural parameters of Vissim’s standard simulation models, we have done some tests. The basis for all tested scenarios is the same: we want to simulate pedestrians and bicycles sharing a narrow path of about 3m width (about 5m for scenario 3). The number of pedestrians and cyclists is proportional to the lane width and therefore the density is the same in all scenarios.

Pedestrians as small vehicles

In Vissim, there exist the possibility to simulate a pedestrian as a car. The advantage is, that pedestrians are recognized by cars and therefore, interactions are automatically generated. Logically, pedestrians behave also like a vehicle. They follow and overtake each other along defined lanes, which of course is not very realistic.

Figure 2 shows an extreme case, where two links with one lane each are created. If no rules are applied, pedestrians would just walk in middle of the lane, making an overtaking for cyclists difficult. Thus, the driving behaviour should be adapted such as pedestrians prefer to walk on the left. As a result, the observable behaviour resembles to a highway, where slow cars are driving on the sides (pedestrians) and fast cars are overtaking in the middle (bicycles).

Figure 2: Extreme scenario 1 with two links and two lanes (3D perspective of a cyclist)
Figure 2: Extreme scenario 1 with two links and two lanes (3D perspective of a cyclist)

Of course we were not satisfied with this setting. In Scenario 2, we tried to improve the driving behaviours, creating 2 links with 2 lanes each and assigning pedestrians and bicycles randomly to a lane (Figure 3). In addition, a possibility to overtake on the opposite lane was implemented and the width of the lanes reduced to the minimum, just enough that pedestrians and bicycle do not touch each other while overtaking. However, as a result bicycles are jammed behind slower pedestrians very frequently.

Figure 3: Scenario 2 with two links and 4 lanes (3D perspective of a cyclist)
Figure 3: Scenario 2 with two links and 4 lanes (3D perspective of a cyclist)

In Scenario 3 with two links and 6 lanes (3D perspective of a cyclist), the number of lanes were augmented to 6 (3 for each direction) in order to allow more flexibility and, therefore, reduce jam (Figure 4). All in all, this setting creates the most realistic interaction between bicycles and pedestrians if pedestrians are simulated in the car-following model.

Figure 4: Scenario 3 with two links and 6 lanes (3D perspective of a cyclist)
Figure 4: Scenario 3 with two links and 6 lanes (3D perspective of a cyclist)

However, when modelling pedestrians as (tiny) vehicles, there always remains one issue: Because of the infrastructure constraints, the flows are segregated in two directions. This do not correspond to the reality, why we tried another approach.

Having said that, scenario 3 could also be simulated as two 2.5m cycle lanes with free overtaking. The problem in this case is that pedestrians behave very strange and conduct nervous overtaking actions.

Bicycles as big pedestrians

In order to avoid the very mechanical and automated behaviour of pedestrians, we were thinking about inverting the rules: let’s simulate the bicycles as pedestrians!

To this end, the work is done with PTV Viswalk, an add-on module of PTV Vissim. PTV Viswalk is mainly used for modelling railway stations, capacity planning, safety concepts or evacuation analysis and is based on the idea of the social force model.

For this scenario, we just adapted the behavioural parameters of those pedestrians that represent cyclists and used a bicycle 3D model for their visual representation. As Figure 5 shows, the pedestrians are walking more randomly on the assigned surface and there are no clear (directional) flows observable.

Figure 5: Scenario 4 with bicycles simulated as pedestrians (3D perspective of a cyclist)
Figure 5: Scenario 4 with bicycles simulated as pedestrians (3D perspective of a cyclist)

We adapted the behavioural parameters of pedestrians and bicycles as follows:

  • Tau: The greater this value, the lower is the acceleration strength and therefore, the time to reach the desired speed is increased. Tau should be lower for pedestrians than for cyclists.
  • React to n: It is important that the number of considered n is low for bicycles. This yields to a smoother trajectory of the cyclists.
  • VD: Increasing VD for pedestrians provoke a greater reject effect from the cyclists (and other pedestrians).
  • Noise: In order to avoid a deadlock between two cyclists, this value should be greater than the default value (1.2).
  • Grid size: Since we do not have to deal with surfaces, but with narrow on long paths, the grid size has only a moderate influence.

Even if the bidirectional flows are much more realistic than with the strategy ‘pedestrians as little cars’, the main issue with this approach remains the very late reaction of pedestrians or bicycles to other agents. In reality, especially cyclists would react much earlier if another cyclist is approaching in opposite direction. Instead, the reaction occurs very late, only few meters before the collision (Figure 6). Hence, the cyclists should have a main force influencing the pedestrians and other bicycles much further ahead.

Figure 6: Basic problem of scenario 4: late reaction of riding in the opposite direction
Figure 6: Basic problem of scenario 4: late reaction of riding in the opposite direction

An adaptation of the 3D Model of bicycles is also needed, because the legs of the cyclists are always moving at constant (fast) speed, even if they stop, making them look like a nervous insect.

Last but not least, the bicycles cannot be simulated anymore with car traffic (e. g. bicycle lane in parts on sidewalks and road). This restriction leads to problems, especially if you plan to simulate a whole network, where a cycle lane merges in a shared space.

We have also a youtube video resuming the main aspects of this article.

Alternative approaches

Since possibilities to simulate a proper interaction between pedestrians and bicycles on a narrow path in Vissim are limited, further research work is needed. One of the most promising approach is shown by a group of researcher s around Prof. Dr. Martin Fellendorf from the Graz University of Technology in Austria. They propose to extend the Social Force model to vehicles in order to model shared including all vehicle and pedestrian types. The so called Social Force based Vehicle Model was presented at the Transport Research Board Conference in 2012. The methodology, explained in this paper, features a multiple model architecture including an Infrastructure Model (shared spaces without spatial separation), Operational Model (Social Force Model with added vehicle dynamics) and Tactical Model (conflict detection and handling using game theory).

Liang, Mao & Xu proposed in 2012 the psychological-physical force model, an adaption of the social force model which represents the cyclists as ellipses and utilizes two regimes, free flow traffic and congested traffic, to model bicycle traffic. While the model generated realistic results for traffic flow on separated cycling lane, the model has not been tested for mixed traffic conditions.

Bani Anvari and her colleagues presented in 2015 the development of new three-layered mathematical model for heterogeneous agents (vehicles and pedestrians) in a shared space environment with single surface pavements, no lane discipline and identical priority for all road users.

Another, more straightforward approach to model shared spaces was proposed by traffic engineer Stuart Gibb in 2015. He only focussed on the interactions between pedestrians and cars. The innovative idea is to replace the cars with groups of closely-packed dummy pedestrians, so that the real pedestrians recognise the vehicles and walk around them instead of simply cross them. In order to recognise precisely where the vehicle stands and replace it with dummies, a fine-meshed grid must be created. In addition, priority rules, links, detectors, pedestrian areas and pedestrian routes have to be built. Kindly, he shared his code that directly implements this approach through Vissim’s COM interface in this report.

Implementing a new behavioural model as the magic bullet?

As already mentioned, a realistic simulation of pedestrians and bicycles interactions on narrow paths is challenging to reproduce using out-of-the-box Vissim, and probably in all other traffic microsimulation tools.

Our tests were of course quite basic as they only tested how Vissim can be configured to simulate mixed traffic conditions between pedestrians and cyclists without actually changing exsting behavioural models. But it became clear that the results or not very satisfying and that there is a need for implementing a new behavioural model to simulate traffic on paths that are shared among pedestrians and cyclists, but also shared space situations in general.

Therefore, we also join the race to develop models and code for simulating such situations. This will ultimately allow us to combine it with parametric 3D models and create interactive Virtual Reality scenarios of shared urban. We are looking forward to work on this quest, stay tuned!