Rubik VR

VídeoAplicación

Autor

Adrián Termenón Riera

Introducción

Cuando me planteé la tarea de hacer una aplicación de Realidad Virtual me vinieron muchísimas ideas a la cabeza, pero tenía claro que quería desarrolar algo para Oculus. Esta decisión, no solo se debe a que ya cuento con cierta experiencia tanto con el dispositivo como con Unity, sino también a que considero que los visores de realidad virtual, ya sean de escritorio o portátiles, actualmente se encuentran en esa fina línea temporal que separa la tecnología que solamente usan unos pocos de la que se utiliza de manera manera masiva, tal como en su día lo estuvieron los smartphones. En definitiva creo que tiene futuro.

OculusGoogle Cardboard

No obstante, la idea de jugar al cubo de Rubik puede parecer un poco aburrida, si se compara con lo que el usuario medio espera de la Realidad Virtual Inmersiva. Es decir, experiencias trepidantes y llenas de adrenalina. Pero opino que cuantos más contenidos haya disponibles, más rápido se extenderá esta tecnología en la sociedad. Quizás por eso y porque hace bastante años que soy aficionado a los cubos me decidí por llevar este proyecto adelante.

 

Proceso de trabajo

1. Modelar el cubo

La primera etapa del proyecto consistió en el modelado 3D del cubo, para lo cual utilicé el software 3DS MAX 2014. Esto, supuso innumerables ventajas respecto al entorno Java Script en el que desarrollé la primera aplicación debido, principalmente, a las herramientas que ofrece la interfaz de trabajo de MAX.


Autodesk 3DS Max

2. Diseñar la interacción

Una vez modelado y texturizado, el siguiente paso fue diseñar la interacción con el cubo en Unity 5. Lo primero que me planteé al abordar esta tarea es que no quería limitar el giro del cubo tal como hice en la primera aplicación. Después de todo, algo más de un año de experiencia con Unity, me ha permitido familiarizarme con la clase Vector3, la cual ofrece infinidad de métodos enfocados a la transformación de objetos en un espacio euclideo, tal como es el entorno virtual en el cual se desarrolla la acción.


Unity 5Unity Manual

Así pues, en la primera aplicación desarrollada en Java Script, el cubo siempre permanecía orientado en la misma dirección, y era la cámara la que rotaba alrededor suyo cuando el usuario deseaba girarlo. Esto simplificaba bastante el manejo de las distintas caras pero, al mismo tiempo, suponía un problema. Era necesario escribir un código específico prácticamente para cada pieza y cada giro. Es decir, si ahora quisiera hacer una versión del cubo de 4x4x4 o de 5x5x5, tendría que reescribir prácticamente la totalidad del código. Por el contrario, en Unity y gracias a sus herramientas vectoriales he conseguido que sea el cubo el que gira sobre si mismo mientras que la cámara, es decir, el sujeto virtual, permanece estático en la misma posición.

De esta manera, el guión de la interacción para el manejo del cubo es el siguiente:

1 – seleccionar la pieza

El usuario hace clic sobre una pieza, con lo que el programa guarda en la memoria la cara del cubo en cuestión y el vector normal de la misma.

2 – seleccionar el conjunto de piezas

El usuario arrastra el cursor sobre el plano de la cara, con lo que se guarda un nuevo vector que permite al programa saber que conjunto de piezas es el que se desea girar.

3 – girar el conjunto de piezas

Una vez guardados los datos necesarios, el programa calcula el eje y ángulo de giro a partir del producto vectorial de la normal de la cara y la dirección del movimiento del cursor sobre la misma.

4 – finalizar el giro

Por último. cuando el usuario deja de presionar el botón del ratón el programa restaura la rotación de la cara en función del ángulo más próximo.

A parte de la interacción con el cubo está también la interacción con la propia aplicación, cuyo guión es muy sencillo. Simplemente se basa en los posibles estados en los que se encuentra el cubo o el juego. Por un lado, si el cubo está resuelto o no y, por otro lado, si el jugador está tratando de resolverlo o simplemente esta jugando con él sin ninguna finalidad en concreto.

3. Diseñar la interfaz lógica

Llegado a este punto, lo que quería evitar a toda costa respecto a la primera aplicación es que el usuario realizase un giro no deseado por error. Para ello, me propuse delinear en todo momento los elementos susceptibles de ser modificados. De esta manera, el jugador dispone de la información visual necesaria para saber con exactitud que pieza o conjunto de piezas se dispone a girar.

Por otro lado, me pareció buena idea incluir una consola para poder mostrar información sobre el estado de la aplicación, es decir, si el cubo se esta desordenando, si el cronómetro esta activo o si el jugador ha logrado resolver el cubo.

Por último, añadí unos sencillos controles para poder desordenar el cubo o resetearlo, conocer los atajos del teclado, regular la iluminación de la escena o la intensidad de la música o poder cerrar la aplicación sin necesidad de quitarse las Oculus.

4. Adaptar la interfaz física

Por suerte, esta parte del desarrollo no supuso ninguna complicación, en parte debido a que Unity ya tiene las opciones de Realidad Virtual y Visión Estereoscópica que automatizan completamente los procesos de mapeado entre el giro del visor, en este caso las Oculus DK2, y el giro de la cámara en la escena.

