For standard use in teaching and research, please see the ReadMe file. This page covers the setup necessary to make changes to the project and use it for your own work (e.g. theses).
Installations
At first you need some programs to run the VR-classroom in developer mode. These programs are listed below and sample sources are linked to them.
- git is a version control program that allows you to download the current version of the project and do versioning of your changes.
- gitExtensions is a GUI for git. There are various GUIs for git, however some of them have known issues with unity, so use of gitExtensions is advised.
- git lfs is an extension for git that takes care of files that are not readable by humans because they are too large or binary.
- unityHub provides an overview of your Unity projects, manages different Unity versions and offers many tutorials and helpful add-ons.
- unity is a GameEngine and the development environment of the VR-classroom's VR environment. To find out the version you need, use unityHub, add the project there and download the suggested unity version to open the project. WARNING using wrong unity version may cause unexpected errors and cooperation with other developers is almost impossible.
Optional
- SRanipal Unity SDK Eye and Facial Tracking SDK (aktuell nutzen wir nur eyetracking)
- viveport may solve inexplicable errors...
- Blender useful tool for creating models, 3D-objects and changing the environment
- For class discussions:
- yEd Graph Editor: creating structure trees
- Audio recording software: according to your own preference
- Optional: Image creation software, e.g. Gimp, etc.
There are currently two versions of the front end; follow the setup steps corresponding to the one you want:
Old site -->
- nodeJS is a JavaScript-based development environment for web applications. NodeJS is responsible for the frontend in this project
- redux Toolkit îs a package for nodeJS and supplies the frontent with necessary functions.
- electron provides the frontend with a browser-independent interface, thus presenting the frontend as fully-fledged app.
New site -->
Training
Now that there is a whole load of new software on your system, you are faced with a project that grown and developed over time with various developers. This may be overwhelming at first and you might wish you had a little more clarity. These are the issues this chapter is intended to address.
Get an overview
Depending on the area you want to develop in, you will of course need to get to know the development environment. There are various sources for this on YouTube, Stackoverflow, etc. Of course, no concrete tips on this project will be given there, but it is useful to know how the development environment is structured. In the following, the structure of the VR environment is discussed and short familiarization exercises are highlighted.
As of this writing (06/01/2021), there are two versions of the VR-classroom. One version is specialized for the use with Vive glasses (master branch) and the other one is specialized for Oculus glasses (oculusVersion branch). So depending on your hardware, you should check out the correct version in git (extensions). Once the project is open, you will see a folder hierarchy. All assets (folders) under "AssetStore" are designed by third party developers and have not been significantly modified. The folders starting with "own" like "ownScripts", "ownPrefabs", etc. contain own developments. The folder "Scenes" contains different seating arrangements for the virtual class and tutorial or menu environments. For own testing to get used to the project, the "Scenes" folder is recommended, although "test environments" should be removed before the first git push. To build up an orientation, try for example to find the self-written script that manages an audio ambience for the scenes.
Double-click on a script to open your IDE for C#, which in the default case is Visual Studio. Familiarize yourself with the programming language and look at existing scripts and our standards. Unity brings various features and classes to the world of C#. For example, the interface "MonoBehaviour" is a keyword that enables a script to be attached to a GameObject, while the interface "Editor" provides functions to add buttons and the like in the unityEditor. Examine the script "AmbientSound.cs" for an Editor class and for a MonoBehaviour class. Then use functions of your IDE to examine the static class "MenuDataHolder". What do you think this class is for?
Back to the editor, you will see the Scene-View, where all 3D objects in the world are displayed. Open the "FrontalScene" scene from the "Scene" folder and look at the GameObject hierarchy. Classroom scenes are all sorted similarly: Teacher, Controls, Sun, ... are GameObjects, i.e. objects to which unity assigns a behavior, location and orientation. In the GameObject "classroom-scaler" are the things that the user can see, including the virtual students or table / chairs. To find your way around here, it is recommended to invest a little time in exploration and find, for example, the GameObject of the window wall. To find GameObjects that carry a particular script as a component, you can use the search function of the hierarchy, e.g. with ref:Assets/ownScripts/Atmosphere/AmbientSound.cs .
Unity offers a great number of options, windows and packages, and a not insignificant subset of them is also used in the project. If you have spent a few hours with the project, as suggested here, you will surely find the right place to include your developments. Should you have specific questions about your development, you've already come a long way and internet resources will certainly help you. If you simply feel lost and overwhelmed in the project, despite this introduction, feel free to contact Axel Wiepke. He is especially looking forward to suggestions for improvement of this tutorial to enable future developers a stress-free start.
Paketstruktur in Teach-R
The functionality of Teach-R is organised according to role and purpose into Unity Packages, which are themselves categorically organised. 
Theoretical foundations
Since this project is primarily a research project, development decisions should be based on scientific sources to the best of our ability. Circumstances already researched with this project can be found here. A knowledge collection of used sources of developments is not linked here for clarity. However, elaborated publications will be shared on the linked page and student works, in the future will also be provided on request.
Documentation for developers
To visualize dependencies of classes and other helpfull tools, we created a documentation with doxygen.
Taking credit for your work
After a substantial contribution has been made to the code, your name can be included as the developer of the software. So as soon as the software is referenced, your name will also be mentioned. To be cited in this way, please modify the "citations.cff" by adding your data to it, in accordance with the present style.