# Design of a Mixed Reality System for Simulating Indoor Disaster Rescue
## 3 Materials and Methods
### System Design  
This section describes how we designed the MR system using the Unity game engine. With Unity, objects rotate or move relative to the left-handed coordinate system. An icon representing the user's location is placed on the indoor map on system startup. Then, the camera is rotated along the X-axis by 90\({}^{\circ}\) and Y-axis by 180\({}^{\circ}\); the Z-axis remains fixed so that the indoor map and user position icon can be viewed from the front. The reason for using this design is that rotating the Y-axis causes the map to rotate such that it does not affect Y-axis rotation; the X-axis affects the movement, and the Z-axis rotates the map according to the direction of the user position icon (based on the X-axis value). The system is designed to accurately calibrate the user's location icon on the fixed indoor map user interface by dividing 5.0 position correction values for the X and Z coordinates and adding the X and Z coordinate values to the starting point. Calibration is performed because there is a difference in the coordinates calculated by the hardware and software. Five pixels on the screen represent the movements of \"1.0 coordinate values\" in the Unity coordinate system. Figure 6 shows how the system's user position icon is displayed on the indoor map.  
Figure 5: Flowchart of the MR system simulating indoor disaster rescue.  
Once the system is started and the status window is activated, the user sees their current direction, the next direction, the next distance, and time to reach the next destination. The thread processing feature of Unity is required because the state information must change when the calculated values are applied to the status window. Because the socket thread does not have access to the status window, it makes a request to the main thread. Then, a queue is created and shared with the main thread. The socket thread progresses data along the queue. Unity's main thread periodically checks the size of the queue, and modifies it if data that would require a change in the information displayed by the status window are available. Figure 7 shows the status window processes.  
When the MR system is activated, a virtual indoor disaster situation is randomly generated, including a virtual victim. An escape point is created upon rescue completion. The navigation function is designed to be displayed as an arrow in front of the user. To guide the user to the victim's location, the navigation arrow rotates based on the angle of the axis where the victim is located. A correction value of 0.5 is applied so that the arrow does not move from the front position, where it points to the victim; the arrow only rotates from the front position to aid interpretation. Regarding the escape point created after victim rescue, the navigation arrow rotates based on the angle of the designated escape route. Because exits generally have many stairs, the simulation is designed such that escape occurs when the y-axis value is <0. Figure 8 describes the navigation function.  
Figure 6: The user’s location is displayed as an icon on the indoor map.  
Figure 7: Status window processes.  
As stated above, the MR system simulates disaster situations requiring the rescue of victim/s. Pre-mapped spatial data are stored in the device's memory. When activated, the system randomly generates virtual disaster sites and victims asynchronously. A button corresponds to the victim's location; when the button is clicked, the victim object is deactivated (i.e., they are rescued). Figure 9 shows a schematic of the indoor virtual disaster.  
The system is configured to run three scenarios, as shown in Figure 10. The situation varies among the scenarios and users can select the scenario of their choice. Figure 11 shows the system specification.  
Figure 8: Navigation function guiding the user toward the victim and exit.  
Figure 9: Schematic of the indoor virtual disaster.