## 4 PRISMIN Framework Overview
### Encoding Node  
The PRISMIN framework and its application programming interface (API) offer all the basic functionalities to create and deploy the described _encoding node_ of the architecture. We highlight here the main classes and methods available to encode students interactions:  
* **Atlas**: this represents the 2D image that is physically generated on disk and exchanged among peers (learners and teachers/analysts). Each atlas may have a specific layout (how data is accessed) and quantization mechanics (how state attribute is encoded into a color). QSA and saliency tables are examples of image atlas--see Sections 3.2 and 3.3.
* **Prism**: an interaction prism object allows the ability to define how incoming user states are projected into atlases. It must implement a _refract_ method (how state attributes are mapped onto the atlas image or images) and a _bake_ method (write the actual image or images on disk).
* **Volume**: this represents a classic AABB structure (see Section 3.1) that operates in a well-defined portion of the scene. Several prisms can be attached to a single volume, providing maximum flexibility on which attributes a teacher is willing to track and how. Notice that each volume operates independently, thus they can be overlapped or nested within the virtual space of the IVE without any issues.  
The role of a single prism object is basically to \"_refract_\" interaction states into image atlases (like QSA and saliency tables) and may live at runtime attached to a volume, in order to encode spatial attributes (location, focus, etc.) inside specific boundaries of the 3D scene. A prism can although be employed without a reference volume: a few examples are the encoding of HMD orientation, view direction vector or neck strain. Figure 6 shows a few examples of QSAs involving four different students (atlas rows): the encoding of spatial features such as focus and location within the virtual space requires indeed a volume (see Section 3.1) since each color maps a specific 3D location. Other attributes like HMD view direction and neck comfort levels (see [27]) do not require a _voxelization_ of 3D location, thus the interaction prism can operate unbounded (i.e., everywhere in the scene, always running). Indeed, quantization errors still occur, but they highly depend on how the quantizer was defined--these errors will not be discussed in this paper. In the encoding node of the architecture, received user states are thus \"refract\" into different QSAs (see Section 3.2) and saliency tables (see Section 3.3) as compact images. From a computational perspective, for each volume \((V_{1},V_{2},...V_{k})\) such operations present an overall complexity of \(O(k\cdot h)\), where \(k\) represents the number of session volumes deployed and \(h\) the number of different attributes to track \((a_{1},a_{2},...a_{h})\). Generally \(h\) is quite small, since the analyst/teacher is interested into the investigation of selected state attributes (e.g., location, focus, ergonomics, etc.). The number of volumes (\(k\)) on the other hand, depends on  
Figure 5: Architecture components overview.  
spatial requirements and complexity of 3D scene (a single volume can sometimes be sufficient to detect interaction patterns in a specific portion of the virtual environment).