Autor
Adrián Termenón Riera
Introducció
Quan em vaig plantejar la tasca de fer una aplicació de Realitat Virtual em van venir moltíssimes idees al cap, però tenia clar que volia desenvolupar alguna cosa per Oculus . Aquesta decisió, no només es deu al fet que ja conte amb certa experiència tant amb el dispositiu com amb Unity , sinó també al fet que considero que els visors de realitat virtual , ja siguin d’escriptori o portàtils , actualment es troben en aquesta fina línia temporal que separa la tecnologia que només fan servir uns pocs de la que s’utilitza de manera manera massiva , tal com al seu dia ho van estar els smartphones . En definitiva crec que té futur .
No obstant, la idea de jugar al cub de Rubik pot semblar una mica avorrida , si es compara amb el que l’usuari mitjà espera de la realitat virtual immersiva. És a dir , experiències trepidants i plenes d’adrenalina . Però opino que com més continguts hi hagi disponibles , més ràpid s’estendrà aquesta tecnologia a la societat . Potser per això i perquè fa bastant anys que sóc aficionat als cubs vaig prendre la decisió de portar aquest projecte endavant.
Procés de treball
1. Modelar el cub
La primera etapa del projecte va consistir en el modelatge 3D del cub , per a això vaig utilitzar el programari 3DS MAX 2014. Això , va suposar innombrables avantatges respecte a l’entorn Java Script en el qual vaig desenvolupar la primera aplicació degut, principalment, a les eines que ofereix la interfície de treball de MAX.
2. Dissenyar la interacció
Un cop modelat i texturitzat, el següent pas va ser dissenyar la interacció amb el cub en Unity 5. El primer que em vaig plantejar en abordar aquesta tasca és que no volia limitar el gir del cub tal com vaig fer en la primera aplicació. Després de tot, una mica més d’un any d’experiència amb Unity, m’ha permès familiaritzar-me amb la classe Vector3, la qual ofereix infinitat de mètodes enfocats a la transformació d’objectes en un espai euclidià, tal com és l’entorn virtual en el qual es desenvolupa l’acció.
Així doncs, en la primera aplicació desenvolupada en Java Script , la galleda sempre romania orientat en la mateixa direcció , i era la càmera la que rotava al voltant seu quan l’usuari desitjava girar-lo . Això simplificava força el maneig de les diferents cares però , al mateix temps , suposava un problema. Calia escriure un codi específic pràcticament per a cada peça i cada gir. És a dir , si ara volgués fer una versió de la galleda de 4x4x4 o de 5x5x5 , hauria de reescriure pràcticament la totalitat del codi. Per contra, en Unity i gràcies a les seves eines vectorials he aconseguit que sigui el cub el que gira sobre si mateix mentre que la càmera, és a dir , el subjecte virtual , roman estàtic en la mateixa posició.
D’aquesta manera , el guió de la interacció per al maneig del cub és el següent :
1 – seleccionar la peça
L’usuari fa clic sobre una peça , de manera que el programa guarda a la memòria la cara del cub en qüestió i el vector normal de la mateixa.
2 – seleccionar el conjunt de peces
L’usuari arrossega el cursor sobre el pla de la cara , de manera que es guarda un nou vector que permet al programa saber que conjunt de peces és el que es desitja girar.
3 – girar el conjunt de peces
Un cop guardades les dades necessàries , el programa calcula l’eix i angle de gir a partir del producte vectorial de la normal de la cara i la direcció del moviment del cursor sobre la mateixa.
4 – finalitzar el gir
Finalment. quan l’usuari deixa de pressionar el botó del ratolí el programa restaura la rotació de la cara en funció de l’angle més pròxim.
A part de la interacció amb el cub està també la interacció amb la pròpia aplicació, el guió és molt senzill. Simplement es basa en els possibles estats en què es troba el cub o el joc. D’una banda, si el cub està resolt o no i, d’altra banda, si el jugador està tractant de resoldre, o simplement aquesta jugant amb ell sense cap finalitat en concret.
3. Dissenyar la interfície lògica
Arribat a aquest punt , el que volia evitar de totes totes que fa a la primera aplicació és que l’usuari realitzés un gir no desitjat per error . Per a això, em vaig proposar delinear en tot moment els elements susceptibles de ser modificats. D’aquesta manera , el jugador disposa de la informació visual necessària per saber amb exactitud que peça o conjunt de peces es disposa a girar.
D’altra banda, em va semblar bona idea incloure una consola per poder mostrar informació sobre l’estat de l’aplicació, és a dir , si la galleda es aquesta desordenant , si el cronòmetre està actiu o si el jugador ha aconseguit resoldre el cub .
Finalment , vaig afegir uns senzills controls per poder desordenar la galleda o resetejar-lo , conèixer les dreceres del teclat , regular la il·luminació de l’escena o la intensitat de la música o poder tancar l’aplicació sense necessitat de llevar-se les Oculus .
4. Adaptar la interfície física
Per sort , aquesta part del desenvolupament no va suposar cap complicació , en part pel fet que Unity ja té les opcions de Realitat Virtual i Visió Estereoscòpica que automatitzen completament els processos de mapejat entre el gir del visor, en aquest cas les Oculus DK2 , i el gir de la càmera en l’escena.
Una mica més complicada va ser la part de mapejar el moviment 2D del ratolí per adaptar-lo a l’entorn tridimensional de l’aplicació. Sobretot en determinades circumstàncies en què l’usuari havia desplaçar el cursor virtual al llarg d’un pla bastant perpendicular a la seva pròpia visió. Però finalment , no em vaig trobar amb cap problema que no pogués solucionar amb trigonometria bàsica.
5. Dissenyar el concepte
Ja des del principi tenia bastant clar que l’entorn havia de ser el més neutre possible . Finalment i després de fer diverses proves em decanti per integrar un pla a manera de sòl, que pogués il·luminar o enfosquir depenent de les preferències de l’usuari . També vaig decidir afegir unes partícules molt tènues situades al voltant de la zona d’acció , per augmentar la sensació de profunditat de l’entorn i afavorir la sensació de presència de l’usuari.
Finalment , el so és un factor molt important per potenciar aquesta mateixa sensació de presència tan indispensable en una aplicació de realitat virtual . De manera que vaig posar especial afecte en aquesta part , buscant una cançó relaxant i gravant sons d’un cub real per posteriorment , tallar i incloure’ls de manera aleatòria cada vegada que es dugués a terme un gir en l’aplicació.
Dificultats
Probablement, la major dificultat que m’he trobat és la manera en què Unity executa el codi . És a dir Mai us ha passat quan intenteu jugar a un videojoc molt antic en un ordinador nou que de sobte tot va tan ràpid que no hi ha forma de manejar ? Doncs si no aneu amb compte , és molt probable que en Unity us passi el mateix. Aquest problema sorgeix principalment en utilitzar la funció Update ( ) que bàsicament és cridada per l’aplicació un cop per fotograma . És ben sabut que, en funció de la potència de la targeta gràfica o del processador , la quantitat de fotogrames que el joc mostra per segon pot variar entre 30 o 300, la qual cosa influeix sí o sí en la velocitat d’execució del codi . Per aquest motiu , cal tenir especial cura en com s’escriuen les diferents instruccions , sobretot les que estan relacionades amb el moviment dels objectes virtuals .
Una altra dificultat que em vaig trobar a mig camí de dissenyar la interacció amb el cub va ser que el programa havia de fer moltíssims processos en molt poc temps per a calcular que conjunt de peces havien de ser afectades pel gir , el que esdevenia en què el mateix l’usuari es trobava girant peces que haurien de quedar-se estàtiques. Per sort , aquest projecte m’ha servit per descobrir bastants trucs de com gestionar el temps d’execució del codi en Unity , sense els quals , no hagués pogut acabar el desenvolupament de l’aplicació.
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.
Finalment , hi ha el tema de l’escalabilitat . Com ja he comentat, la idea inicial era fer un programa escalable que un cop acabat, em permetés implementar el maneig de cubs de diferents dimensions com el de 4 o el de 5 peces . No obstant això, quan vaig començar a dissenyar el codi encarregat de detectar si la galleda aquesta resolt em vaig adonar del complicat que era fer això. Cada cub , per la seva topologia té les seves particularitats , de manera que és realment costós fer un codi escalable en aquest sentit.
Impacte de l’aplicació
Realment no es que impacte pot arribar a tenir aquesta aplicació . Com ja esmentava al principi, jugar al cub de Rubik , no és precisament el que s’espera d’una experiència de Realitat Virtual Immersiva , la qual cosa no treu que hi hagi molts aficionats tant del propi cub com de la Realitat Virtual que trobin interessant provar l’aplicació . La veritat és que buscant ” Rubik Virtual Reality ” a Google apareixen resultats que poc o gens tenen a veure amb aquest projecte , de manera que no descarto publicar l’aplicació al web de Oculus , intentar difondre-la a través de les xarxes socials o fins i tot redactar una nota de premsa i enviar-la a mitjans especialitzats en oci i tecnologia .
Usos no previstos
Quant als possibles Hacks o usos no esperats que puguin donar-se en el maneig de l’aplicació només contemplo que algú pugui utilitzar-la únicament per escoltar el tema musical que per cert és de lliure difusió i es distribueix a la plataforma Jamendo sota una llicència Creative Commons BY NC SA . Tant el títol de la cançó com la seva autora apareixen en tot moment a la consola de la interfície.
Conclusió
Com ja he comentat al principi, crec els visors de Realitat Virtual estan a la volta de la cantonada. Potser , perquè aquests esdevinguin un producte de consum massiu , encara és necessària l’existència d’un contingut que sigui indispensable per als usuaris , com ara el va ser el Whats App en els smartphones . Per descomptat , Rubik VR no pretén ni de lluny ser aquest tipus de contingut. Però no hi ha dubte , que com més opcions i experiències puguem oferir als desenvolupadors, més a prop estarem d’iniciar d’una vegada per totes aquest nou i apassionant episodi en el món de la tecnologia , l’oci, i la multimèdia .
Adrián Riera
12 de diciembre de 2015