Andrew co-founded Agility3 in 2012 and took on the responsibilities of Software Solutions Director and Software Development Lead. He continued in these roles until 2020.
During his time at Agility3, Andrew was a critical part of the business, performing key roles on all projects, and being technical lead on all software projects.
The following are a small sample of the projects Andrew was involved with at Agility3 from their inception, through their design and development, to their successful delivery.
Railway Environment Model Developer (REMoD)
Overview
REMoD was the last project I worked on at Agility3 and draws heavily on the experience and expertise I had developed throughout my time with the company.
Agility3 were invited by the BCRRE (Birmingham Centre for Railway Research and Education) to take part in a competition for this project in early 2020. I was responsible for designing the software concept and also in charge of the technical proposal. The BCRRE awarded the contract to Agility3, and I took on the roles of technical authority, technical manager and lead software developer for the project. I managed one other software developer who, under my guidance, was responsible for developing the user interface. The first version of REMoD was delivered in late 2020.
REMoD is a 3D unity-based application that provides a user with the ability to create a 3D virtual rail environment. The REMoD tool starts with an empty world, into which a user can import track topology data that describes the connectivity and shape of a rail network. From this data, REMoD can automatically generate the 3D track-bed geometry. The user is then able to attach different ‘network components’ to any segment of the track, for instance: platforms that can include elements such as passengers, roofs, walls, fences; stations; different forms of environment such as countryside, farmland, industrial, suburban, city; electrification such as a third rail or pylons and overhead wires. Within those categories of ‘network component’, the user can also specify a finer level of detail, for instance, in an industrial environment, the user has control over which buildings are used to populate the environment, where they are placed, how they are rotated, if they should repeat and how often; the placement, size and number of cars in car parks; where vegetation such as trees and bushes should be placed. Throughout the environment model, by using ‘templates’ and ‘rules’ that are built into as a basis, the user has control over what elements are placed where and so can develop their own, bespoke rail networks and 3D environments.
In addition to the creation of 3D rail environment models, REMoD is also able to stream in real-time data from a train simulator and visualise the simulated train movements, track switch points states, signal states, electronic message board information and dynamic passenger numbers on platforms. When simulation data is being streamed in this way, the user can adopt the viewpoint of a train driver and visualise their ‘out-of-the-window’ perspective.
Technology
REMoD is developed using Unity. It uses a UDP messaging interface to read in real-time simulation data in an XML format at a rate of 10Hz. REMoD is able to extrapolate/interpolate this data to provide smooth animation of train motion. REMoD core functionality makes use of procedural 3D geometry generation.
Agility3 have since rebranded and enhanced this product, now known as “RapidRail”:
https://agility3.co.uk/rapidrail-3d-visualisation-for-the-digital-railway/
Challenges & Achievements
User Configurability
In previous rail related projects that required the procedural generation of 3D environments, the complexity was greatly simplified by having static, consistent rules that determined what 3D geometry should be created where. With REMoD, the specification of those rules had to be given to the user and could therefore be customisable and, by definition, dynamic. This meant that not only was it necessary to expose all the procedural geometry generation rules to the user, but also, the application had to be able to cope with all kinds of configuration and user design. It was very challenging to provide this level of configurability whilst also ensuring that the 3D generated geometry remained realistic and representative.
Rails Crossing at Switch Points
The visualisation of the state of switch points was required for this project. Because the network topology could have any size, shape and structure, it meant that where track converged or diverged at switch points, the generation of the 3D geometry had to accommodate any and all possible track curvatures. In software code, I was able to characterise the track curvature at switch points and so dynamically create switch blade geometry of the appropriate length with an appropriate centre of rotation. The geometry then registers interest in specific incoming real-time simulation data and changes state according to the received data.
Screenshots
Images courtesy Agility3 Limited
https://agility3.co.uk/agility3-portfolio/rail/#rail-1 Agility3 Blog: BCRRE
3D View Display for ProRail
Overview
In 2019, Agility3 were asked by ProRail, who are responsible for the maintenance of the Dutch railway infrastructure, to develop a 3D visualisation application to help with the rollout of the new ERTMS technology. ProRail had been impressed with the VIrtuRail software that had been demonstrated to them and they required something similar. The “3D View Display” is able to read in ProRail custom data that defines a rail route and the elements along it (e.g. signals, bridges, level-crossings, etc). The 3D View Display is then able to auto-generate a rail track and surrounding 3D environment from the supplied data. ProRail also required that the 3D View Display link up with their train simulators in order to provide a user of the 3D View Display with a simulated ‘out-of-the-window’ driver perspective of a train journey.
I originally provided ProRail with the demonstration of VirtuRail that ultimately led to this contract. I was responsible for designing the software solution and led the software development. I managed one other software engineer who helped develop the software.
Technology
The 3D View Display is a Windows desktop Unity application. It interfaces with ProRail’s train simulators via DDS (Data Distribution Service) over a LAN.
Challenges & Achievements
Performance
ProRail had some tight performance requirements due to the specification of the target hardware. They needed it to be able to run on relatively low specification machines as well as also looking as good as possible on high specification machines. This was achieved firstly by developing 3D models that are as efficient on polygons and materials as possible, but secondly by providing the user with configuration file settings that allow them to customise the complexity and detail that is generated in the 3D. For instance, the quantity and density of vegetation can be adjusted by the user as well as window size and resolution.
Arched Bridges
The ProRail track data can include the specification of the location and length of bridges. ProRail required these bridges to span bodies of water. It was therefore necessary to develop models and functionality that could generate bridges of varying length. For bridges with constant cross-section, this was relatively straightforward. By having a ‘bridge start’ model, a ‘bridge end’ model and a repeating ‘bridge middle section’ model a bridge of almost any length could be automatically generated from pre-existing 3D ‘kit’ components. However, for an arched bridge, it was less straightforward. Because the cross-section is not constant and arched bridges of differing heights would be required for different bridge lengths, I had to develop algorithms to auto-generate a 3D bridge structure around a dynamically calculated equation for a parabola that spanned the necessary length. The screenshots in the next section show a couple of examples of procedurally generated arched bridges of differing length.
Screenshots
Images courtesy Agility3 Limited
https://agility3.co.uk/2020/05/14/3d-view-display-delivered-to-prorail/
https://www.youtube.com/watch?v=RmnIpT_CQ-c&feature=emb_logo
Phase 5 Upgrade
In 2021, Soft Pebble Limited won a contract to develop a major upgrade to the ProRail 3D View Display software. In previous versions the entire 3D environment is generated on initialisation of the application, however, in the upgraded version the tracks and environment are procedurally generated ‘just-in-time’ as the train traverses its route. This allows the train’s route to change during its journey and the 3D View Display will automatically generate the appropriate environment and track assets for the current route. This upgrade involved a great deal of rework and, in particular, optimisation of the existing software application to ensure acceptable frame rates and smooth train locomotion.
VirtuRail for Transport for London
Overview
In 2015, Transport for London (TfL) launched a public tender competition for proposals to develop a 3D viewer to link into their existing Railway Engineering Simulator (RES) software. Agility3 entered and won this competition. I was responsible for developing the Agility3 solution concept and writing the technical proposal for this project. I was also responsible for pitching the solution to the TfL bid team during the competition process.
Following the successful tender, I was technical authority, technical manager and lead software developer for the duration of the project. I managed one other software developer who helped me in developing VirtuRail.
The TfL RES software uses text-based data to define a railway network and the trains that run along that network. TfL use RES to simulate the conditions of and analyse train movements along proposed network alterations or new network additions. Until the “VirtuRail” 3D software, the only visualisation TfL had of their simulated data was on a topological top-down network map. VirtuRail has two main, underlying features:
i) The ability to import TfL’s text-based railway network definition files and procedurally auto-generate a 3D model representing the network’s tracks, tunnels, stations, signals, signs, trains and surrounding environments.
ii) The ability to connect to TfL’s RES software to receive simulated train location data and signal state data in order to visualise them with the auto-generated 3D environment.
TfL use VirtuRail for stakeholder engagement as well as it being a powerful tool for their engineering team.
Technology
The VirtuRail software has been built using Unity. It is a windows desktop application and is able to communicate across a LAN either with other instances of VirtuRail (multiple remote users can all visualise the same 3D network simulation at the same time) or receive state data from a running RES simulation.
Challenges & Achievements
Procedural 3D Geometry Generation
data. This required an enormous amount of planning and careful design. Unity has the capacity for procedural generation, but it comes with some compromises and complications that had to be overcome. For instance, real-time lighting had to be used throughout. This would have an impact on both performance and realism, so had to be carefully considered and real-time lights used sparingly. Because procedurally generated geometry, such as the track bed, could potentially be of any width and any lengt
obvious repetition. The actual software design and development of the mechanisms to perform the geometry generation and try to ensure that geometry flowed and connected correctly was a complex task.
External Interfaces
While connected to TfL’s RES software, VirtuRail is constantly receiving data. Unity is a single threaded application that doesn’t cope very well with multiple threads. However, it was essential to have VirtuRail receive data on a separate thread to ensure the main thread frame rate didn’t grind to a halt. This had to be carefully designed and implemented to avoid memory issues and race conditions which might crash the application.
Train Motion Smoothing
Even though train data can be received by VirtuRail at a high frequency, often a single simulated train only reports its position once per second. If VirtuRail only moved the train once per second, its motion would look very stilted and jerky. It was therefore necessary to develop a method of extrapolating/interpolating train locations. Due to the way individual sections of track are defined in the RES data, this task proved remarkably complex. For instance, tracks can branch into two tracks at switch points and it was necessary for VirtuRail to know the state of the switch in advance of the train location data arriving so that the train position could be correctly extrapolated onto the correct branch.
Screenshots
Images courtesy Agility3 Limited
See “VirtuRail – 3D Visualisation Application”: https://agility3.co.uk/agility3-portfolio/rail
Rail VR Experience
Overview
In 2017, Agility3 exhibited at the RailSimTech event in the UK. Agility3 have a number of rail simulation and 3D visualisation related projects and RailSimTech was focused on these capabilities. At the time, I was leading Agility3 in undertaking research and development in Virtual Reality. With the help of one other software developer, we made use of some of the 3D content developed for the VirtuRail project and developed a demonstrator that showcased our VR capabilities.
Wearing a VR headset, the user is immersed in a seated VR experience. They are able to board a virtual tube train and, select their seat and even enter the driver’s cab and take control of the train. Realistic sound effects further immerse the user in the virtual environment.
Technology
The Rail VR Experience was developed using Unity. It is targeted at the HTC Vive VR headset and runs with a VR ready laptop PC. The application was optimised to run at around 90 frames per second. The 3D content was derived from the VirtuRail 3D content and the visual quality enhanced to improve the realism.
Challenges & Achievements
Motion Sickness
As with any VR experience, user comfort is a fundamental challenge. Due to the level of immersion, it is all too easy to put the user in a situation that can cause motion sickness or fatigue. This is especially true if the user is made to move around a 3D scene that they have little control over and can be accentuated if the user is forced to accelerate and decelerate. All of these elements were core components of the Rail VR Experience concept. The first thing I decided was that the experience should be a seated experience, this helped minimise any loss of balance effects and also suited the target audience of RailSimTech exhibition delegates. The other thing we did was to minimise the amount of acceleration and deceleration of the train itself. These together allowed us to almost completely remove any feelings of motion sickness from the application.
Frame Rates & Performance
Also key to VR applications is performance. If frame rates are less than about 90Hz, the user can start to feel motion sickness due to the lagging of 3D visuals and jerkiness of movement within the scene. We therefore spent time optimising the 3D content and minimising the complexity of the underlying train simulation. By using techniques such as baked lighting and dynamic occlusion culling we were able to improve performance and hit the required 90Hz frame rate.
Sound Effects
Sound effects for the Rail VR Experience add further realism and immersion to the application. These were originally captured from real London Underground trains and then I edited, cut spliced them to create a library of sounds. By incorporating various triggers into the application, the relevant sound effects play at the correct moment, providing the user with a sense of realism.
Screenshots
Images courtesy Agility3 Limited
http://agility3.co.uk/agility3-portfolio/rail/#rail-5
https://www.youtube.com/watch?v=-eUV9N42RLc
Level Crossing VR Experience
Overview
The customer required a short VR experience that could either be from a pedestrian or cyclist’s perspective. This project was developed for trialling a new type of UK train line level crossing and how pedestrians and cyclists might react to them.
I was technical manager and lead software developer on this project, managing one other software engineer.
Technology
This was developed using Unity and targeted at the Oculus Rift VR headset.
Challenges & Achievements
Configurability
The customer required that a series of VR experiences were possible. Each experience was a slight variation on a baseline experience. The baseline experience required a user to approach a level crossing along either the pavement (pedestrian) or the road (cyclist). However, the type of level crossing barriers and the number of trains that pass when the barriers are down needed to be part of the trial’s variable data. This was achieved by having a number of different configuration files that characterised the different variables and when the trial coordinator chose the specific scenario for the user from a start-up UI, then the 3D scene and components within it would be configured specific to that required scenario.
User Motion
Because the user was being moved through the world, out of their control, we were very conscious of the potential for causing motion sickness. To try and minimise this, we developed a configurable ‘peripheral vision limiter’. Enabling this limited the user’s view to be a circular region in the centre of their vision, the rest of the view being blacked out. By doing this, it limits the amount of ‘stuff’ moving through the user’s periphery and reduces the sense of acceleration and motion, the theory being that it thus reduces the chance of motion sickness. The size of the circular region could also be configured by the user, given them control over what they felt was comfortable for them.
Screenshots
Images courtesy Agility3 Limited
https://agility3.co.uk/2020/06/04/vr-experiences-delivered-for-level-crossing-research/
VR Driver Hazard Perception Experience
Overview
This project was a prototype, proof-of-concept, and demonstrator developed at Agility3 for a potential customer. It is a seated VR experience in which the user drives a vehicle, using hardware steering wheel and pedals input devices. The user must react to a randomly generated hazard. The application then measures the user’s reactions to the hazard. It measures reaction time and reaction manoeuvre.
I was sole developer, taking around 2 weeks to design and develop the application from scratch.
Technology
Unity was used as the development platform and targeted at the HTC Vive VR headset. A Logitech steering wheel and pedals were integrated into the application to provide input to the vehicle model. The vehicle model (3D model and vehicle simulator) was a third-party Unity asset from the Asset Store. The environment 3D models were reused directly from another Agility3 VR project.
Challenges & Achievements
Timescales
The potential customer needed a proof-of-concept two weeks from the start of this project. This was a challenging deadline, especially as I was the only developer. By reusing elements already developed on other projects (such as the environment models – houses, roads, etc) and making use of existing assets on the Unity Asset Store, I was able to quickly integrate all the necessary elements. Adding the ‘gameplay’ and an opening introduction UI was relatively straightforward. The main difficultly then lay in optimising the scene and application for VR.
User Experience
Combining variable motion and VR isn’t often a good combination. When a user experiences acceleration in the VR world, the lack of correlation with their physical motion can cause sickness.
We warned the client of this potential issue and unfortunately there was little that could be done, especially in the timescales to address this. It was partially addressed by ensuring that the user is seated for the experience, and I minimised the rate of acceleration as much as possible.
Hardware Input
Detecting and reacting to the input from the steering wheel and pedal hardware devices was straightforward, however, calibrating their input was quite trial-and-error. When testing on a desktop PC, outside of a VR environment everything looked ok. However, when immersed in VR, the vehicles reactions to user inputs created an enhanced ‘feeling’ of being in control of the car. Getting the calibration wrong resulted in the car feeling ‘spongy’ or feeling like it was pivoting about the middle or rear of the car. This required careful adjustment and readjustment.
Screenshots
Images courtesy Agility3 Limited
https://agility3.co.uk/agility3-portfolio/road/#road-5
https://www.youtube.com/watch?v=_v3p5Lo0D_U