Un poco más peliaguda fue la parte de mapear el movimiento 2D del ratón para adaptarlo al entorno tridimensional de la aplicación. Sobre todo en determinadas circunstancias en las que el usuario debía desplazar el cursor virtual a lo largo de un plano bastante perpendicular a su propia visión. Pero finalmente, no me encontré con ningún problema que no pudiese solucionar con trigonometría básica.

5. Diseñar el concepto

Ya desde el principio tenía bastante claro que el entorno debía ser lo más neutro posible. Finalmente y tras hacer varias pruebas me decante por integrar un plano a modo de suelo, que pudiese iluminarse u oscurecerse dependiendo de las preferencias del usuario. También decidí añadir unas partículas muy tenues situadas alrededor de la zona de acción, para aumentar la sensación de profundidad del entorno y favorecer la sensación de presencia del usuario.

Por último, el sonido es un factor muy importante para potenciar esa misma sensación de presencia tan indispensable en una aplicación de realidad virtual. De modo que puse especial cariño en esta parte, buscando una canción relajante y grabando sonidos de un cubo real para posteriormente, cortarlos e incluirlos de manera aleatoria cada vez que se llevase a cabo un giro en la aplicación.

 

Dificultades

Probablemente, la mayor dificultad que me he encontrado es la manera en que Unity ejecuta el código. Es decir ¿Nunca os ha pasado cuando intentáis jugar a un videojuego muy antiguo en un ordenador nuevo que de repente todo va tan rápido que no hay forma de manejarlo? Pues si no vais con cuidado, es muy probable que en Unity os pase lo mismo. Este problema surge principalmente al utilizar la función Update() que básicamente es llamada por la aplicación una vez por fotograma. Es bien sabido que, en función de la potencia de la tarjeta gráfica o del procesador, la cantidad de fotogramas que el juego muestra por segundo puede variar entre 30 o 300, lo cual influye sí o sí en la velocidad de ejecución del código. Por este motivo, hay que tener especial cuidado en como se escriben las diferentes instrucciones, sobre todo las que están relacionadas con el movimiento de los objetos virtuales.

Otra dificultad que me encontré a medio camino de diseñar la interacción con el cubo fue que el programa tenía que hacer muchísimos procesos en muy poco tiempo para calcular que conjunto de piezas debían ser afectadas por el giro, lo que devenía en que lo mismo el usuario se encontraba girando piezas que debieran quedarse estáticas. Por suerte, este proyecto me ha servido para descubrir bastantes trucos de como gestionar el tiempo de ejecución del código en Unity, sin los cuales, no hubiese podido terminar el desarrollo de la aplicación.

Por último, está el tema de la escalabilidad. Como ya he comentado, la idea inicial era hacer un programa escalable que una vez terminado, me permitiese implementar el manejo de cubos de distintas dimensiones como el de 4 o el de 5 piezas. No obstante, cuando empecé a diseñar el código encargado de detectar si el cubo esta resuelto me di cuenta de lo complicado que era hacer eso. Cada cubo, debido a su topología tiene sus particularidades, con lo que es realmente costoso hacer un código escalable en ese sentido.

 

Posibles mejoras

Desde luego, la principal mejora sería incluir cubos de distintas dimensiones o incluso modificaciones del propio cubo de 3 piezas. Aunque también me he planteado adaptar la aplicación para otro tipo de interfaces físicas que permitan el manejo del cubo prescindiendo del uso del ratón. Algunos ejemplo pueden ser Leap Motion o MYO.


Leap MotionMYO

 

Impacto de la aplicación

Realmente no se que impacto puede llegar a tener esta aplicación. Como ya mencionaba al principio, jugar al cubo de Rubik, no es precisamente lo que se espera de una experiencia de Realidad Virtual Inmersiva, lo cual no quita que haya muchos aficionados tanto del propio cubo como de la Realidad Virtual que encuentren interesante probar la aplicación. Lo cierto es que buscando “Rubik Virtual Reality” en Google aparecen resultados que poco o nada tienen que ver con este proyecto, de manera que no descarto publicar la aplicación en la web de Oculus, intentar difundirla a través de las redes sociales o incluso redactar una nota de prensa y enviarla a medios especializados en ocio y tecnología.

 

Usos no previstos

En cuanto a los posibles Hacks o usos no esperados que puedan darse en el manejo de la aplicación solamente contemplo que alguien pueda utilizarla únicamente para escuchar el tema musical que por cierto es de libre difusión y se distribuye en la plataforma Jamendo bajo una licencia Creative Commons BY NC SA. Tanto el título de la canción como su autora aparecen en todo momento en la consola de la interfaz.


JamendoSerakina

 

Conclusión

Como ya he comentado al principio, creo los visores de Realidad Virtual están a la vuelta de la esquina. Quizás, para que estos se conviertan en un producto de consumo masivo, todavía es necesaria la existencia de un contenido que sea indispensable para los usuarios, como por ejemplo lo fue el Whats App en los smartphones. Desde luego, Rubik VR no pretende ni de lejos ser ese tipo de contenido. Pero no cabe duda, de que cuantas más opciones y experiencias podamos ofrecer los desarrolladores, más cerca estaremos de iniciar de una vez por todas este nuevo y apasionante episodio en el mundo de la tecnología, el ocio, y la multimedia.
Adrián Riera
12 de diciembre de 2015

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *