Skip to content

AEC Realtime workflow (parte III)

27 marzo, 2017

Hoy aquí no hay nada de BIM, pero hay una idea asociada que subyace en el horizonte. Quizá a alguno de mis escasos lectores le suenen las formas de la imagen protagonista de esta entrada. Esta imagen encierra unas cuantas horas de trabajo previas que dan lugar a una experiencia de evaluación inmersiva y sobre todo la intención última del trabajo: un test de locomoción VR mediante el paradigma por defecto de SteamVR en un edificio (que por ahora sólo existe como un modelo BIM) de tan colosales dimensiones. Aquí sólo están representadas una parte de las envolventes y todo el entramado interior que las sustenta, todo ello en un estado de diseño muy primario, muy mass modeling, pero que permite vivenciar qué se sentiría dentro de este edificio cuando esté construído y cómo moverse en él de forma inmersiva.

El edificio que representa y su irrupción en mi agenda de trabajo va a hacer que me salte la promesa de la anterior entrada donde decía que hablaría de Autodesk LIVE e Iris VR como herramientas de evaluación temprana de modelos AEC en su fase de diseño conceptual y de desarrollo. De hecho, este también es un camino para hacer lo mismo que con las otras herramientas.

El WIP

Porque, con todos los tests que aún quiero hacer, todavía lo considero Work in Progress. De entre toneladas binarias de documentación que tengo de la primera ola de este proyecto, rescato dos archivitos en formato Rhino (NURBS), fuente primaria de las intenciones de diseño de Foster + Partners. No llevan info alguna de los lucernarios (ahora les llaman foniles), de manera que dejémoslo como viene, que ya haremos los taladros pasantes otro día (por eso es WIP).

Estos archivos son digeridos en primer lugar por medio de AutoCAD, el cual se porta muy bien con este tipo de modelos. Muchos polígonos y muy buena definición, otra historia serían las normales y demás aspectos topológicos de las formas.

Puesto que el DWG convenientemente organizado ya es un formato más friendly para 3DSMax, procedo a su importación contemplando cómo un parámetro de este proceso determina en gran medida el número de polígonos. Como en VR la ecuación nPolígonos=FPS=UX he decidido ser muy cuidadoso en reducir la topología, pese a encontrar luego aristas definitivamente muy poco segmentadas. De ahí que el primer error que encuentro es la inconsistencia en la continuidad entre distintas superficies, algo que corregiré a mano.

La segunda parte en mente es buscar simetrías y preparar el modelo para ser correctamente importado en UE4, aislando, organizando y nominando objetos.

Esa organización ha de tener en cuenta también la continuidad en superficies para el bakeado de luz en UE4 y que no se produzcan discontinuidades exageradas en el lightmapping. Muchos elementos pequeños para conseguir un doble fin: mapas de luz pequeños y cálculo en el Swarm Agent bien distribuido entre los threads de las CPU’s para reducir los tiempos. Dichos cálculos se han realizado relativamente rápido para el tamaño de este environment. (Tengo un servidor enterprise IBM X3850 M2 con 4 Xeon de 4 núcleos y 128 GB de RAM esperando que le monte VMware ESXI para crear 2 o 4 máquinas virtuales para este cálculo, a ver si es posible).

Hay que recordar que una de las premisas en VR es evitar la mayor cantidad de cálculos posibles en tiempo real con el fin de mantener lo más cercana la latencia a los ansiado 11ms, por lo que dejar todo en estático y la luz bien cocinada es garantía de buena UX (evitar motion sickness).

El proceso de unwrapping es esencial y puesto que UE4 lo hace afortunadamente mal para AEC, nada como una sesión en 3DSMax de unwrapping artístico en todos y cada uno de los elementos.

Con todo ello, por fin a UE4, donde el modelo es organizado, replicado en sus simetrías, asignado un material clay, montado un navigation mesh elemental, testadas proporciones, calculados lightmaps, adaptado el Postprocess, y revisados FPS’s.

Locomoción VR

Tras los muchos tests realizados con HTC Vive y Oculus Rift en room scale me he convencido, y así se lo hago saber a mis clientes, de que HTC Vive es la solución recomendada. ¿Porqué?. El sistema de lighthouses de HTC, de Steam o de Valve, quien se quiera atribuir la autoría, permite que las experiencias VR sean verdaderamente lo que llamo 9DOF (degrees of freedom) con controladores en las manos para generar los desplazamientos en el mundo virtual. Las Oculus son más bonitas, más ligeras, mejor terminadas y huelen mejor, pero en el momento en que te das la vuelta y le das la espalda a los sensores, se acabó. Las experiencias que se realicen pensando en Oculus como plataforma, han de ser desarrolladas pensando en un ambiente room scale 180º. Eso limita la libertad del usuario en su visita VR, porque tendrá que pensar entonces porqué diablos cuando se ha dado la vuelta la experiencia comienza a no funcionar del todo bien. Y verá flechitas que le sugieren que se dé la vuelta y se preguntará porqué, si lo que quería era ver lo que tenía detrás. Y tendrá que utilizar los thumbsticks de los controllers y añadir una dificultad más al infundado temor iniciático que se suele tener al meterse en una historia de estas.

Tengo intención de testar el Leap Motion/Orion que tengo por aquí sobre Oculus para olvidarme de sus controllers y asociar gestos de las manos a funciones locomotrices. Esto daría lugar a experiencias sin controllers y 360 puras.

La plantilla pues para montar todo en UE4 fue la que por defecto viene para VR, sobre todo por los blueprints necesarios para trabajar la navegación. Con esa plantilla vienen las manos robóticas que a mi no me gustan nada y que ya han sido sustituidas para el test 2 por los controladores de HTC.

Intimidante Event Graph del Blueprint del Motion Controller. Y eso que es la cara amable de C++.

Existen otras plantillas unofficial que quiero probar, puesto que la idea de la locomoción tal cual está planteada en default de UE4.14.3, está bien, pero me gusta mucho más la idea de Valve en su experiencia Destinations y The Lab, en la que la malla de navegación se visualiza al manifestar el usuario la intención de teleportarse. De esa forma es mucho más fácil que el usuario sepa a dónde y a dónde no puede ir.

Plantilla de navegación en Destinations, sólo visible en el momento en que el usuario procede a desplazarse. Se ve también la ubicación de las cámaras para la restitución fotogramétrica.

Imprescindible para entender las dimensiones faraónicas del edificio ha sido colocar personajes acartonados aquí y allá. Con todo ello, y vista la experiencia por varias personas hay dos corrientes: a unos no les gusta la idea de que tras indicar el lugar destino del teleporting se produzca un fade-out/fade-in a negro y al destino desde el origen en milisegundos de duración y a otros sí. En un lugar tan grande como este edificio puede llegar a resultar irritante. También en exteriores. Yo lo solucionaría haciendo que el “rayo” del teleporting tenga un alcance mayor y no tan limitado. Existe una versión que probaré y que evita este procedimiento fade-out/fade-in y que funciona simplemente realizando una rápida secuencia cinemática del origen al destino, pero que creo yo que en algunos usuarios puede desembocar en la temida combinación de mareos y náuseas (motion sickness). Qué es lo mejor?: dar a elegir cualquiera de las dos opciones y parametrizar por el usuario tanto la distancia del rayo (dentro de unos márgenes), como el tiempo de fade-out/fade-in, como el de la cinemática, si fuera ésta la elección.

No comments yet

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: