Virtual Reality (VR) locomotion methods are mainly ground-based, room-scale, or discrete, making them ill-suited for flying experiences. Although leaning- and controller-based techniques are promising for flying in VR, we lack empirical evidence of their advantages. We compared combinations of leaning- and controller-based methods for steering and velocity in a user study (N = 24) using a broom metaphor to integrate these methods into an understandable locomotion reference. The steering methods were: 1) controller-pointing (CP) and 2) headset-leaning (HL); and for velocity control: 1) controller linear displacement (CLD) and 2) headset linear displacement (HLD). Results indicate that HL increase presence compared to CP. However, combining HL with CLD worsens coin collection rate, completion time, mental load, control factor ratings, and enjoyment. In contrast, HLD worked well when paired with either steering method. CP-CLD led to the highest coin collection rate and lowest mental load. All methods had comparable feelings of flying.

Rowing has great potential in Virtual Reality (VR) exergames as it requires physical effort and uses physical motion to map the locomotion in a virtual space. However, rowing in VR is currently restricted to locomotion along one axis, leaving 2D and 3D locomotion out of the scope. To facilitate rowing-based locomotion, we implemented three steering techniques based on head, hands, and feet movements for 2D and 3D VR environments. To investigate these methods, we conducted a controlled experiment (N = 24) to assess the user performance, experience and VR sickness. We found that head steering leads to fast and precise steering in 2D and 3D, and hand steering is the most realistic. Feet steering had the largest performance difference between 2D and 3D but comparable precision to hands in 2D. Lastly, head steering is the least mentally demanding, and all methods had comparable VR sickness.

As programming is typically a static activity in front of a screen, we perform an initial exploration around the capabilities of block-based programming in the immersive space using Virtual Reality (VR) to make an early charting on how programming could involve moving the programmer’s body. We created a block-based programming interface in a VR space called BlocklyVR based on the existing Blockly programming environment. To investigate programmer performance and experience in BlocklyVR, we conducted a controlled lab experiment (N = 20) with eight programming tasks that covered mathematical operations, if-statements, and function creation. Our initial exploration contributes by classifying movement types made by BlocklyVR programmers and reflecting on how these movements are related to the programming tasks. Additionally, our data suggests that participant performance in BlocklyVR was not affected compared to the 2D Blockly, even if participants were physically moving in VR space. We also found that the virtual reality sickness was marginal. Lastly, we identified four types of interaction that can potentially be employed by VR designers and developers aiming to convert a static task, like programming at a desk, into a “mobile” immersive experience.

Walk-in-Place is an established locomotion technique for walking in virtual environments, as it incorporates body motion similar to regular walking. Although there is extensive research on the performance and experience of walking in virtual reality spaces, it typically requires minimal-to-moderate physical movement, e.g., stepping forward and turning around, to explore virtual spaces. Therefore, the question we ask ourselves in this work is how user experience and performance are affected when the user is actively moving in place. In this paper, we explored three body-steering methods for jogging-in-place in virtual environments: (1) head-, (2) hand-, and (3) torso-based. To investigate the performance of the proposed body-steering methods for jogging in virtual reality, we conducted a controlled lab experiment (N = 12) to assess task completion time, number of steps, and VR sickness. We discovered that hand- and torso-based methods require fewer steps than the head-based method, and the torso-based is slower than the other two. Moreover, the number of collisions and virtual reality sickness were comparable among the methods.

Automated detection of cancer metastases in lymph nodes has the potential to improve the assessment of prognosis for patients. To enable fair comparison between the algorithms for this purpose, we set up the CAMELYON17 challenge in conjunction with the IEEE International Symposium on Biomedical Imaging 2017 Conference in Melbourne. Over 300 participants registered on the challenge website, of which 23 teams submitted a total of 37 algorithms before the initial deadline. Participants were provided with 899 whole-slide images (WSIs) for developing their algorithms. The developed algorithms were evaluated based on the test set encompassing 100 patients and 500 WSIs. The evaluation metric used was a quadratic weighted Cohen's kappa. We discuss the algorithmic details of the 10 best pre-conference and two post-conference submissions. All these participants used convolutional neural networks in combination with pre- and postprocessing steps. Algorithms differed mostly in neural network architecture, training strategy, and pre- and postprocessing methodology. Overall, the kappa metric ranged from 0.89 to -0.13 across all submissions. The best results were obtained with pre-trained architectures such as ResNet. Confusion matrix analysis revealed that all participants struggled with reliably identifying isolated tumor cells, the smallest type of metastasis, with detection rates below 40%. Qualitative inspection of the results of the top participants showed categories of false positives, such as nerves or contamination, which could be targeted for further optimization. Last, we show that simple combinations of the top algorithms result in higher kappa metric values than any algorithm individually, with 0.93 for the best combination.