¿Quieres realizar realidad virtual para arquitectura? Empieza por aquí

Pablo A. Martín

 

Hace meses que no escribo por aquí (¡feliz 2016!). Desde septiembre hasta Semana Santa he estado abrumado de encargos y no he tenido tiempo de nada (ni de dormir decentemente). Gracias a todos los que habéis confiado en mí durante este tiempo.

 

Entre infoarquitectura de varios tipos, cursos de Photoshop CC y Sketchup en La Casa Encendida y proyectos varios, estoy contento de haber realizado al fin mis primeros encargos reales de realidad virtual para arquitectura. Uno de ellos para una gestora de activos inmobiliarios en colaboración con un estudio en Santa Mónica (California, EEUU) y otro para mi próximo gran proyecto, que presentamos hace un par de semanas en la feria JustMad 7 con gran éxito y que os contaré en detalle en muy poco tiempo.

 

Algunos ya sabéis que llevo tiempo investigando sobre las nuevas tecnologías que llegan a la infoarquitectura, pero salvo algunos casos de tour virtual en 360º, que realmente no es que sea muy novedoso a estas alturas, no había tenido ocasión de realizar algo no como proyecto personal sino como encargo para clientes. Con esta pequeña experiencia y la que sigo desarrollando, voy a ir escribiendo, si mi agenda me lo permite, una serie de pequeños artículos con las características y elementos a tener en cuenta durante la realización de trabajos de realidad virtual, en contraposición a los que solemos realizar en nuestro arquitectónico campo usual.

 

Sin más dilación, comienzo por algo básico…

 


1.- ¿Realidad virtual, para qué?

 

Bueno, claro, una cosa es que llegue un cliente y que diga que quiere algo en VR, ahí poco puedes discutir, pero en otros casos hay que plantearse porqué eta solución es la adecuada, si lo es. Tiene varias ventajas pero también varios inconvenientes.

  • Las ventajas se resumen en: La inmersión conseguida no tiene rival, puedes moverte por el proyecto en 360º y en cualquier dirección, desaparecen los efectos sospechosos de grandes angulares y puntos de fuga exagerados y puedes crear interacciones. Por ejemplo, cambiar el color de las paredes, mover los muebles, encender luces y cosas así.
  • Sus inconvenientes son: mucho más tiempo de desarrollo (y por tanto, coste mayor), resultado menos detallista y limitaciones técnicas muy importantes, de las que hablaremos más adelante. Además, muy poca gente tiene acceso a gafas de realidad virtual, incluso las Cardboard, por lo que este sistema está más pensado en reuniones presenciales con el cliente, no para mostrar al público.

 Eso sí, si lo haces, todo el mundo se acordará de tu proyecto. Ventaja competitiva, que lo llaman.

 

JustMad realidad virtual
Presetación en la feria JustMad, en el COAM, de nuestro proyecto de realidad virtual

2.- ¿En qué dispositivos queremos que se vea?

 

Bien, aquí empieza la marcha. Esta es nuestra primera decisión trascendente. Acabo de mencionar que las limitaciones técnicas son importantes. Bien, si vamos a lo grande, Oculus (o HTC Vive o las que vayan saliendo) + PC es la opción de mayor calidad. Permite tener mucha más libertad para trabajar y conseguir mejores resultados con menos esfuerzo. PERO. Para verlo necesitas un ordenador potente (Oculus Ready, si puede ser), las gafas (que resulta que cuestan 700 €) y un mando para moverte (no, el teclado no vale, intenta girar la cabeza para mirar hacia atrás y escribir a la vez). Esta opción, pues, es para tenerla en tu oficina y que los clientes vayan a verlo. Pierdes parte de la ventaja competitiva y deja de compensar, si lo hacía.

 

Bien, vamos a intentar moverlo en móviles pues. Me han hablado de unas gafas de Samsung...” Mejor, sí. Pero las Samsung Gear tienen un problema: que solo funciona con los últimos modelos de Galaxy Edge (gafas + móvil sale por el mismo precio de Oculus, más o menos) y además las aplicaciones compatibles están excesivamente limitadas y se convierten en incompatibles con otros dispositivos. Ahora esto no importa mucho, porque no hay muchas más opciones. Pero las habrá en breve.

 

