## 4 Performance Analysis of the Generated Models in Virtual Environments
### Data Collection Method  
Following the construction and deployment of each scene, usage metrics were collected using the native profiling tool OVR Metrics Tool 1.6.5 ([[https://developer.oculus.com/documentation/native/android/ts-ovrstats/](https://developer.oculus.com/documentation/native/android/ts-ovrstats/)]([https://developer.oculus.com/documentation/native/android/ts-ovrstats/](https://developer.oculus.com/documentation/native/android/ts-ovrstats/)) accessed on 7 July 2024). As the primary objective of analysing the performance offered by the models is their integration into a VR shopping environment, we made the following decisions when developing the scenes:  
* Employ the official Meta SDK for Unity to incorporate into each model the necessary components to interact with the models. Thus, these can be picked up with virtual hands and moved freely to observe how a typical interaction with objects affects performance.
* Replicate the number of models in different scenes to estimate the limit of products that could be included in a virtual environment for each type of model generated by Luma AI. This allows estimating a maximum number of objects that can be displayed for the application to run smoothly and for the user experience to be satisfactory. This was performed with the low-poly models of Luma AI and Polycam for Android as they have been the most realistic models and the ones that have provided the best data, as seen in Section 3.3. In total, 14 scenes were developed to achieve this objective.
* For the collection of performance data, the corresponding application for each scene was run, and during an application execution lasting approximately 60 s, there was interaction with the objects in the environment, as well as free movement around the scene. This was done with the aim of simulating a user's behaviour in a VR shopping environment.  
OVR Metrics exports data from each application execution to a.csv file, recording the value of up to 88 metrics every second regarding the CPU, GPU, memory, temperature, etc. We have selected for analysis the metrics we are interested in with respect to performance, as metrics such as voltage, wattage, or colour intensity in each eye of the headset are also collected but are not of particular interest to us.  
In the next section, we provide a performance analysis of the models from the execution of the scenes developed. The main constraint to further replicating objects of one type was the smoothness of the application, which is a key factor in the user experience. With the recommended rate of frames per second being between 60 and 72 for the Meta Quest devices used, a rate below half that (in this case around 30 frames per second) starts to severely affect the user experience, causing lag that, in the case of VR, can cause motion sickness. We started with 4 objects to represent a minimum number of objects that could appear simultaneously in a real shopping environment, one of each type that was scanned. The replications, as shown below, allowed us to reach a maximum of 96 low-poly, 24 medium-poly and 12 high-poly objects, figures at which the user experience was affected quite negatively.  
Figure 8: Two of the scenes developed for analysing the performance of models. (**a**) Simple scene (1 object of each model) of low-poly Luma AI models; (**b**) 12x scene (12 objects of each model) of low-poly Luma AI models.