Exploring the Reuse of Fire Evacuation Behaviourin Virtual Environments

Mingze Xi Shamus P. Smith

School of Electrical Engineering and Computer ScienceUniversity of Newcastle,

Callaghan, NSW 2308, AustraliaEmail: mingze.xi@uon.edu.au, shamus.smith@newcastle.edu.au

Abstract

There is increasing use of virtual environments toprovide scenario-based training in hazardous environ-ments, where real-world training would be difficult,dangerous or have ethical implications. One specificexample is fire evacuation training and the use of vir-tual fire drills. Virtual environments can be used topresent simulated buildings and fire hazards whereevacuation drills can be safely practised. However,realism in the virtual environment, e.g. visual andsound effects, and the interactions with simulated en-tities, e.g. fire, smoke and other building evacuees,can impact the training experience. Also buildingsuch complex environments can be time consumingand error prone. One solution is the reuse of compo-nents that make up the virtual environment, in thiscase, the building layouts, the interactive environ-ment itself, and the realistic simulation of fire hazardsand fire science impact on human behaviour.

This paper describes work to extend a virtual envi-ronment development pipeline for building virtual fireevacuation training systems. The pipeline integrates3D building models and fire egress behaviour fromfire evacuation simulations into a game engine. Thebehaviour of autonomous agents representing humanevacuees, extracted from the fire simulations, is val-idated against the target virtual environment. Con-sistent agent behaviour was found across egress time,agent population scalability, the addition of fire haz-ards and in extended building complexity.

Keywords: Virtual Reality, Game Engines, VirtualEvacuation Drills, Evacuation Model, Reuse.

1 Introduction

Fire accidents are a frequently reported disasteracross the world. For example, there are over 6,000building fires in New South Wales, Australia, annu-ally (Fire & Rescue NSW 2006) and 41,000 dwellingfires in the United Kingdom in 2013 (Department forCommunities and Local Government [UK] 2013). Acontributing factor to fire-based fatalities is a lack ofevacuation knowledge or evacuation planing by indi-viduals. People often panic in fires. This can result indelayed evacuation time and extended exposure to firehazards. Therefore fire drills are a common feature infire evacuation exercises and training. However, con-

Copyright c⃝2015, Australian Computer Society, Inc. This pa-per appeared at the 11th Australasian Conference on Interac-tive Entertainment (IE 2015), Sydney, Australia, January 2015.Conferences in Research and Practice in Information Technol-ogy (CRPIT), Vol. 167, Yusuf Pisan, Keith Nesbitt and KarenBlackmore, Ed. Reproduction for academic, not-for-profit pur-poses permitted provided this text is included.

ducting fire evacuation drills in modern buildings un-der realistic fire conditions can be difficult (Gwynneet al. 1999). During fire drills, building occupantstypically exit at a leisurely pace, without having todeal with panic inducing events such as smoke filledcorridors, fires in unexpected places or blocked fireexits. Fire evacuation drills are either considerablydisruptive when they occur unannounced or tediouslyuneventful if routinely practised (Ren et al. 2006).

Instead of disruptive and unrealistic fire drills(Galea & Galparsoro 1994, Silva et al. 2013), virtualfire drills can support low cost evacuation trainingand provide opportunities to evaluate human evac-uation behaviours (Smith & Trenholme 2009, Xi &Smith 2014a,b). Thus virtual environment-based fireevacuation training systems have become increasinglypopular for various settings and environments, includ-ing in hospitals (Silva et al. 2013), in campus building(Smith & Trenholme 2009), in nuclear power stations(Mol et al. 2008) and in aircraft (Sharma & Otunba2012). Virtual environments have been used to de-velop fire evacuation training systems which bene-fit from high levels of graphical realism and multi-ple interaction methods. However, these systems of-ten have non-player-characters (NPC) with basic be-haviour as autonomous agents with realistic fire evac-uation behaviour are difficult to build as they mustaccurately simulate interaction with fire hazards, forexample the impact of poisonous gases, smoke, andheat on human behaviour.

Intelligent NPCs in virtual environments and firesimulations represent extra human agents in a sce-nario and require behaviours to imitate human per-ception and decision making in emergencies. The re-alism of NPC behaviours in interactive fire evacuationtraining systems plays a significant role, especiallywhen human users are required to make evacuationdecisions. Human decision making is a sophisticatedprocess. In a fire emergency, real human decisionsmay be influenced by current location, knowledge ofthe building (e.g. the familiarity level with locationof fire stairs or exits), personal preferences (e.g. entrypoints are preferred exits or evacuation paths), com-munication with other local individuals (e.g. familyor group members) and perception of the surroundingenvironment (e.g. temperature, smoke, and/or visibleflames) (Kobes et al. 2010). However, it is challengingto build such behaviours into NPCs.

One alternative to directly programming complexhuman behaviours into virtual environment appli-cations is to use existing fire evacuation models orevacuation simulators to provide fire science knowl-edge for the human behaviours to be simulated byNPCs during fire evacuations. Evacuation modelsare normally numerical simulators developed by firescience professionals. These simulators can calculate

Proceedings of the 11th Australasian Conference on Interactive Entertainment (IE 2015), Sydney,Australia, 27 - 30 January 2015

35

how fire spreads under environmental conditions, howsmoke and gas flow through buildings and how hu-man agents, i.e. evacuees, would behave under suchconditions. Frequently used fire simulators includeSimulex, FDS+Evac, VISSIM, STEPS, Pathfinderand EXODUS (for more details see (Kuligowski &Peacock 2005, Pelechano & Malkawi 2008, Ronchi &Kinsey 2011, Santos & Aguirre 2004)).

Besides NPC behaviours, creating realistic largescale virtual environments is a time consuming pro-cess. Compared with traditional virtual environmentdevelopment tools, game engines enable the swift de-velopment of 3D training systems (Smith & Tren-holme 2009, Trenholme & Smith 2008). This pro-cess is supported by a variety of game engine selec-tion methods and guidelines (Anderson et al. 2013,Marks et al. 2007, Petridis et al. 2010, Trenholme &Smith 2008). Previous virtual fire evacuation sys-tems are implemented in various of game engines,such as Source Engine (Smith & Trenholme 2009),Unreal Engine (Mol et al. 2008), Ogre3D (Ruppel &Schatz 2011) and Unity3D, also called Unity (Silvaet al. 2013).

Another challenge is the use of 3D buildings thatform the basis for any virtual fire drills. Both gameengines and evacuation simulators support creating3D models with built-in modelling tools. However,for individual scenarios, duplicating the effort to build3D buildings in both tools is a waste of resources andis error prone. As a consequence, using an indepen-dent 3D modelling tool to create models and exportthem to both the game engine and the fire simulatoris desirable. There are a variety of 3D modelling toolsthat can help developers create realistic 3D buildingmodels, such as SketchUp, 3ds Max and AutoCAD.

This paper describes work to extend a virtual en-vironment development pipeline for building virtualfire evacuation training systems (Xi & Smith 2014a)and explore the consistency of agent behaviour reuse.Section 2 will overview the pipeline to integrate 3Dbuilding models and fire egress behaviour from fireevacuation simulations into an example game engine.Next, we will describe the example building that hasbeen used to compare the agent behaviour extractedfrom the fire evacuation modeller with the agent be-haviour in the game engine. The aim is to ensurethat the behaviour of autonomous agents represent-ing human evacuees extracted from the fire simulatoris faithfully represented in the target virtual environ-ment. Four measures will be used to validate theimported building models and agent behaviour (Sec-tion 4). Consistent behaviour will be explored acrosstotal evacuee egress time, agent population scalabil-ity, scenarios with fire hazards and in an extendedbuilding with increased layout complexity. Conclu-sions and future work will be considered in Section 5.

2 Building Model to Game Engine Pipeline

A general pipeline was introduced by (Xi & Smith2014a) for creating a fire evacuation training systemin a virtual environment by combining 3D buildingmodels with human behaviours extracted from fireevacuation simulators, all imported and rendered ina gaming engine. Through this pipeline, developersare able to prototype a fire science knowledge basedevacuation system from a floor plan and basic fire sce-nario configuration. The 3D buildings can be mod-elled from floor plans in general 3D modelling tools,exported into evacuation simulators and then into agame engine to generate the target virtual environ-ment. The evacuation simulators use the imported

building models to run simulations with fire scienceknowledge and use this to generate agent behavioursfor the game engine. The human behaviours in thispipeline are represented as paths that agents chooseto evacuate the fire scenario during simulations. Theaim here is to script NPC movement behaviours byreusing evacuation paths generated from fire evacua-tion simulators and running the evacuation scenarioin a game engine within the same building model ex-ported from 3D modelling tool.

There are three types of software tool involved inthis pipeline, namely, 3D modelling tools, evacuationsimulators and game engines. Figure 1 summarisessome of the available options for each tool. The boldpath illustrates the software used in the examples pre-sented in Section 4 and will be described briefly below.

SketchUp was used as the modelling tool in thework described here. SketchUp is a 3D modelling toolfor applications including architecture design, gamedesign and other types of design. It has a free ver-sion called SketchUp Make and a commercial ver-sion named SketchUp Pro. Compared with complexCAD software, for example AutoCAD, SketchUp islight-weight with low hardware requirements. It alsohas an online repository called 3D Warehouse, whichprovides a large number of free 3D models. In theexamples described in this paper the free version ofSketchUp Make was used. The aim here is to generatea floor plan. Tools such as SketchUp enable develop-ers to easily draw 3D building models. What is im-portant here is that the selected tool should be ableto export 3D objects and attached textures to fre-quently used formats, for example, AutoCAD DWGfile (.dwg), AutoCAD DXF file (.dxf), FBX file (.fbx),or COLLADA file (.dae) file formats.

The second step of the pipeline is the generationof human behaviour paths. The simulation processis the most time consuming but critical procedureof the entire pipeline. During this procedure, theevacuation simulator with its built-in fire science isregarded as a “black box”. All decisions made byagents are based on in-built professional and com-plex fire science knowledge. In our pipeline, the be-haviours are regarded as the evacuation paths chosenby agents. The path selection frequencies by agentswill be used to script NPC behaviours in the gameengine. For the example pipeline presented in thispaper, we used FDS+Evac to generate human be-haviours as paths. Fire Dynamics Simulator (FDS) isa computational fluid dynamics (CFD) model of fire-driven fluid flow (McGrattan et al. 2013). Smokeview(SMV) is a program used to visualise FDS outputs(Forney 2013). FDS+Evac is the evacuation modelembedded in FDS, which is used to simulate howhuman egress from a scenario under the influence ofsmoke density and gases including O2, CO and CO2(Korhonen & Hostikka 2009). One disadvantage ofFDS+Evac is that there is no graphical user interface(GUI), which means users have to create their firescenarios by writing FDS scenario source code lineby line. This is a time consuming and error proneprocess when creating complex building models. Analternative is PyroSim which is a graphical user inter-face for FDS developed by Thunderhead Engineer-ing (www.thunderheadeng.com/pyrosim). PyroSimsupports importing CAD models, drawing complexgeometry objects with build-in tools, and managingcomponents including materials, surfaces, door/exit,agent types and agent initial positions. In this paper,PyroSim (FDS) with a free educational license was se-lected to run simulations and generate paths for NPCscripts used in the target virtual environment.

The final step of the pipeline is the integration of

CRPIT Volume 167 - Interactive Entertainment 2015

36

Figure 1: 3D building to game engine pipeline summary. The bold path indicates the tools used for theexamples in this paper.

Algorithm 1 Sample Script in Game Engine

if Random Number < 30 thenAgent choose RoomX Path A;

elseAgent choose RoomX Path B;

end if

the 3D building model and extracted fire-based egresspaths into the interactive environment, in this case afire drill simulation in a game engine (Xi & Smith2014b). Thus the focus here is on augmenting thegame engine NPC behaviour with fire science knowl-edge. This procedure starts with importing 3D mod-els and textures of the target building into the leveleditor provided by the game engine. Then humanbehaviour data generated from evacuation simulatorscan be imported into the game engine and used asNPC movement scripts. The NPC scripts should in-clude path selection frequency of how often agentschoose each available path, which are generated fromevacuation simulations. The selection frequency isimplemented as a range and determined, at run-time,by a random number. A general script is described inAlgorithm 1, which defines that the frequency for anagent in Room X to choose “Path A” is 30 percent,while 70 percent to choose “Path B”. This script willbe shared by all agents initiated in Room X. By al-tering the agent position (Room 1, Room 2, ..., RoomN), path label and selection frequency, all scripts canbe easily generated in the game engine. In this way,the NPC decision making process is controlled by arandom generator in the game engine scripts.

There are many game engines could be used to cre-ate virtual environments (Trenholme & Smith 2008)and for this project we have used the Unity3D engine.Unity3D is a modern game engine that supports de-

velopment of 2D and 3D games and interactive con-tent (Goldstone 2009). One major advantage of theUnity engine is that it supports multiple platformsincluding Macs, PCs and mobile platforms (Petridiset al. 2010). We used the free version Unity 4.5.2as an example engine for the case studies presentedin this paper because of its easy-to-use editor, C#scripting support and tutorials resources, includingvideos, sample projects and online documentation.

In the following section, we will describe the useof our pipeline to generate an example fire evacua-tion environment with the 3D building modelled inSketchUp, agent behaviour simulated in PyroSim andthe final visualisation of building egress in Unity.

3 Building a Fire Evacuation Environment

With the exception of a complex building test (seeSection 4.4), all the test cases presented in this paperwere based on a simple building model. The floor planof this test building is shown in Figure 2. The dimen-sions of this building are 10 m x 15 m x 3 m. There arethree exits in this building, EXIT TOP, EXIT LEFTand EXIT BOT. The building is divided into 9 areaswhere autonomous agents will be initiated, including5 rooms and 4 corridor areas. The overall evacua-tion time in PyroSim can be read from Smokeview,while evacuation time in Unity is recorded by addinga timer controller to the Unity virtual environment.

The first three tests presented in this paper ex-plored the pipeline mapping to the target virtual envi-ronment by evacuation time accuracy, agent numberscalability and the impact of adding fire hazards. Themajor configuration differences between these threetests are shown in Table 1 and will be detailed, asappropriate, in the following sections.

Proceedings of the 11th Australasian Conference on Interactive Entertainment (IE 2015), Sydney,Australia, 27 - 30 January 2015

37

Table 1: Configurations details for the evacuation time and scalability tests

Evacuation Time Test Scalability TestTest environment FDS+Evac Unity FDS+Evac UnityNumber of agentsper area 1 1 1/3/6/9/12/15/18 1/3/6/9/12/15/18

Agent velocity 1.05 m/s 1.05 m/s 1.05 m/s 1.05 m/sPre-evacuationtime

10 s 10 s 10 s 10 s

