FlyoVeR: 2D virtual reality for head-fixed walking flies

This page provides technical details and additional resources for the 2D virtual reality for head-fixed walking flies described in [].

Please note that this website is still under construction. We are working on adding more information shortly.

If you have comments or feedback, please contact haberkern[at]janelia.hhmi.org.

Technical details about FlyoVeR

The FlyoVeR application is a modified version of the Jovian/MouseoVeR software [1], hence the name. Like MouseoVeR, FlyoVeR was built from several powerful third-party, free and open source software components. The 3D graphics, in-memory scene model, and callback-oriented rendering loop in FlyoVeR were implemented in the C++ programming language using the cross-platform open source OpenSceneGraph library (version 3.4). The graphical user interface was also implemented using C++ based on the cross-platform open source Qt toolkit (version 4.8). The cross-platform build and packaging system was implemented with CMake (version 3.4).

FlyoVeR differs from the parent Jovian/MouseoVeR software in the following respects:

• It incorporates a palette of location-dependent behavioral reinforcement capabilities. This allows the FlyoVeR application itself to determine the final reinforcement parameters, thus simplifying the responsibilities of the software running on the programmable microcontroller reinforcement apparatus.
• In FlyoVeR, the treadmill motion is directly represented as translational (horizontal) and rotational (heading) motion of the animal in the virtual world (with one exception: the animal motion is not permitted to penetrate vertical obstacles in the virtual scene). By contrast, in the parent Jovian/MouseoVeR software system, the treadmill motion is incorporated into a full physical mechanistic dynamic simulation. The simpler motion system used in FlyoVeR was easier to debug and sufficient for our needs.
• It includes an option to display a radially symmetric visual fog effect, as opposed to an axis-aligned fog effect. With axis-aligned fog, equidistant objects can be hidden or visible through the fog depending on their position within the FOV.
• It is distributed as a self-installing executable program.
• FlyoVeR uses a human-readable xml configuration file format, enabling easier recording of experimental details, and also enabling off-line adjustment of experimental parameters.
• It records various experimental details in the log file header, to help keep track of the parameters were used for a particular experiment.

References:

[1]  Cohen, J.D., Bolstad, M., and Lee, A.K. (2017). Experience-dependent shaping of hippocampal CA1 intracellular activity in novel and familiar environments. eLife

Virtual world construction

Naming conventions used in FlyoVeR

Custom Collada (version 2.4) format scene files used in our experiments were created with the free 3D modeling program Blender (version 2.73). The Collada file format is a standardized XML format used to describe 3D graphics. Each object within the 3D scene had a unique name and a set of properties. Properties such as the color and texture were specified in Blender as “materials” that were then assigned to the respective object. Three other properties were communicated to FlyoVeR as part of the object’s name string:

• Visibility: An object could be marked as invisible by placing underscores at the beginning and end of an object name, e.g. “_Cone_”.
• Penetrability: An underscore followed by “p” as in “Cone01_p” marked an object as “physical”, i.e. not penetrable by the fly.
• Concavity: An underscore followed by “c” as in “Cone01_c” marked an object as “concave”. This property was only relevant for objects that were hollow and impenetrable, as it defined whether the fly was excluded from the inside or the outside. For example, to prevent a fly from entering the inside of a small hollow cylinder used as a virtual landmark, the landmark model had to be marked as “convex”. In contrast, to prevent a fly from leaving the inside of a large hollow cylinder that marked the arena wall, the arena model had to be marked as “concave”.
• Scene item names containing the letter "z", proceeded by an underscore, and followed by an optional number (e.g. "item_z2"), represent locations where positive or negative reinforcement might be delivered. The detailed effects of each of these reinforcement zones can be specified in the FlyoVeR graphical user interface.

The flags for visibility, penetrability and concavity could be combined in the name of a single object. By default, objects were “visible”, “penetrable” and “convex”. When loading a new scene file, FlyoVeR parsed the names of each object and assigned corresponding properties to the objects composing the virtual scene. Invisible objects could be used to mark special areas within the scene, such as the starting point of each trial, and control the delivery of other stimuli based on the fly’s position inside the VR. Two items, a small sphere and a plane above it, representing the virtual animal size and viewpoint and the initial animal location, are required in every scene and have to be names "_camera_block_pm_" and "_start_", respectively.

Virtual worlds used in the paper

Under construction

Building FlyoVeR

Under construction

How to run FlyoVeR

Under construction