Avance modificación RADIx para funcionar con ejecutable O3DE y problema encontrado VR implementación O3DE

Avance modificación RADIx para funcionar con ejecutable O3DE

Esta semana, he trabajado mayoritariamente modificando el RADIx para que funcione con el ejecutable.

Para crear el RADIx he tenido que modificar las ramas para O3DE de Jderobot: RA (Robotics Academy), RI (Robotics Infrastructure) y RAM (Robotics Application Manager).

En RA, he modificado los dos dockerfiles para generar el RADI:

• Dockerfile.dependencies_humble: En este dockerfile se descargan todas las dependencias necesarias para el RADIx. Para nuestro caso, he creado un repo nuevo en Jderobot con el ejecutable (usando git lfs para poder manejar los archivos más grande del ejecutable) con el objetivo de poder instalarlo en el RADIx como una dependencia más y no tener que meter el ejecutable en ningún otro repositorio de los ya mencionados.

• Dockerfile.humble: En este dockerfile se prepara ya el entorno de RA, donde se añade al RADIx tanto los ejercicios y assets necesarios que tiene RI como los procesos de los que se hacen uso que se encuentran en RAM. En este dockerfile, he añadido que tenga en cuenta la carpeta con los .pak de los levels, que serán los archivos que al ejecutar se iniciará el level con sus assets.

En RI, he añadido una carpeta que almacena los .pak de los levels. La semana pasada me preguntaba comó poder manejar la carga de levels, pero me di cuenta que con tener en el .pak almacenado el level ya es suficiente, es decir, el .pak no solo guarda los assets del level, también guarda toda la información del mismo. De esta manera se hacía mucho más sencillo el RADIx, teniendo solo que crear una carpeta para guardar los .pak. También, como se iba acceder de otra manera a los levels a la hora de ejecutarlos, modifique el sql de la base de datos con los ejercicios de O3DE

En RAM, por último, he modificado el programa launcher_o3de_api.py, este programa se encargaba de ejecutar lo necesario a la hora de iniciar un ejercicio con O3DE en Robotics Academy. Lo que he tenido que modificar ha sido la manera en la que se inicia el level. Antes se hacía mediante un .cfg que se configuraba con el level que querías y lanzabas el GameLauncher, el problema es que el ejecutable no tiene estos .cfg pero no hace falta ya que se puede lanzar el GameLauncher con el argumento +LoadLevel y el nombre del level que tengamos contenido en el .pak.

Habiendo hecho estos cambios, he generado el RADIx, pero he tenido problemas al final, debido a que estaba trabajando con un dockerfile.humble más antiguo que el actual y con el RAM más actual, así que tendré que arreglar estos problemas y volver a crear el RADIx.

Problema encontrado VR implementación O3DE

He estado indagando un poco más de nuevo en la implementación de las gafas VR con O3DE.

He estado viendo más a profundidad los videos de O3DE y OpenXR, aunque en estos videos usan windows y meta link, explican como funciona el sistema de renderizado de O3DE en las Meta Quest. Para realizar este renderizado, se usa un pipeline de renderizado distinto al principal que tiene O3DE, MultiView.

Me he dado cuenta a partir de esto, que el problema es la renderización que hace este pipeline de renderizado, por lo tanto el problema de las gafas con O3DE que he tenido tanto tiempo está relacionado con Atom.

Durante esta semana revisaré código que pueda fallar relacionado a la gem Atom y como maneja todo lo relacionado a las gems OpenXRVk y XR