REPORTE DE PLANIFICACIÓN

Detailed measurements and results of EyeCVE’s performance in a two-CAVE link are now presented. The data provides insight into the resulting system performance from a minimum-load setup. It should be noted that this evaluation was performed with an early version of EyeCVE, and that the initial (lower refresh rate) MobileEye eye trackers were used rather than the high-performance ViewPoint eye trackers. Additionally, the test was performed using basic avatars rather than advanced avatars featuring facial ex- pression. Subsequent development of EyeCVE’s rendering and network components have significantly increased performance: particularly regarding the number of updates in avatar animation frames per

3.1. EyeCVE System Overview 95

Figure 3.16: Opening phase of mouth movement performed by male advanced avatar upon detection of audio input from microphones worn by users. Closing phase reverses the sequence at a faster rate.

Figure 3.17: Processing pipeline from sending to receiving site. R1– R5represent the various simulation cycle rates at each stage.

second between remote sites. Nevertheless, the following evaluation of the system is still relevant, pro- viding a baseline performance measure that satisfies the temporal and spatial requirements of a tracked gaze AMC system specified in Section3.1.1.

This evaluation is particularly concerned with the time taken to process and distribute gaze data, as well as characteristics of loss and discontinuity of the synthesised information. To analyse the data, avatar update traffic was logged at various stages within the processing pipeline when sending avatar updates from one site to another. Figure3.17illustrates the processing pipeline of the system. Gaze data is firstly acquired by the eye trackers and sent over the local area network to the local client. The data is then applied to the local object simulation, calculating the local avatar’s eye angles, including vergence, with respect to head orientation. The resulting angles are sent as an update message over the Internet and passed via the relay server to the receiving client’s object simulation. The message is then applied to the respective avatar, before rendering at the receiving site’s display.

3.1. EyeCVE System Overview 96 Acquisition and simulation processes run on separate machines, and thus may run at different speeds. The filtered eye tracking acquisition rate, R1, is variable, and for this evaluation, was set to the following rates over a series of sessions: 5 Hz (200 ms), 10 Hz (100 ms), 20 Hz (50 ms), and 50 Hz (20 ms). The MobileEye eye tracker supports a maximum update rate of 30 Hz, so in the case of 50 Hz, the effects of driving the device above its specification are investigated. R2represents the object simulation rate of the sending client, and R4represents that of the receiving client. The actual display is refreshed at rate R5, independent of the object simulation cycle. In this evaluation, both clients operate on very similar machines, so only minor performance differences are expected. Hence, no investigation into varying object simulation and display rates is performed. R3was also left constant.

The procedure of each of the five test sessions was as follows: 1. Configure the specified update rate on eye tracker driver; 2. Connect the two EyeCVE clients and calibrate gaze;

3. Users asked to walk around and look at a set of virtual objects laid out on a virtual table;

4. Users take turns looking and pointing towards specific objects while partner who follows direction of gaze;

5. Log all incoming and outgoing updates locally at each site.

Occurrences of avatar updates at time of acquisition, sending simulation, and receiving simulation were logged. Each log entry included a time-stamp, object ID, and current position coordinates. In order to identify individual updates within the log files, each entry was tagged with an incrementing frame number. During the tests, threshold filtering was activated, which discarded tracking updates featuring less than 3 cm or 1◦ difference from the last transmitted update. The ordering mechanism discarded obsolete updates, as described in Section3.1.2. This implies that packets may be discarded due to redundancy filtering or ordering, making the measurements dependent on the specific task and activity of the interactants. However, these preliminary results are sufficient to demonstrate typical system characteristics.