Known exits Share samepre-definedknown exits

Share samepre-definedknown exits

Exits are unknown to allagents

Not available in Unity3D

Path Share samepre-definedfixed path

Share samepre-definedfixed path

Generated by FDS+Evacaccording to actual build-ing involved in simulation

Randomly picked frompath lists generated fromsimulations in FDS+Evac

Figure 2: Floor plan of test building.

3.1 Exporting 3D Building Model fromSketchUp

The example building was modelled using SketchUpbased on a floor plan shown in Figure 2. Since thepurpose of this study is to test the accuracy of humanbehaviours in Unity against the original behaviours inFDS+Evac, high realism textures are not required forthe 3D model. In order to use this model in PyroSimand Unity, it was exported to AutoCAD DWG file forPyroSim via the SketchUp build-in export tool, whilethe model for Unity was exported to a COLLADAfile using a third party plug-in named PlayUp (seeFigure 1).

3.2 Egress Path Generation in FDS+Evac

After importing the model, there is a need to cre-ate meshes for FDS+Evac to determine simulationevents. All FDS simulations are computed by split-

ting the environment into rectilinear volumes calledmeshes. Details of mesh definition and use are outsidethe scope of this paper (see FDS User’s Guide (Mc-Grattan et al. 2013)). Here the mesh cell size was setto 0.333 m x 0.375 m x 3.25 m. Next, agents were pop-ulated into the environment to represent the evacueesinvolved in the evacuation. FDS+Evac provides fivecustomizable agent types. Based on the adult typeof agent, we set the agent reaction time, which is re-garded as pre-evacuation time, to a constant value of10 seconds. In addition to reaction time, the humanwalking velocity was also set to a constant value of1.05 m/s as shown in Table 1.

The purpose of conducting the simulations inFDS+Evac is to generate the statistics of regularizedbehaviours, i.e. the paths selected by the agents dur-ing the evacuation. Paths are defined based on theagent’s initial area to evacuation points/exits. Allagents initiated in the same area share the same setof paths. As this building is divided into 9 areas,there should be at least 9 sets of paths as at least1 agent was placed in each area. However, an areamay have a set of paths, consisting of a number ofpaths, which are decided by simulation results. Multi-ple paths may be generated from multiple simulationsbased on simulation events such as fire or exit viewobstruction. For example, if an agent leaves RM2,then passes AREA2 and AREA4, and finally egressesthrough EXIT LEFT (areas and exits are labelled inFigure 2), the path is described as:

P R2 = RM2 → AREA2 → AREA4 → EXIT LEFT

As suggested in the FDS+Evac User’s Guide (Ko-rhonen & Hostikka 2009), a dozen simulations shouldbe run to achieve a stable result. Defining the numberof simulations that are required to find all the possi-ble unique paths is outside the scope of this paper.In this paper, 30 simulations were conducted for eachtest.

3.3 Fire Evacuation in Unity

The 3D building model that was exported as a COL-LADA file from SketchUp via PlayUp plug-in and wasimported into the Unity engine. To make it possibleto identify each area, a floor was added to the originalmodel and relevant areas were coloured. Exits in Py-roSim were replaced by assembly points and definedas green areas in Figure 3. Since this paper is focusedon exploring and validating the pipeline, the graphi-cal realism of virtual environment is less important.A simple cylinder model was used to represent thehuman model, e.g. the NPCs.

CRPIT Volume 167 - Interactive Entertainment 2015

38

During this procedure, the key task is coding theNPC scripts representing the egress paths. Pathswere implemented using Unity scripting ApplicationProgramming Interface (API) and are triggered byevent or threshold values. The Random.range func-tion provided by Unity was used as a random numbergenerator to control the path selection when multiplepaths had been generated from an area. The scriptswere generated in C# using Algorithm 1 described inSection 2.

Figure 3: Imported building model in Unity.

4 Testing the Pipeline

Four tests were performed to explore the consistencyof agent behaviour as extracted from the fire evacu-ation modeller and integrated into the game engine-based virtual environment. The long term goal ofthe project is to extend the fire evacuation virtualenvironment with increasingly complex scenarios andnew interactive behaviours. Therefore it is impor-tant to determine whether the reused components, inthis case the agent behaviours in the presence of firehazards, has been accurately generated and importedinto the game engine. In the following tests, we haveexplored examples across total evacuee egress time ina fire-free environment, agent population scalabilityand evacuee egress behaviour with fire hazards andin an extended building with increased layout com-plexity.

4.1 Evacuation Time Test

During an evacuation, the most important thing isthat all the evacuees successfully evacuate from thebuilding and how much time the evacuees take toegress. There are two critical questions about theoverall evacuation time: (i) it is unknown if thereis any difference in the evacuation time between thesource simulator and the target game engine, (ii) ifthere is such difference, why it happens and whetherthis difference is acceptable.

