## 3 Methodology
### Augmented Reality  
The AR functionality entails the registration, i.e., the spatial alignment of the real and virtual objects. For marker-less AR based on pattern detection, the 3D model is expected to be placed in the center of the pattern, with the \(Z\) axis in the direction of the camera. The coordinates of the vertices of the 3D model in its local coordinate system are transformed to the world coordinate system by being normalized in the range \([-1,1]\). They may also be multiplied with a user-defined scale factor, in order to give the 3D model the intended size relatively to the pattern object. The data needed to achieve the registration and the visualization of the 3D overlay are: (i) the parameters of the camera exterior orientation estimation, (ii) the camera calibration matrix, (iii) the pattern image as well as (iv) the draw and load functions of the 3D engine. In our implementation, the camera pose parameters constitute a shared resource that should be accessed by the compute and rendering module. For the synchronization of access and the execution of the various calls, semaphores are exploited. They are memory variables in the form of integers, indispensable for multi-tasking programming. The 3D model's pose tracking must wait until the semaphore's value is positive, then changes the semaphore's value by subtracting one from it. When it is finished, the thread performs feature extraction and pattern detection, which change the semaphore's value by adding one to it. However, whenever any process waits, it continues checking for the semaphore value and waste CPU cycle. To prevent busy waiting, a system _call block_ is exploited and a queue is created to contain the functions that got blocked while performing down operation. The process which is currently being executed is added to the queue, and when completed, it calls the signal function and the previous process in the queue is resumed. Thus, synchronization prevents extra memory loads and multiple waisted memory cycles. The elements of the estimated joint rotation-translation matrix \([R\,|\,t]\) of the camera pose object are converted to float values and define the current model matrix \(M_{MODEL}\). Then, the known intrinsic camera matrix \(M_{CAM}\) is translated from a perspective projection into an OpenGL projection matrix \(M_{Pryj}\). The view frustrum specifies the perspective projection \(M_{Pryj}\) that is then converted into normalized device coordinates \(NDC\) in the range \([-1,1]\) in 3 axes, according to Equation (7), which describes their inverse correlation.  
\[M_{Proj}=NDC\times M_{Pryp}. \tag{7}\]  
The clipping points between the \"near\" and \"far\" planes of the view frustrum cut it perpendicularly to the viewing direction. The distance between them affects the precision of depth-buffering. If the \"near\" value is reduced, the pixel of vertices near the \"far\" plane might be wrongly rendered. Instead of \"near\" and \"far\" values, the depth limits are defined with the field of view (FOV) and the aspect ratio. The AR scene rendering further involves construction of the vertex and fragment shaders, parsing of the 3D OBJ file, its material properties and its sub-texture image as well as the lighting and camera settings.