Jo, vale, pues las gafas de cartón. Esas son 20€ y valen con todos los móviles ¿no?”. Pues no. La realidad virtual consume muchísima memoria gráfica, más de lo que los dispositivos de gama media manejan, así que o gama alta o nada. Mis proyectos, por ejemplo, mi tableta de hace 3 años ni los abre. Además necesitamos, para que la gente no se maree, los ansiados 60 fps (o cerca) con una latencia extraordinariamente baja y para eso hay que simplificar muchísimo. Ahora entramos en eso.

 

Esto no significa que todas las opciones sean malas, sino que todas conllevan limitaciones importantes. No es tan fácil como decir “quiero realidad virtual” y pensar que ya se tiene todo preparado.

 

En los trabajos realizados para la gestora de activos necesitábamos realidad virtual compatible con móviles de gama alta, inicialmente para gafas Samsung. En el propio que presentamos hace poco queríamos la mayor versatilidad de dispositivos posible y que funcionara con y sin gafas, en PC y móvil, a alta y baja resolución y con varias formas de controlarlo. Sin descargas, por cierto.

 

Lo conseguimos, pero el desarrollo es bastante infernal.

 

Aquí hay más información sobre los dispositivos VR actuales.

 

 

3.- WebGL como opción universal

 

Nuestra opción ha sido WebGL. Esto es, que la realidad virtual no sea una aplicación que haya que descargar sino que sea una página web como esta misma en la que estáis, que en vez de abrir texto o imágenes abra un mundo 3D compatible con realidad virtual, como los videojuegos de explorador (pero sin Flash). Esto seria la panacea para los problemas de compatibilidad de la VR, pero la capacidad actual de la web para manejar 3D es bastante, por no decir muy, limitada.

 

Esto se traduce en tener que realizar modelos muy sencillos y optimizados, low poly y con la menor cantidad de texturas e iluminación posible (esto último es un fallo que solemos tener todos cuando empezamos, pensar que son los polígonos lo que consume más, cuando suelen ser las texturas). Un esfuerzo extra que convierte el trabajo en un proceso mucho más similar al de los videojuegos que a los renders de arquitectura.

 

En cuanto al software que he usado en estos casos…

  • El modelo básico lo suelo hacer en CAD porque los planos me vienen en ese formato (lo siento, fanáticos del BIM, pero no, además para VR prefiero planos 2D en CAD que un modelo 3D BIM que tenga que repetir de cero).
  • 3DS Max para terminar de realizar el modelado y optimizarlo.
  • Vray para realizar bake de texturas (esto lo explicaré en otro post).
  • GIMP y Photoshop para tratar las texturas, que tienen que tener un tamaño específico.
  • Unity para colisiones y gravedad y esas leyes físicas que en 3D a veces uno se olvida que existen.
  • Babylon.js para iluminación y estilo final, optimización y paso a web.

 

Realidad virtual arquitectura
Un wireframe del COAM con unos 40.000 polígonos
Realidad virtual arquitectura
Así quedó el interior una vez acabado...y el edificio entero, con obras, no llegó a los 50 megas!

 

En próximos post os hablaré de los procesos de trabajo que hay que seguir, pero antes de nada, es importante tener estos temas claros, saber por qué, para qué, para quién y de qué modo. Si no, podemos estrellarnos, ya que el cambio en la tecnología elegida puede hacernos tener que repetir el desarrollo completo.

 

Si os ha gustado, compartirlo! Gracias por estar aquí.

 

Saludos!

 



Escribir comentario