A realistic time should be between its optimaland worst case situations. As described in Table1, there was 1 evacuee for each area in both Unityand FDS+Evac (see Figure 2) for a base line mea-sure without NPC collisions at the doors. There arefour benchmarks of building egress that we can de-termine from the building model, namely (i) the op-timal case time, (ii) the worst case time, (iii) the casewhen agent placements are optimal in rooms/areasbut then choose the worst building exits and (iv) thecase when agent placements in rooms/areas are theworst but they choose the best possible exits. Thesecombinations are summarised as:

• Best start position and best exit strategy (BPBE)

• Worst start position and worst exit strategy(WPWE)

• Best start position and worst exit strategy (BPWE)

• Worst start position and best exit strategy (WPBE)

For simplicity we will assume that all agents moveconcurrently, at a velocity of 1.05 m/s, do not col-lide with each other and all have a pre-evacuationthinking time of 10 seconds. Thus we can define thefinal egress time by the last agent to leave the build-ing. For example, with best start position and bestexit strategy (BPBE), the slowest agent to exit willbe from RM 2 (optimally positioned at the door) tothe exit (EXIT LEFT) directly opposite (see Figure4), with a distance of 6m to travel and an exit timeof 15.71 seconds. The worst start position and worstexit strategy (WPWE) will be an agent placed in theback corner of RM1 and exiting through the bottomexit (EXIT BOT), with an exit time of 27.05 seconds.The other benchmark routes are shown in Figure 4.

Figure 4: Four benchmarked egress routes.

The 3D building models in FDS+Evac and Unityhave the same dimensions as they are based on thesame floor plan. What is different is that they havedifferent agent moving tracks and collision detectionmechanisms to deal with evacuation flow conjunc-tions. These differences might result in different evac-uation time. Compared with the fixed initial positions(see Figure 4), agents were placed with random initialpositions and face directions in both FDS+Evac andUnity. The results after 30 simulations are shown inTable 2.

The overall evacuation time in both FDS+Evacand Unity are between the optimal and the worst sit-uation, specifically between WPBE and BPWE (see

Proceedings of the 11th Australasian Conference on Interactive Entertainment (IE 2015), Sydney,Australia, 27 - 30 January 2015

39

Table 2: Comparison of total evacuation times (inseconds). The results of Unity and FDS+Evac timesare averages

Table 2). This is because the agents have random po-sitions between the best position (BP) and the worstposition (WP) and they do not always choose the bestexit in the both Unity and FDS+Evac simulations.However, the time in Unity is approximately 3.85 sec-onds shorter than that in FDS+Evac. This is causedby different walking track planning and turning mech-anisms between Unity and FDS+Evac. Agents inUnity always take the shortest path towards the des-tination (target), while in FDS+Evac, agents take alonger and less optimal travel distance. As the pathsare determined by area to area movements and theactual path is determined at run-time by the Unityengine, this is a side-effect of more efficient path op-timisation for autonomous agents in Unity. However,both FDS+Evac and Unity have realistic evacuationtimes when compared to the benchmark evacuationtimes (see Table 2), while Unity has slightly betterperformance due to optimised path planning func-tions.

4.2 Agent Population Scalability Test

Section 4.1 has shown that the evacuation time inboth Unity and FDS+Evac fall into a realistic range.However, there were only 9 agents involved in thistest. Of more interest is exploring the performance ofthe pipeline with a scenario including a larger agentpopulation, for example 50 agents or 100 agents. Thetest presented in this section aims to demonstratethat the pipeline is still valid with increasing numbersof agents in the evacuation simulation. As shown inTable 1, the number of agents placed in each areais increased from 1 to 18, with the total number ofagents increased from 9 to 163. 30 simulations wereconducted to calculate the average evacuation timefor each number of agents.

The overall evacuation time shows a linear growthwhen the number of agents in the scenario is no morethan 27 (see Figure 5). Thereafter, the evacuationtime in Unity and FDS+Evac both grow much faster,but still linearly. However, Unity has a slower growthrate than FDS+Evac, especially when the total num-ber of agents is over 54. This might be because withmore agents in a scenario, more collisions are caused.This is indicative that the agent moving performanceand collision detection in Unity are better than thosein FDS+Evac. One thing that should be noted isthat when the total number of agents reached 162,the area per agent was very small with only 0.93 m2

(150 m2/162), which is unlikely to happen in the realworld. Thus, it is reasonable to expect that the over-all evacuation time in Unity will always shorter thanthat in FDS+Evac. The same trend of time increasebetween these two environments also demonstratesthat the scalability of this pipeline is consistent witha large number of agents involved in the simulation.

4.3 Fire Hazard Test

The evacuation time and scalability test have shownthe accuracy and stability of the pipeline in a firefree evacuation. However, without fire hazards in the

environment, agent behaviour is determined by basicevacuation behaviour and there is no validation thatthe extracted paths are taking into account the firescience knowledge embedded in the fire evacuationmodeller, e.g. from FDS+Evac. Our interest hereis how the agents will behave when facing a fire andhow this impacts path generation by FDS+Evac andreuse in Unity. Thus this test explores the pipelinewhen fires are added to the scenario.