The hardware environment consisted of two CAVE systems with dimensions of 3m3. The stereo projection screens have a resolution of 1024×786 and a refresh rate of 96 Hz. Computation was provided by an SGI Prism system at each site. The eye trackers were connected to Intel Pentium D or Core Duo PCs, equipped with 1Gbit/s Ethernet cards. The relay server hosting the EyeCVE sessions ran on the SGI Prism at one site. The test VE consisted of a single room with nine objects arranged in three rows over a table. The objects were positioned approximately 1.5 metres from the CAVE floor (i.e. at approximately eye height of both users and their avatars). The complexity of the entire scene was approximately 24000 polygons.

Results

Four sessions were conducted, each with a specific update rates set on the MobileEye eye tracker driver. The duration of each session, from connection to disconnection varied between 3–5 minutes due to differences in time taken for setting up and calibrating the eye tracker in EyeCVE. The measurements presented in this section refer to values collected over a 100 second period during each session in which the gaze task was ongoing.

3.1. EyeCVE System Overview 97 0 5 10 15 20 25 30 R1=5Hz R1=10Hz R1=20Hz R1=50Hz Processed Updates/s Rate Acquired Lost/Discarded on Send Sent Lost/Discarded on Receive Applied

Figure 3.18: Frequency (occurrences) of updates that passed through the system at various stages.

Figure3.18shows the frequency of updates that passed through the processing pipeline at acquisi- tion, distribution and representation with varying R1. The graph also shows the frequency of occurrences where updates that were lost in transit over a network, or discarded due to redundancy or ordering during object simulation, at either the sending or the receiving site. The figure demonstrates how new updates were generated at the selected acquisition rates. However rate of updates that were actually sent and applied did not increase beyond 8 Hz. An acquisition rate that is higher than the simulation rate results in updates being queued, and subsequently superseded and discarded. An acquisition rate close to that of the simulation rate yields a throughput of 80% of gaze updates, while approximately 15% were lost or discarded after acquisition, and 5% were lost during, or discarded after, transmission over the Internet. Almost every update message that was sent from the sending client was received in the correct order at the receiving client.

Figure3.19shows an example of latency measurements taken during the session in which R1was set to 20 Hz. It shows how the resulting end-to-end latency of the system is composed of the delays induced by the individual modules within the processing pipeline. The measured times are as follows: T1is the time it takes to deliver a message containing new eye tracker data from the MobileEye to the sending client over the local intranet, including the time for sending and the time that new data resides in the receiving buffer before it is read by a simulation call; T2is the time it takes the simulation process on the sending site to calculate gaze, plus other minor management tasks; T3is the latency for sending update messages over Internet; T4is the time it takes the object simulation on the receiving site to read new updates from the receiving buffer, apply the update to the avatar object, and update the scene graph just before the renderer is called. It is evident from Figure3.19 that the time taken to acquiring eye tracker data and apply the simulated data to the avatar on the receiving site comprises a smaller part of

3.1. EyeCVE System Overview 98 0 50 100 150 200 60 65 70 75 80 Latency (ms) Time (s) Latency, Site1 -> Site2 (R1=20Hz)

T1 (Acquire) T2 (Compute) T3 (Distribute) T4 (Apply)

Figure 3.19: Extract of latency measurements in condition R1 = 20 Hz. End-to-end latency (from acquisition to application) is composed of delays within the various stages of the processing pipeline.

0 20 40 60 80 100 120 140 160 180 R1=5Hz R1=10Hz R1=20Hz R1=50Hz Latency (ms) Rate T1 (Acquire) T2 (Simulation Sending Site) T3 (Distribute) T4 (Simulation Receiving Site) T5 (Total)

Figure 3.20: Mean latency caused by stages of the processing pipeline.

the total latency than computation of gaze and distributing it over the Internet.

Figure3.20shows the mean latency occurring throughout the processing pipeline. Computation during simulation on the sending site appears to increase slightly with higher acquisition rates, and thus, with higher data load. In contrast, average latency for transmitting data over a network, both in the local network during acquisition, and across the Internet when distributing to remote sites, reduces slightly with increasing acquisition rate. This stage appears to have the greatest effect on the resulting total end-to-end latency, which ranged between 136–150 ms.