Overview

Ease-of-Use vs. Flexability

Many labs require different design setups, and it's a tall order to cater to all situations.

• For power users, experienced Unity developers, or researchers with subjective test design, a range of flexible features would provide a more comprehensive tool.
• For novice users, a rich and flexible feature set requires a steep learning curve, somewhat defeating the purpose of providing a tool to streamline virtual reality reality tests.

QExE Architecture

To overcome this issue, the QExE tool takes a modular design approach. Using a set a defined interfaces for methods, questionnaires, and OSC communication, different modules can be programmed and imported by experts users to work within the tool, while leaving the base QExE feature set clutter-free for normal users wishing to explore the current implementation.

Pick and choose: Test control, VR platform, or both?

Using a Controller-Agent-based setup, we can separate out "test control" aspects from "virtual platform" aspects.

For example, if you have a VR system that already has UI's and interaction mechanics but require a means to automate and collect data, you can use the Controller. Likewise, the reverse if true if your lab uses Matlab or Python to automate tests but require a VR system with user interfaces for subjects, you can just take the Unity Agent. In these examples, the only additional programming required is to implement the expected communication messages between programs.

Here's quick glance at the overall architecture of the QExE tool. Check out the MaxMSP Controller and Unity Agent pages for a more detailed breakdown of what's happening inside.

Why MaxMSP and Unity?

There several tools that could have been used to develop either the Controller or Agent. Front runners for the QExE Host could have been JUCE, for example. For the Client, Unreal Engine would have been an option. In the end, it all comes back to which program best fits your use-case.

Max/MSP

MaxMSP is a graphical programming tool. It's basic principle of having graphical objects that represent a class means that those will minimal coding experience can jump in to create something with little trouble. This graphical programming is done in something called a "patch". A patch can be as big or small as you like, contain graphic components for designing quick user interfaces, and contain javascript code. While this does have drawbacks for those with a deeper coding background, those who have little coding experience that wish to adapt the QExE tool have a much higher chance of success, than if they were to open up some source code to a C++ project.

Some things, are easier coded than drawn...

If we want to get more organized, we can create a Javascript object in MaxMSP and script out some functions. Going deeper into some DSP we can also open up a GEN object. Read more about that here.

Most of the QExE Host is programmed done using a combination of patchers with corresponding javascript code objects.

Unity

Unity is a 3D gaming engine that has risen to popularity within research communities due to it's accessibility. The program has a shallow learning curve, is capable of doing many of the tasks that are throw it's way, has good online documentation, and allows users to get into lower level C# coding quite easily with it's scripting API built around a base class - MonoBehavior.

More recently, Unity has invested resources into providing tools for virtual reality development, making it a good candiate for the QExE tool.