Based on the same floor plan (see Figure 2), fireswere added to various locations in the test build-ing. An example fire location is shown in Figure6 where a fire is located in AREA3, blocking theexit EXIT BOT. As with the previous tests, agentbehaviour was generated from 30 simulations in Py-roSim and then used in Unity. The configuration ofthe environment for the fire test is defined in Table 3.

Figure 6: Floor plan with an example fire location.

In this test, fires in Unity were represented as a redcube object as shown in Figure 7. To easily observeagent movements, we identified paths by assigningeach agent a unique colour using customizable tex-tures provided by Unity. The agent path was repre-sented as a stream of dots using the Unity instantiatefunction. The instantiate function can create cylinderobjects by fixed intervals when NPCs moved on thefloor, thus drawing a coloured path for each agent.

Compared to the optimal evacuation paths de-scribed in Section 4.1 (also shown in Figure 8), agentsin RM3, RM4 and AREA3 chose to evacuate throughEXIT LEFT instead of the closest EXIT BOT, whichwas blocked by fires (see Figure 7). In addition tofires at EXIT BOT, agent movements were also testedwith other fire locations such as EXIT TOP (see Fig-ure 9) and AREA 4 (see Figure 10). The results showthat agents in Unity behaved as expected when facingfires using the paths generated from the FDS+Evac

CRPIT Volume 167 - Interactive Entertainment 2015

40

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

9 27 54 81 108 135 162

Ove

rall

Evac

uat

ion

Tim

e (

s)

The Total Number of Agents Involved in Simulation

Unity PyroSim

Figure 5: Increase of overall evacuation time against the total number of agents in simulations using Unity andFDS+Evac (via PyroSim).

Table 3: Configurations details for the fire tests and extended building complexity test

Fire Test Extended Building Complexity TestTest environment FDS+Evac Unity FDS+Evac UnityNumber of agentsper area 1 1 1/5/10/15 1/5/10/15

Agent velocity 1.05 m/s 1.05 m/s 1.05 m/s 1.05 m/sPre-evacuation time 10 s 10 s 10 s 10 sKnown exits Exits are un-

known to allagents

Not available inUnity3D

Exits are un-known to allagents

Not available inUnity3D

Path Generated byFDS+Evac ac-cording to actualbuilding involvedin simulation

Randomlypicked from pathlists generatedfrom simulationsin FDS+Evac

Generated byFDS+Evac ac-cording to actualbuilding involvedin simulation

Randomly pickedfrom path listsgenerated fromsimulations inFDS+Evac

Figure 7: Fire evacuation path in Unity with fire haz-ard at EXIT BOT.

simulations.Figure 11 shows that the overall egress time in

Unity is approximately 5 seconds shorter than that inFDS+Evac. This is similar to the results described inSection 4.1 and as noted above this is because Unityhas better path planning and agent turning mech-

Figure 8: Fire evacuation path in Unity (fire free).

anisms. Therefore, the simulated behaviours andegress times indicate that the pipeline can accuratelyreuse fire science knowledge from FDS+Evac to cre-ate consistent NPC behaviour in the presence of firehazards.

Proceedings of the 11th Australasian Conference on Interactive Entertainment (IE 2015), Sydney,Australia, 27 - 30 January 2015

41

Figure 9: Fire evacuation path in Unity with fire haz-ard at EXIT TOP.

Figure 10: Fire evacuation path in Unity with firehazard at AREA4.

Figure 11: Comparison of total evacuation times withfire hazards in the environment. (NB. The results ofUnity and FDS+Evac times are averages.)

4.4 Extended Building Complexity Test

Section 4.3 has shown agent behaviour when thereare fire hazards in the scenario. However, in addi-tion to having a limited agent population, the exam-ple 3D building model used was too simple to showthe performance of pipeline under increased buildingcomplexity. Thus we have explored the pipeline whenusing a more complex building. Complexity was in-creased by constructing a larger, extended, floor planwith additional connected rooms and corridor areas.Figure 2 shows the extended building model with afire hazard in a middle area and Figure 13 shows thesame extended building as imported into Unity.

As described in Table 3, the maximum agent pop-ulation involved in this test has increased from 162 to

Figure 12: A floor plan of an extended building withan example fire hazard.

Figure 13: Unity model of extended building show-ing fire hazard location and placement of 1 agent perroom/area.

270. Compared to previously used model (see Figure2), the new model has more agent start areas, as thebuilding has 10 rooms, 8 corridor areas and 4 exits(see Figure 12). With a fire hazard present in the en-vironment, the average evacuation time for increasingnumber of agents is shown in Figure 14. The sametrend of evacuation time increase between this testand previous agent population scalability test (seeSection 4.2) was found. The evacuation time increasessmoothly when the number of agents is no more than90. Thereafter, the evacuation time in FDS+Evac(PyroSim) grows much faster, while a similar increaseto the previous scalability test is found in the Unityexamples. This result further confirms that evacua-tion time in Unity is shorter than FDS+Evac due tobetter inbuilt path planning functions for autonomousagent navigation and collision detection and avoid-ance in Unity. In the scope of the current work, thisprovides confidence that the increasing scale of thescenario does not negatively impact the reused agentbehaviour in the target virtual environment.

