Desarrollo tareas cuarta iteración Tarea número uno

Tal como se muestra en la figura 34, se genera la estructura para la vinculación de modelos 3D con base en la estructura general para archivos RDF, agregando los campos necesarios para agregar las licencias de los modelos 3D o de las texturas usadas, el link de descarga del modelo, la escala y el posicionamiento en el escenario.

Los campos que se usarán para representar cada modelo 3D serán:

• Título: El título del modelo 3D

• Comentarios: se agregan una descripción breve del modelo

• Licencia: se agrega el link de la licencia ya sea del modelo 3D o de la textura que se usó para crearlo.

• Posición: lugar de la escena donde estará localizado el objeto, para esto se usará escribirán las coordenadas X, Y, Z separadas por comas.

• Escala: el tamaño porcentual que tendrá cada modelo dentro de la escena.

• Rotación: la rotación necesaria para que el modelo pueda ser visualizado de forma correcta.

83

Figura 34. Estructura RDF para la vinculación de modelos 3D al escenario. Fuente: propia.

Tarea número dos:

Para el desarrollo de esta tarea se crearon algunos modelos 3D usando la herramienta online “Smoothie-3D” poniendo como texturas las imágenes que se fueron encontrando en Wikipedia. Otros modelos se descargaron de sitios libres cuya licencia será presentada en el archivo RDF de vinculación. Los ejemplos de algunos de estos modelos se presentan en las figuras 35 y 36.

84

Figura 35. Modelo 3D para el término “Egyptian_faience” de la ontología creado usando smothie-3D usando como texturas las imágenes de Wikipedia. Fuente: modelo 3D propio, texturas tomadas de [33, 34, 35].

Figura 36. Modelo 3D para el término “Venus_of_Willendorf” de la ontología, descargado de sitio web gratuito, licencia creative commons ShareALike. Fuente: Imagen propia, modelo 3D tomado de [36].

85

En total se han creado y descargado un total de 85 modelos 3D, uno por cada término de la ontología, a continuación, se procede a describir cada uno de estos recursos mediante un archivo RDF siguiendo la estructura definida en la tarea anterior (figura 34).

Una vez se ha realizaron la representación de los modelos 3D mediante tripletas, se procede a su vinculación con el archivo principal de la ontología permitiendo de esta manera que al navegar por determinado término se pueda obtener su respectiva representación basada en la metadata definida en el archivo RDF. El archivo RDF que se ha generado para los objetos 3D cuenta con un total de 915 líneas donde se incluye en cada tripleta la respectiva licencia de uso, ya sea del modelo 3D como tal o de las texturas que se usaron para generarlo; en su mayoría las texturas son tomadas de las imágenes encontradas en Wikipedia.

Tareas número tres, cuatro, cinco y seis

En este caso se realizan el desarrollo de estas cuatro tareas en paralelo ya que se requería hacer uso del motor de desarrollo, el servidor de archivos y el archivo RDF para la creación y vinculación de modelos 3D.

Para la configuración del servidor, se optó por usar un servidor tipo HTTP que permitiera múltiples peticiones. Se utiliza el servidor gratuito llamado “HFS” que se puede instalar de manera local y recibe peticiones por el puerto 8080 del localhost.

Para lograr la descarga de los modelos 3D en tiempo de ejecución se utilizó un objeto propio de unity3D llamado “asset bundles” que permite empaquetar una serie de objetos, escenas, sonidos y todo material usado para construir los videojuegos en un solo contenedor que se consume por demanda. Entonces, se toman todos los modelos desarrollados anteriormente y se ponen en un mismo paquete, este paquete se sube al servidor HTTP que se instaló y seguido a esto se construye el script necesario para obtener el recurso cuando se lanza el evento de seleccionar un término específico del menú de navegación.

Es en este punto donde usar RDF para vincular los recursos cobra sentido ya que, al consultar un término en la ontología, este ya tiene relacionado el modelo 3D en forma de tripleta apuntando al RDF creado que contiene la información de este dentro de la escena como lo es la posición, la rotación y la escala. Como se aprecia en las figuras 37 y 38, el objeto 3D es descargado a la escena con dichos datos y es visible para los usuarios junto con la información descargada de DBPedia.

86

Figura 37. Visualización modelo 3D y descripción para el término “Lion-Man”, perteneciente a la categoría edad de piedra-paleolítico.

Fuente: propia.

Figura 38. Visualización 3D y descripción para el término “Carruaje”, perteneciente a la categoría de edad de los metales-edad de hierro.

Fuente: propia.

Realizada esta actividad se procede a crear o descargar los escenarios y elementos que allí se incluyen, de repositorios abiertos. Esto se hace para cada una de las seis edades de la ontología que aquí se usa de demostración que es ATT-ontology. Tal como se muestra en la figura 39, el primer recuadro corresponde al neolítico, el segundo al mesolítico, el tercero al neolítico, el cuarto a la edad de cobre, el quinto a la edad de bronce y el último a la edad de hierro.

87

Figura 39. Escenarios para las edades definidas en la ontología de ATT. Fuente: propia.

Por último, se realiza la transmisión hacia el celular utilizando una librería llamada Trinus VR que funciona a través de la red wifi o cable USB. Para su funcionamiento se necesita instalar la aplicación móvil y la aplicación en el computador. Como se muestra en la figura 40, los modelos 3D se descargan del servidor HTTP y la información es consultada de DBPedia, luego con la información del RDF de los modelos 3D, se instancian en la escena. Luego de esto basta con abrirla, seleccionar el visor deseado (en este caso Google cardboard) y abrimos nuestra aplicación en el computador; automáticamente se iniciará la transmisión.

88

Figura 40. Interacción y transmisión de la aplicación hacia el visor de realidad virtual. Fuente: propia.

Como se aprecia en la figura 41, la imagen de la aplicación se transmite hacia el celular y una vez allí ya se puede hacer uso de los distintos visores que existen. En este caso, el computador es el que realiza todo el procesamiento gráfico de la aplicación, el celular simplemente se encarga de capturar la imagen como video y mostrarla al usuario.

En una posible futura versión de Leapmotion para Android se incorporará la posibilidad de no tener que conectar este dispositivo al computador, sino que, se conectará directamente al celular y este realizará todo el procesamiento gráfico. Hay que tener en cuenta que esto implicará tener el futuro smartphones con mayor capacidad de procesamiento.

Por otro lado, se ve que el rendimiento de la aplicación decae (existe mucha latencia) en ciertos momentos cuando se navega que ambas manos, esto se debe principalmente al rendimiento del computador donde se está probando ya que no cuenta con una tarjeta gráfica lo suficientemente potente para renderizar las texturas.

Finalizada esta tarea, la aplicación ya está lista para ser probada y encontrar posibles fallos en la interacción y rendimiento.

89

Figura 41. Transmisión de video en realidad virtual hacia el smartphone con un visor del tipo Google cardboard. Fuente: propia.