Comentarios: 7
  • #1

    Emilio López (martes, 26 abril 2016 21:17)

    Hola, gracias por el artículo. He trabajado unas cuantas escenas de arquitectura en Unreal Engine sin embargo tuve que googlear Babylon.js interesante.

  • #2

    Pau Martí (martes, 26 julio 2016 11:55)

    Muy buenas. Tu post me está sirviendo bastante ya que estoy haciendo el Proyecto de Recerca en Bachillerato sobre la realidad virtual.
    Te animo a que sigas con él si dispones de tiempo :D

    Muchisimas gracias! Ya tendré una opinión de alguien que se dedica a ello

  • #3

    Luis David Arias (sábado, 20 agosto 2016 02:46)

    Hola, Gracias por este fabuloso articulo, La verdad es que estoy pensando en hacer algo como esto para mi proyecto de grado de ingenieria de sistemas, pero estoy teniendo muchas dudas al elegir la plataforma, ya que no tengo dinero para el oculus. Tengo ganas de hacer mis primeras pruebas con cardboard y mi moto x 2014, pero no se si tenga problemas con lo del mareo.

    Espero que sigas con este tema, me podria ayudar mucho.

  • #4

    Rolando Nava (miércoles, 15 febrero 2017 02:58)

    Babylon...? lo veo muy torpe... preferiria modelo.io q es mas dinamico
    como pregunta, no es mejor hacer todo como final en unity..?

  • #5

    Pablo Martín (miércoles, 15 febrero 2017 10:29)

    Buenas Rolando,

    Gracias por tu comentario. Te explico resumidamente las razones:
    Modelo.io y similares no nos valen en ningún caso, porque estamos obligados a: 1.- pagar por su producto en vez de hacer uno nuestro. 2.- Estamos limitados a los que nos deja hacer y nada más.
    Por ejemplo, en el tema de las galerías de arte tenemos que introducir una plataforma de pago, que permita a la gente desde la realidad virtual poder comprar las obras. No existe un programa que te deje hacer eso, así que tenemos que crearlo nosotros.

    Babylon.js no es para arquitectos, es para programadores. Yo mando a mi socio programador todos los objetos con una enrevesada forma de iluminación y texturizado (render to texture, nunca usado en arquitectura) y le digo las funcionalidades que queremos: teletransporte, información de las obras, tutoriales para andar, etc. y él, con el lenguaje de programación, las va creando e implantando. Así, al terminar, tenemos un producto nuestro que podemos no solo enseñar sino vender como propio.

    Y si, es muy torpe y limitado, pero dentro de las plataformas de creación para webGL es la mejor.

    En cuanto al tema Unity (o Unreal, que es mejor), es por dos cosas: primero, al pasarlo para web obliga al usuario a instalarse un plugin. Es una barrera que hace que mucha gente no quiera ni plantearse ver. Segundo, por lo que ocupa en MB o GB. Nuestro edificio de 4 plantas y más de 700 cuadros no llega a ocupar 50 megas. En Unity con eso no haces nada. Para resumir: Babylon = no plugin y 50 megas máximos de descarga (se van cargando según vas viendo cosas, asíque realmente solo cargas unos 10 megas). Unity = descarga de plugin y proyecto de 300 megas.

    No todo es una cuestión visual, hay cosas internas a tener en cuenta para el usuario. Ten en cuenta que esto es para que lo vea todo el mundo, no sólo un cliente.

    Espero haberte respondido correctamente a tus dudas. Un saludo

  • #6

    Rolando Nava (martes, 21 febrero 2017 22:48)

    Estimado Pablo.

    Ucha me dejaste con mucho mas trabajo de investigacion... pense q podia llegar de mejor manera con unity.. pero tienes razon (plugins y el peso)... pero me dijeron q del unity podria pasar a la web...
    Vi eso de render to texture en un plugins q tenia el max. (Torntool) q ya no lo vi mas era bien interesante y hacia esto hace tieeempo...
    Tubieras algun tuto o una guia de donde o como hacer con babylon... porq aqui en bolivia los programadores no creo q me entiendan... q al final seguro terminare programando basicamente como en unity...
    Saludos...

  • #7

    Oscar Veizaga (sábado, 11 marzo 2017 03:04)

    Un saludo
    Felicitarte por el post, podrias dejar algunas referencias de algún tutorial para poder empezar a diseñar para realidad virtual?