5 Conclusions

This paper has described work to extend a virtual en-vironment development pipeline for building virtualfire evacuation training systems. The pipeline inte-

CRPIT Volume 167 - Interactive Entertainment 2015

42

0

20

40

60

80

100

120

140

160

180

18 90 180 270

Ov

era

ll E

va

cua

tio

n T

ime

(s)

The Total Number of Agents Involved in Fire Simulation

PyroSim Unity

Figure 14: Increase of overall evacuation time against the total number of agents in the extended buildingexample in Unity and FDS+Evac (via PyroSim).

grates 3D building models and fire egress behaviourfrom fire evacuation simulations into a game engine.The aim is to extract behaviour of autonomous agentsrepresenting human evacuees from fire evacuationsimulations and integrate this into a target virtualenvironment. It is important that consistent agentbehaviour is mapped to the target environment andthat, in this case, any path navigation is at least asgood as the paths used in the source simulations. Inorder to explore the validity of the pipeline, four testson evacuation time across different environment sce-narios have been conducted.

Evacuation time tests, with and without fire haz-ards, have shown that the overall evacuation time inFDS+Evac and Unity are consistent. The time differ-ence between FDS+Evac and Unity is caused by dif-ferent collision detection and path planning functions.However, the agent type used here in FDS+Evac ismodified from the default Adult type, which has apre-defined velocity and pre-evacuation time. Addingmore types of evacuees and changing the reactiontime, including pre-evacuation time, might signifi-cantly change the overall evacuation time. For exam-ple, in some real fire accident cases, disabled individ-uals and elderly individuals may cause unexpected in-teractions when encountered by other evacuees. Thepre-evacuation time of each evacuee may also varyfrom 50s to over 300s (Lawson 2011). Thus the per-formance of the pipeline with complex agent typesneeds further investigation.

FDS+Evac has a strong scalability that can sup-port up to 10,000 agents in one evacuation mesh (Ko-rhonen & Hostikka 2009). Although it is unlikelyto use such a large population in the test buildingsfrom this paper, it would be interesting to explore thepipeline approach with an extremely large buildingwith hundreds of residents, for example, simulatinga shopping mall or sports stadium. Both scalabilitytests have shown that the pipeline is stable with largenumbers of agents. Even when there were 270 agentsin the extended building, the scripted NPCs in Unitystill behaved as we expected.

Besides the accuracy and stability in fire free sce-

narios, the fire test further validated this pipeline in asimple fire environment. Across the tests, the NPCsin Unity escaped the building in a realistic time, whencompared to best and worst case alternatives, andmade appropriate decisions as in FDS+Evac simula-tion. However, we did find that agents occasionallytried to cross fire zone leading to failed evacuation in4 of 90 simulations (4.44%) in FDS+Evac. The fail-ure to egress impacts the generation of the paths tobe reused in the target virtual environment. Whetherthere are issues with the FDS+Evac simulation or inthe configuration of the scenarios warrants further in-vestigation.

In summary, fire science knowledge plays an im-portant role in virtual environment based fire evac-uation training systems. Using fire evacuation sim-ulator to support virtual environment developmentis a promising method to help virtual environmentdevelopers create realistic fire science based NPC be-haviours. The pipeline described here can reduce thedevelopment cost, boost the development process andimprove the realism of virtual environment-based firetraining systems. This paper has described work thatexplores such a pipeline for consistency of behaviour,agent scalability, building complexity and with firehazard examples. Future work includes testing thepipeline against more complicated configurations, forexample various types of agents, especially disabledindividuals, children and elderly adults, since theyvary in walking speed which may result in unexpectedinteractions during fire evacuations. Finally, we in-tend to apply the pipeline to a real campus buildingwith multiple floors and pre-defined fire stairs andexits.

6 Acknowledgments

Mingze Xi is a PhD candidate and is supported bya University of Newcastle International PostgraduateResearch Scholarship.

Proceedings of the 11th Australasian Conference on Interactive Entertainment (IE 2015), Sydney,Australia, 27 - 30 January 2015

43

References

Anderson, E. F., McLoughlin, L., Watson, J., Holmes,S., Jones, P., Pallett, H. & Smith, B. (2013), Choos-ing the infrastructure for entertainment and seri-ous computer games - a whiteroom benchmark forgame engine selection, in ‘5th International Con-ference on Games and Virtual Worlds for SeriousApplications (VS-GAMES)’, pp. 1–8.

Department for Communities and Local Gov-ernment [UK] (2013), ‘Fire Statistics: GreatBritain April 2012 to March 2013’, https:// www. gov. uk/ government/ statistics/fire-statistics-great-britain-2012-to-2013(Last Access: 12/11/2014).

Fire & Rescue NSW (2006), ‘Fire & RescueNSW Annual Statistical Report’, http: // www.fire. nsw. gov. au/ page. php? id= 171 (Last Ac-cess: 12/11/2014).

