# AR Presentation of Team Members' Performance and Inner Status to Their Leader: A Comparative Study
## 4 Simulated AR in VR Application: MATB-II-Collab
### Operator Model  
Operators are automated virtual team members controlled by the experimental platform. Their avatar is either controlled by inverse kinematics animation for the four tasks or by skeleton animation when the avatar is idle. The operators virtually perform the four tasks of the NASA MATB-II [44] on a virtual screen interface in front of them, see Figure 3. The avatars of the operators replay previously recorded movements with inverse kinematics (using FinalIK). The movement data set comprises more than ten different recordings for each task recorded from a person performing the four MATB-II tasks in a VR setting with the experimental platform. The playback speed for each animation was adjusted to last for 10 s. If not replaying a recorded animation, the avatar of the operator plays one randomly chosen idle animation among the six skeleton animations from the Mixamo library. Inverse kinematics interpolates the positions of the hands and head to ensure consistently smooth movement when the avatar transitions between recorded movements and other animations [45].  
The team leader puts tasks in the operators' task queues. Operators will perform their tasks one after another without resting between them until the queue is empty, following a FIFO (First In, First Out) pattern. When an operator's task queue is empty, they are on a rest break until new tasks are placed in their queue.  
Each operator has a speed multiplier; with a speed of 1.0, an operator will execute a task in 10 s (the normalized time for all tasks); with a speed of 1.5, they will execute the task in 6.7 s and, with a speed of 0.75, they will execute the tasks in 13.3 s. Two operators have a speed multiplier of 0.75, two operators have a speed multiplier of 1.0, and two have a speed multiplier of 1.5.  
Operators have a _simulated stress_ attribute to refer to their internal status (normalized to a 0.0-1.0 range). The team leader's action of adding a task to an operator's task queue progressively increases the _simulated stress_ experienced by that operator, which we call _stress charge_. The total amount of _simulated stress_ per task experienced by an operator is not impacted by the speed at which the operator completes the task; thus, the _stress charge_ is obtained by multiplying the speed of the operator by the _stress charge_ parameter. Operators' _simulated stress_ decreases with time, which we call _stress cooldown_; all operators have the same rate of _stress cooldown_, another parameter of the experimental platform. The _stress charge_ parameter must be stronger than the _stress cooldown_ parameter to increase operators' _simulated stress_ when they work, as their _simulated stress_ evolves by the following Algorithm: _As long as the simulation is running, the operator's simulated stress decreases by the cooldown rate, then it increases by the charge rate if the operator has a task to perform.  
The experimental platform makes a probabilistic determination of whether an operator is successful for each task. The more stressed an operator is, the more likely they will not succeed with the task. We distinguish three different levels of _simulated stress_: Low, medium, and high, with two parametrable thresholds to separate them. With a low level of _simulated stress_, there is a low chance of failure by an operator, and at a high level of _simulated stress_, the operator is almost certain to fail at the task. A parametrable function defines a task's failure probability according to the _simulated stress_ level. As a performance measure, for a score of 1 min, the failure probability is given to an operator after performing a task. Operators have no preference or skill differences among tasks.  
Initial conditions of the virtual environments and operators' attributes will be described in Section 5.1.