Trials
A trial is a key type of logic node in VRmaze, just like the protocol or experiment. There cannot be an assignment without a trial. A trial necessarily belongs to an experiment.
Trials in a trial list will normally run one after the other, except in the case of a decision process. However, it is possible to mix the order of the trials before launching the experimentation. Indeed, the trial list TrialList contains an option to shuffle the list at run time.
Shuffle trials
During a shuffled run, the original order is saved in the protocol, which can allow the trials to be re-sorted into the original order after running in the result modification mode.
A trial has a set of components, some of which are common to all trial types. Thus, a trial will always have an instruction list, a rendering camera system and success conditions. These three elements allow the participant to be informed before and after the trial, at a minimum, to specify a starting position and orientation, and to allow the current trial to be stopped according to given conditions.
Child nodes in a trial
Like experiments, some types of trials allow the integration of different nodes (e.g. 3D objects). The lifetime of these objects is normally equivalent to the lifetime of the trial itself (this is not the case for instructions or specific entities with a controlled lifetime). Any entity present in the structure of the trial will be available only during the trial, neither before nor after.
Child nodes
The trial offers fine-grained configurability by allowing the addition of entities specific to the trial. The trial container must contain the structural elements specific to the trial. In a trial, it is not possible to remove a node from the parent trial to make it conform.
Data recording
One of the features of the trial is the ability to record data. The trial is indeed the only space available in the VRmaze structure for storing data, regardless of its source, whether virtual or real.
The DataRecords entities are the storage containers of VRmaze. They allow the recording of any type of data.
Data Record
Data records in VRmaze are automatic. There is no way to add a DataRecord entity, it will be dynamically created during the pass. Not all entities record their data. Only some have a recording system.
Cameras
The cameras, visible under the names Subject in the structure of the trial, allow to configure some parameters concerning the rendering.
These are the nodes that allow to define all the properties of the Subject at the beginning of the trial:
- Starting position and orientation
- Speed of movement and orientation
- Use of gravity and collisions
- Display of the sky
- ...
This node offers the possibility to add post-rendering effects that allow you to add an aesthetic effect to the rendered image. Here is the list of available effects:
| Effect | Render |
|---|---|
| Anti-Aliasing render effect | Anti-aliasing effect |
| Avoid Render Effect | Disable all rendering effects |
| Background Color | Replace the background color when rendering |
| Field of View | Set the field of view of the camera |
| Orthographic Render | Orthographic rendering (no depth) |
| HDR Rendering | Enable HDR rendering |
| MSAA Rendering | Enables Multisample Anti Aliasing |
Adding a rendering effect
Rendering effects are custom attributes on the Subject entity of the trial. They are only available on the Subject entity in the custom attributes tab.
Camera data recording
Cameras are entities that record data from the subject's position and orientation throughout the test. Regardless of the type of test, the rendering camera node will always contain a recording system. Results analysis will regularly pass through this node.
Subject position in 2D space ?
In the case of 2D experiments, the Subject node will record mouse data (movements and clicks).
Event handler and pointing nodes
The cameras have an event handler. This event controller allows you to develop your own behaviors thanks to the VRmaze SDK. These controllers work in conjunction with the pointing nodes of the protocol tree to trigger hover or click events on an object
Default Controller
By default, each camera has a default controller that can be changed by another controller. There can be only one controller per camera.
Multiple pointing systems
It is possible to use more than one pointing node for a controller. One can imagine using both VR controllers to point at two objects at the same time.
Success conditions
The success conditions describe how to end a trial. These conditions can be cumulative or not. Thus, it is possible to have several cumulative conditions to complete a trial or only one condition in a complete list.
Success conditions can be totally different and depend on the type of trial (In a Morris pool trial, conditions are based on targets found or not), they can be generic and time-based, or interactive, requiring human interaction such as keystroke input on a keyboard, or pressing a button on a 2D display.
Cumulative Conditions
Cumulative conditions are managed by the condition list: it has a parameter to specify the cumulative effect. By default, it is not activated, and a validated condition in the list is enough to close the trial.
Maximum protocol time
Regardless of the success conditions, if the maximum protocol time is reached, everything ends.
Decision process
The decision process allows a non-sequential execution of the trials of an experiment. In this execution system, each trial has a list of conditioned switches to execute a specific trial selected according to predetermined conditions.
Executing a decision process transforms the linear tree of trials into a graph and makes the success conditions inaccessible.
Accessibility of decision processes
Decision processes are accessible only for specific experiments. These experiments are found in the category of Decisionnal process. This documentation is related to the testing of a decisional process, as the switch settings are an integral part of the testing.
Principle of the decisional process
The success conditions of a decisional process are replaced by switch conditions. For each success condition, the next trial must be specified, which makes the creation procedure more complex. It is possible to have as many referral conditions as needed, each of which refers to a trial in the experiment list.
Trial identifier
Trials linked to conditions are referenced via their identifiers. It is imperative that the trials have different identifiers.
Condition for stopping the experimentation
It is possible to create a condition that, if validated, exits the current experimentation.
Switch to a trial of another experimentation?
It is not possible to refer to a trial in another experimentation.
Composition of conditions
It is possible to create a complex structure of conditions using Boolean operations. Therefore, it is possible to create a switch that uses multiple conditions to validate.