Forney, G. P. (2013), Smokeview, A Tool for Visu-alizing Fire Dynamics Simulation Data Volume I:User’s Guide, National Institute of Standards andTechnology, US Department of Commerce.

Galea, E. & Galparsoro, J. P. (1994), ‘A computer-based simulation model for the prediction of evac-uation from mass-transport vehicles’, Fire SafetyJournal 22(4), 341 – 366.

Goldstone, W. (2009), Unity Game Development Es-sentials, Packt Publishing Ltd.

Gwynne, S., Galea, E., Owen, M., Lawrence, P. & Fil-ippidis, L. (1999), ‘A review of the methodologiesused in the computer simulation of evacuation fromthe built environment’, Building and Environment34(6), 741 – 749.

Kobes, M., Helsloot, I., de Vries, B. & Post, J. G.(2010), ‘Building safety and human behaviour infire: A literature review’, Fire Safety Journal45(1), 1–11.

Korhonen, T. & Hostikka, S. (2009), ‘Fire dynamicssimulator with evacuation: Fds+evac: Technicalreference and user’s guide’, VTT Working Papers(119).

Kuligowski, E. D. & Peacock, R. D. (2005), A Reviewof Building Evacuation Models, National Instituteof Standards and Technology, US Department ofCommerce.

Lawson, G. (2011), Predicting Human Behaviour inEmergencies, PhD Thesis, The University of Not-tingham.

Marks, S., Windsor, J. & Wunsche, B. (2007),Evaluation of game engines for simulated surgicaltraining, in ‘Proceedings of the 5th InternationalConference on Computer Graphics and InteractiveTechniques in Australia and Southeast Asia’, ACM,New York, NY, pp. 273–280.

McGrattan, K., Hostikka, S., McDermott, R., Floyd,J., Weinschenk, C. & Overholt, K. (2013), Fire Dy-namics Simulator: User’s Guide, National Insti-tute of Standards and Technology, US Departmentof Commerce and VTT Technical Research Centreof Finland.

Mol, A., Jorge, C. & Couto, P. (2008), ‘Using agame engine for vr simulations in evacuation plan-ning’, IEEE Computer Graphics and Applications28(3), 6–12.

Pelechano, N. & Malkawi, A. (2008), ‘Evacuationsimulation models: Challenges in modeling highrise building evacuation with cellular automata ap-proaches’, Automation in Construction 17(4), 377– 385.

Petridis, P., Dunwell, I., de Freitas, S. & Panzoli, D.(2010), An engine selection methodology for highfidelity serious games, in ‘2nd International Con-ference on Games and Virtual Worlds for SeriousApplications (VS-GAMES)’, pp. 27–34.

Ren, A., Chen, C., Shi, J. & Zou, L. (2006), Applica-tion of virtual reality technology to evacuation sim-ulation in fire disaster, in ‘Proceedings of the 2006International Conference on Computer Graphicsand Virtual Reality’, CSREA.

Ronchi, E. & Kinsey, M. (2011), Evacuation mod-els of the future: Insights from an online surveyon user’s experiences and needs, in J. Capote &D. Alvear, eds, ‘Proceedings of the Advanced Re-search Workshop: ”Evacuation and Human Be-haviour in Emergency Situations”’, Universidad deCantabria, pp. 145–155.

Ruppel, U. & Schatz, K. (2011), ‘Designing abim-based serious game for fire safety evacua-tion simulations’, Advanced Engineering Informat-ics 25(4), 600 – 611. Special Section: Advancesand Challenges in Computing in Civil and Build-ing Engineering.

Santos, G. & Aguirre, B. E. (2004), A critical re-view of emergency evacuation simulation models,in ‘NIST Workshop on Building Occupant Move-ment during Fire Emergencies’, National Instituteof Standards and Technology.

Sharma, S. & Otunba, S. (2012), Collaborative vir-tual environment to study aircraft evacuation fortraining and education, in ‘2012 International Con-ference on Collaboration Technologies and Systems(CTS)’, pp. 569–574.

Silva, J. F., Almeida, J. E., Rossetti, R. J. & Coelho,A. L. (2013), A serious game for evacuation train-ing, in ‘IEEE 2nd International Conference on Seri-ous Games and Applications for Health (SeGAH)’,IEEE, pp. 1–6.

Smith, S. P. & Trenholme, D. (2009), ‘Rapid pro-totyping a virtual fire drill environment usingcomputer game technology’, Fire Safety Journal44(4), 559 – 569.

Trenholme, D. & Smith, S. P. (2008), ‘Computergame engines for developing first-person virtual en-vironments’, Virtual Reality 12(3), 181–187.

Xi, M. & Smith, S. P. (2014a), Reusing simulatedevacuation behaviour in a game engine, in ‘2014Interactive Entertainment’, ACM, New York, NY.

Xi, M. & Smith, S. P. (2014b), Simulating cooperativefire evacuation training in a virtual environment us-ing gaming technology, in ‘2014 IEEE Virtual Re-ality (VR)’, IEEE, pp. 139–140.

CRPIT Volume 167 - Interactive Entertainment 2015

44