Skip to content

One click BIM2VR (o casi)

2 agosto, 2017

Quienes me conocen saben que llevo ya unos dos años sopesando el concepto de tiempo real de calidad y VR aportado por motores de gaming como Unity, Unreal Engine o Cry Engine aplicado a Arquitectura e Ingeniería Civil, coloquialmente AEC.

En noviembre de 2015 tenía listo un test formal para un cliente premium como Abbott Laboratories, división de diagnósticos automatizados. Fue realizado en Unity y testado en una Oculus DK2, con más o menos éxito y “Wows” varios. Un tiempo de desarrollo no adaptado a la dinámica del cliente dejó en el desván la iniciativa, decantándonos por recorridos virtuales apoyados en renders esféricos, como los ejemplos que hay en entradas anteriores a esta, mucho más rápidos de llevar a cabo, normalmente 3 o 4 días como mucho. Y han debido tener mucho éxito cuando no solamente los realizo para España y Portugal si no que están teniendo también una demanda notable en Reino Unido con esperanzas en Italia, Holanda y Oriente Medio.

Desde entonces y hasta ahora me he volcado mucho más en “BIMificar” las planificaciones a nivel de anteproyecto para licitaciones, teniendo como resultado la posibilidad de realizar hasta 6 opciones de una planificación de un laboratorio medio en menos de dos horas, por supuesto con todas las ventajas que aporta BIM a un LOD100. Para una multinacional que viene de planificar en Visio no está nada mal.

Pero durante los últimos meses he establecido más o menos el flujo de Revit a VR para ofertar modelos interactivos inmersivos en una semana realizados en Unreal Engine, el motor finalmente escogido por razones que ahora no vienen al caso. Faltan por adaptar unas librerías o assets a UE4 en VR (objetivo no superar 11 ms de latencia) como lo fueron adaptadas como familias en Revit para tenerlo todo hilado.

Durante este tiempo han ido apareciendo diversas soluciones de tiempo real. De entre todas ellas la más atractiva y con un grado de madurez cierto es Enscape. Algunos clientes hacen uso de ella y la considero relativamente buena a un nivel de calidad medio. No he tenido tiempo de testar el producto pero sé por ensayos publicados y terceros que es bueno según para qué objetivos. Fases tempranas de diseño y sin pedir un producto muy refinado son su nicho de funcionalidad. He descargado una demo no de fábrica, que amablemente Phil Read, CEO de Read | Thomas (y sosías del gran Phil Read, piloto mítico de motociclismo), deja para descargar de un producto que hace uso de una técnica que comenta en un post en LinkeIn. Me interesaba especialmente por venir de Revit de forma directa. En pantalla Full HD no va mal, bien de FPS, pero la iluminación no es nada del otro mundo, amortiguada en gran medida a través de Ambient Oclussion en Screen Space. No creo que hagan uso de GI bakeada. Materiales regulares, pero es una solución pura One click, por lo que no es la mía si no la de estudios y clientes con cierto grado de autonomía y conocimiento como para hacer tiempo real con herramientas como esta. La versión VR es tristemente inutilizable, al menos en un equipo que mueve algo tan refinado como Robo Recall sin despeinarse, por lo que este producto tal cual sale no me vale para VR, un mareo total. Quizá han olvidado activar algún parámetro para VR, porque me extraña lo mal que ha ido la demo. Aquí el game play de pantalla que sí va muy bien:

Otra cosa que me ha extrañado es la ausencia de colisiones, por lo que podemos andar por el modelo como un fantasma, atravesando todo. En VR no hay el equivalente a “navigation mesh” para teleportación lo que conduce a que a la mínima que queramos llevar al límite la experiencia acabaremos subidos en muebles y otras cosas.

Pero durante el último mes se han dado a conocer dos soluciones realmente disruptivas, como se dice ahora, en el escenario.

Twinmotion 2018

Una es Twinmotion 2018, de Abvent. Una solución que hace uso de UE4 como motor de render, e inspira por tanto la confianza de una calidad superior a Enscape y a años luz de LIVE. Tengo una beta recién descargada de la que haré uso la semana que viene si es posible y poder tener así una opinión bien fundada. Enlace directo a ArchiCAD y Revit, prácticamente una solución “One click” de alta calidad. Mientras tanto he descargado una demo que he testado tanto en modo pantalla como en VR y de la que ofrezco este gameplay de pantalla, porque la versión VR no me ha satisfecho. Quizá ha sido realizada con versiones precedentes a la que se ha publicado ayer.

Esta demo se centra principalmente en materiales, con todas las características que UE4 puede dar por sí solo. Hay que recordar que en tiempo real y aún más VR las texturas deben tener tamaños realmente considerables, lo normal es 4K, ya que es normal estar muy cerca de los objetos. Así, la memoria gráfica se puede saturar de mapas y comenzar el streaming o intercambio de mapas según necesidades. Bien, pues esta gestión en esta demo se ve realmente bien. Hay algunos objetos sin colisión y al poco de comenzar ya se ve un bug en navegación, pero bueno, la solución es realmente buena para acortar plazos. En VR tiene algunos problemas, no tantos como la mareante demo de Enscape & Read, pero los tiene: probada tanto en Oculus Rift como en HTC Vive, en ambos casos no he encontrado teleportación, ni forma de moverse ninguna. Al ponerse las gafas uno está a una altura que no le corresponde, por lo que algo ahí dentro no funciona bien. Y los fps no son estelares, más bien malos, nada que ver con apps más maduras y hechas a propósito de forma nativa. De hecho ya he preguntado si la app cambia de Deferred a Forward rendering.

Datasmith (ex Project Nile)

Lo que he realizado en los últimos meses, es decir, aprender el flujo de trabajo óptimo de un modelo BIM (Revit) a tiempo real y VR incluye una larga lista de operaciones creativas y trabajosas. Orientadas todas ellas al máximo de FPS, mínimo número de polígonos, bakeo de GI de calidad, rendimiento en ordenadores no gaming, programación de eventos, redes de navegación VR, unwrapping adecuados, materiales PBR, y más cosas. Muchas más. Al parecer Datasmith sería un middleware capaz de realizar bastantes de estos pasos de una forma automatizada, previsible y de calidad. Lo que nos podría conducir a ejecutables nativos, abiertos (Twinmotion da un resultado cerrado, no se puede abrir en UE4 en esta versión), escalables y buenos como si los hubiera hecho uno mismo. Estoy pendiente de que me aprueben mi solicitud a betatester. Si hay suerte podré testar, pero si no, tampoco es un drama. Sé que lo que debe dar es algo muy cercano a un trabajo puro realizado de manera amanuense y con la pinta de cualquier producto nativo UE4 bien hecho. Como no puedo colgar ninguno de los dos productos recientes que he realizado de esta manera en UE4 por razones de confidencialidad (siempre igual) pongo esta demo testada de los chicos de ArchVirtual, realizado eso sí, en Unity. Pero se trata más o menos de lo mismo:

 

¿La hora de VR HQ sin cables?

15 julio, 2017

TPCAST montado sobre la Vive

Actualizado 2/8/2017 – SIGGRAPH Los Angeles

Presentada HP Z VR Backpack PC. La hermana “Enterprise” de la Omen.

 

Se afirma, y yo creo que es cierto ahora que Apple ARKit ya es un hecho, que este es el año cero de AR.

Como el año pasado lo fue de VR. Mientras AR y MR comienzan a despuntar, de lo que no cabe duda es de que VR sigue su camino con mejor o peor salud según los sectores y con la convicción, no sólo mía si no de muchas personas de diversos sectores con las que hablo, de que es en el sector “enterprise” donde está teniendo un inesperado mejor éxito que en el gamer.

De esto yo ya estaba seguro: el gasto de un equipo que entre pitos y flautas (con PC High-End incluído) se puede ir fácilmente a los 3000€ y el espacio requerido para vivencias “room scale” no está al alcance de cualquier adolescente pero sí de las empresas, especialmente AEC e industrial.

Este tipo de experiencias van ligadas a día de hoy sólo a Vive y Rift. Que no me vengan con historias, la potencia de una 980 Ti a un Titan X no cabe en un móvil por muy gama alta que sea, y las aventuras sin cable de Vive y Rift que tenemos en ciernes veremos qué aportan. Por ahora y para AEC enterprise sólo confío en estos modelos.

Hay un rasgo común que pesa sobre esta opción: el cable, el cordón umbilical que nos une a la potencia gráfica, a mover muchos polígonos con la deseada latencia de 11ms. Se enrolla, se pisa, se ensucia. Es incómodo pero necesario. Y además nos restringe a un área de actuación tan grande como lo que permite cada opción, unos pocos metros cuadrados.

Hace unos meses se han desbrozado caminos incipientes muy interesantes, que si quedan unidos a las tecnologías “inside-out” de posicionamiento de las gafas hermanas tipo Hololens o Daqri o de los desarrollos de Tango y ARKit nos podrían conducir a un concepto un escalón por encima: VR “world scale” de altas prestaciones.

Estos dos caminos son por un lado los PC’s mochila de HP(septiembre), MSI o Zotac y por otro los sistemas como TPCAST (Por ahora sólo en China).

HP Omen X VR en su dock

HP Omen X VR montada en el chaleco

En el caso de las primeras la idea es tan sencilla como crear un portátil de gama alta sin pantalla y bien nutrido de gráfica, meterle unas baterías bien grandes que garanticen suministro de corriente durante algo más de una hora, buena ventilación y colocarle un chaleco o correas que permitan ponérsela. La autonomía es segura, y el único problema es salirse del espacio destinado a VR y el peso sostenido durante mucho tiempo.

MSI VR One

En el caso del TPCast básicamente se trata de una conexión inalámbrica de 60 GHz para Vive (emisor y receptor), que se supone que perjudica lo mínimo la latencia. Transmite video y audio sin percibirse ninguna merma en la calidad, si el emisor está bien situado y no hay interferencias con otros canales Wifi. Aporta también una batería 20.100 mah, ojo, que alimenta la Vive y el propio TPCast, en un cinturón, durante más de 4 horas. Libertad total.

TPCAST Receptor

Sea la opción que sea la elegida se abren puertas que antes no teníamos y es la posibilidad de tener espacios “room scale” mucho más grandes, y aquí nos encontramos con el límite de los sensores y emisores de Rift y Vive respectivamente. La base tecnológica (outside-in) que emplean es muy precisa, para mí la mejor, dada en valores absolutos de 6 grados de libertad (9 con teleportación). Pero quizá sea el momento de pensar en una segunda ola de HMD’s de este tipo con tecnología inside-out, que siendo menos precisa bajo mi punto de vista ha mejorado muchísimo: la combinación de giroscopios de altísima calidad con la detección del entorno por medio de tecnologías como Tango y ARKit o sensórica móvil a partir de patrones de luz estructurada daría lugar a HMD’s de alta calidad con toda la fuerza bruta de gráfica delegada y “world scale”. ¿Un sueño?. Antes de 2020 lo tenemos fijo.

 

Unreal Engine Swarm Agents sobre máquinas virtuales en ESXi 5.5

28 junio, 2017

Fig. 1: máquinas reales vs. máquinas virtuales peleando en un cálculo de lightmassing para una evaluación de un viaducto en fase de diseño para VR. Cada línea es un core, líneas cortas, proceso  terminado antes, líneas largas, proceso de mayor duración o incluso sin acabar.

Con un título tan poco alentador cuelgo esta entrada que hace la número 100 en este blog.

Me suelen decir que mis artículos son demasiado técnicos, muy poco atractivos a la hora de evangelizar a las masas o de darme publicidad, pero sinceramente me da igual, ya hay quien se dedica a esos menesteres. Debo haber tenido algún antepasado luterano y así me va. Quien haya llegado aquí y no por desavisado, tendrá la oportunidad de comprobar como comenzamos la doctrina:

Según avanza el curso de Unreal Engine aplicado a arquitectura que voy haciendo (para corregir vicios y conceptos mal adquiridos) y según la carga de trabajo me permite (tarde, mal y nunca), voy por un lado ensamblando las piezas que compondrán mi flujo de Revit a Unreal Engine (BIM2VR) y por otro divagando con aventuras que creo que acelerarán ese flujo de trabajo hasta hacerlo tan cotidiano como un render de 3DSMax.

La calidad que se obtiene en UE4 responde a muy diversos factores siendo uno de ellos el cálculo de distribución de la luz, como sucede con motores de render como Vray. Si bien con objetos estacionarios o movibles y en exteriores se puede recurrir a iluminación en tiempo real, quienes desarrollamos no hemos de olvidar que el cliente ni tiene, ni tendrá máquinas como las que tenemos nosotros y que por tanto nos arriesgamos a que nuestra aplicación interactiva en tiempo real tan pulida, tan resultona y tan fluida sea un desastre en los ordenadores del cliente.

  • Por tanto la primera premisa es: utilizar en lo posible iluminación precalculada, procurando tener un balance equilibrado en el número de mallas estáticas de tal forma que no las haya muy grandes que exijan mapas enormes ergo cálculos muy largos.
  • La segunda es tener en cuenta el proceso distribuido, simétrico, paralelo que supone el cálculo de n lightmaps.
  • La tercera es que la variable n vendrá dada en función del número de mallas estáticas que tengamos en la escena. Más o menos, y debido a que el algoritmo de lightmass decide por su cuenta o en base a escondidos parámetros guardados en algún .ini agrupar o no algunos lightmaps en atlas más grandes por optimizar recursos de memoria.

Aprovechando ofertas de amistades he dejado provisionalmente mi estudio como un taller de reparación de ordenadores, ya que en poco tiempo han entrado varios servidores (6) de todo pelo, desde “desktop” de los de poner en el suelo a un enrackable como el de la figura 2.

Fig. 2: esperanzador aspecto de la primera pantalla en el boot interminable de este System X

Me hacía especial ilusión que un IBM genuino volviera a entrar en mi vida. Aprendí a programar en los tiempos de los IBM PC y XT con pantallas de fósforo verde y cariñosas impresoras matriciales. Las características de este equipo hacían que aceptara la oferta de probarlo para cálculos que no tienen en principio nada que ver con los que llevaron a crearlo: 4 Xeon relativamente viejos (2010) que suman 16 núcleos y 128 GB de RAM. Puesto que un Windows normal sólo acepta 2 procesadores físicos, había que elegir entre Windows Server, Linux o algo para mí desconocido hasta entonces que es VMware ESXi. Opté por este último porque en su versión 5.5 es de libre disposición, muy contenido en su instalación, muy de pantalla de fósforo verde, es decir, textos y nada de interface gráfica y con un parque instalado suficientemente garantista.

Fig. 3: Interior del bicho

La modularidad de estos aparatos, en los cuales casi todo es intercambiable en caliente, es increíble. El arranque es eterno, debido entre otras cosas al número de tarjetas que traía instaladas y diversos chequeos.

Vaciado de todo lo que no era estrictamente necesario (tarjetas de red convencionales y fibre channel) e instalado el S.O., el arranque es ya más “rápido”. En este momento deja de ser necesario monitor y teclado, puesto que todo el proceso de instalación de máquinas virtuales se realiza de forma remota desde VMware vSphere Client. Decidí crear dos, con las características que se puede ver en la figura 1.

Instalados los componentes que requiere Swarm Agent, Ip’s, parámetros varios y reconocidas las máquinas virtuales por Swarm Coordinator los cálculos de luz fluían…. como no esperaba, es decir, muy mal para los Xeones del servidor X. Y es que según las comparativas, estos procesadores son ya muy viejos y con unas características que se han visto superadas de largo por otros Xeon no tan antiguos e I7.

Días después realicé otras pruebas con otros servidores equipados con Xeon más recientes de hasta 16 cores que reafirmaron tan empíricamente la idea de que el x3850M2 ya no es una máquina para realizar cálculos de lightmass tendiendo en cuenta el nivel de ruido que tiene y sobre todo el consumo, más 1400 W de fuente de alimentación (redundante).

Fig. 4: lo que se llama “dar sopas con ondas” en relación a la Fig. 1. Todas son máquinas físicas.

Tanto en la figura 1 como en la 4 se pueden apreciar procesos acabados mientras otros siguen en marcha debido a que son cálculos de mayor envergadura (mallas estáticas más grandes) para los que se ha dedicado un solo core.

No sé en que medida la virtualización de máquinas recorta las prestaciones de unos Xeon de por sí anticuados, sin instalar un Windows Server que me permitiera ejecutar procesos distribuidos en 4 procesadores físicos no puedo más que especular, pero no voy a perder el tiempo, siempre tengo mucho lío y fechas de entrega muy cortas.

Lo que sí es cierto es que en el mercado abundan los servidores “enterprise” de tipo enrackable de características interesantes a unos precios muy contenidos, como este por ejemplo: HP Proliant DL580 G7 Barebone System 4x ten core e7-8867l/64gb memory / 2x 300gb 10k / rails / 4x psu

Este figura es un especialista, trabaja en un Data Center y sabe la tira, para quien quiera ahondar en este mundo.

Intuyo que esta abundancia de servidores sea debido a que se está produciendo una tendencia a evitar tener centros de cálculo “in house”, por su coste de mantenimiento, por seguridad, por su coste de renovación y por su consumo, dirigiendo la demanda de proceso de cálculo a soluciones en la nube como Amazon Web Services, donde cada cual se puede alquilar por horas las necesidades de cálculo que requiera e incluso ofrecen máquinas preconfiguradas para procesos específicos.

IBM, HP, etc también llevan tiempo ofreciendo estos servicios. Si por consumo eléctrico fuera podemos utilizar las migajas.

A día de hoy están apareciendo tentativas, experimentos, aventuras de las que he hablado en LinkedIn como Project Nile, porting de Vray a UE4, nVidia VXGI, Light Volume Propagation, etc, todas ellas en fase experimental, y algunas con clara tendencia a Iluminación Global en tiempo real, (Otoy Octane integrado en el futuro Unity 2017 mete presión) sin embargo pienso que siempre será requerido el “cocinado” de luz para agilizar experiencias en equipos de rango medio, bajo o móviles, es decir, el parque de dispositivos más grande al que habitualmente optaremos para el destino de nuestros productos AEC.

 

 

“Mockups” para un nuevo analizador

24 abril, 2017

Resultado final, y seguimos imprimiendo

Desde sus fases iniciales mi cliente me comentaba lo secreto del producto. Del cual ni ahora puedo mencionar su nombre. La competencia es feroz.

Como el uso de los kits impresos como éste ha sido todo un éxito, extendiéndose su uso en Portugal e Italia, y seguramente en otros países próximamente, por su versatilidad y la implicación en lenguaje natural del cliente final en la fase de diseño de la solución, pues tocaba realizar un modelo igual de versátil del nuevo analizador.

El analizador se compone de una serie de unidades que se ensamblan según las necesidades, es decir, está concebido bajo unos criterios de escalabilidad y flexibilidad. Por lo tanto el modelo que lo representa debía alumbrar desde su diseño primigenio las mismas características, y no plantearse representar las 4 posibilidades de configuración básica mediante 4 modelos diferentes, si no diseñarlo bajo los siguientes ideales de partida

1.- Mínimo número posible de unidades/máximo número posible de configuraciones

2.- Fácil conexión entre unidades

3.- Representación inequívoca de la realidad

4.- Resistencia al manipulado cotidiano (evitar anisotropía en impresión)

5.- Mejora en calidad de impresión vs. evitar material de soporte

Ya teníamos claro desde el principio que íbamos a modelar 4 unidades que iban a representar los 6 módulos reales posibles que ensamblados darían lugar al menos las 4  posibles configuraciones.

Versión 1

Veníamos de hacer uso de unas costumbres que funcionaban bien para los anteriores modelos del kit, es decir: layer de 0.2 y material de soporte. El resultado vino a ser tan malo como este:

Acabados malísimos debido a temperaturas y orientación de la impresión en el modelo inadecuadas

Machihembrado con buenos propósitos pero complicado de ajustar y frágil, detalles innecesarios, demasiado tiempo de impresión por ir con material de soporte y layer 0,1

La idea de imprimir “tumbado” venía sobre todo por una ligera pendiente que tiene el modelo en su parte superior y que prefería representar bien por la dificultad que tiene este tipo de “features” en impresión FDM si se quiere evitar el tedioso postproceso.

Versión 2

Lo más importante era simplificar el modelo sin perder la idea de lo que representa así como un machihembrado más resistente y fácil de ensamblar. Aún así el resultado seguía siendo bastante pobre, especialmente en algunas piezas.

Un machihembrado más sólido, pero difícil de manipular, demasiado ajustadas o demasiado flojas las tolerancias

Sigue habiendo fragilidad y acabado tosco

Esta versión seguía estando diseñada para usar material de soporte: “coffee break” para retirarlo con limoneno

Como todo plástico, el ABS tiene unas características térmicas de tolerancia para piezas que deben quedar ajustadas pero libres en su movimiento, por lo que hay que hacer muchas pruebas hasta dar con el modelo perfecto. Simplifiqué el modelo, sin embargo seguía siendo frágil al manipulado.

Versión 3

En la versión 3 decido cambiar la orientación de impresión, pero me encuentro con que algunas partes de alguna pieza, al ser de las últimas capas son impresas demasiado deprisa, no dando tiempo al ABS a enfriarse, y desvirtuándose por completo el resultado. El parámetro de “minimal layer duration” no funciona, por lo que decido hacer uso de “torres mártires” para obligar a que la duración de impresión por capa sea mayor. El uso de muros de limpieza laterales ayuda también a eliminar restos que quedan pegados en el extrusor, dando todo ello un resultado que mejora mucho las versiones precedentes. Seguía usando material de soporte, lo que sumado a layer 0,1 da tiempos de impresión muy largos.

Torres con igual altura que la máxima altura de pieza a imprimir y muros de limpieza

Cuidado al manipular, la impaciencia quema

Retirada de “rafts” y material de soporte, a pelo, sin limoneno ni nada porque con un nuevo diseño no hacen falta baños

Versión 4

Creo que esta fue la primera versión sin material de soporte. Engrosé también algunas características y dí aún mayor solidez a todos los elementos de cada pieza. En modelismo FDM no siempre es fácil representar a escala absoluta todo, ya que habría partes que físicamente no podrían ser impresas (mínimo ancho imprimible es 0,4 mm) y además resultarían muy frágiles para objetos que no son para estar en una vitrina y van a ser manipulados por mucha gente.

En esta versión las cosas ya van saliendo bastante mejor. El “despegue” entre las “shell” de lo que representa una pantalla es debido a que la dimensión no es múltiplo del ancho de extrusión, 0,4 mm, y además no cabe un “inshell”. Hasta en eso hay que pensar.

Detalle de la evolución de los machihembrados, con un acabado tan tosco como el del “raft” que fue retirado

Versión 5

Sirvió para pulir algunos aspectos, mejorar tolerancias de montaje y reducir tiempos de impresión que aún así se van a casi 10 horas.

Bonito detalle de todos los elementos que conforman una unidad completa

Las distintas configuraciones posibles y en cualquier orden

 

Versiones 6 y 7

A alguien se le ocurrió rizar el rizo y probar a imprimir en dos colores puesto que no hacía falta ya material de soporte. La elección de colores fue corporativa del producto pero no nos gustó a nadie:

Versión 8 (5b)

El color verde es el de la línea gráfica del producto por lo que la decisión final fue hacer uso de él para diferenciarlo de otros analizadores. El resultado es el de la entrada y las imágenes que a continuación pego:

Cuando tras casi 7 horas de impresión ves esto te da una alegría. No todos los intentos acaban así: los atascos en extrusor por mala nivelación de cama son frecuentes, como el progresivo deterioro en el “kapton”, o la limpieza necesaria en extrusor y rodillo de alimentación, por no hablar del deterioro de filamento por absorción de humedad…

Pequeño ejército de bribones que me dio mucho trabajo, y aún no hemos terminado, falta otra tanda al menos.

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.

Segundo ejercicio curso Unreal Engine para Arquitectura Interactiva en tiempo real

5 marzo, 2017

Esto va viento en popa. Aquí la prueba de haber completado el segundo ejecutable. En estas sesiones hemos aprendido entre otras muchas cosas a cambiar de nivel, y añadir más interactividad como cambiar materiales, abrir y cerrar puertas, blueprints incipientes y a afianzar un flujo de trabajo que se vislumbra ya más o menos nítido. Los triggers son unos benditos, los adoro, aunque van un poco por libre cuando los abandonas. El gameplay ha sido capturado a 4K y 60 fps. La GTX980 Ti sudando… esa vegetación.

La 4.14.3 me sigue dando algunos problemillas, por ejemplo ha sido imposible capturar ninguna de las secuencias preparadas con Matineé, se queda tostado. Por otro lado, los materiales del cambio de la pared del dormitorio, tras un build de iluminación, dejaron de funcionar y hubo que sustituirlos por otros nuevos. Tengo mi opinión personal sobre la plantilla de inicio que estamos usando, creo que es fuente de problemas y viene bastante sucia.

Algunas cosas que me gustaría mejorar y espero ver a lo largo del curso: he intentado por mi cuenta situar el playerstart de cada nivel en el lugar que por navegación le corresponde sin conseguirlo. El AOSS (ambient oclussion screen space) no me gusta. Es un recurso que está muy bien para exteriores o como último remedio para ir depurando todos los aspectos del interactivo, pero no lo hace bien: desaparece en los bordes de la pantalla (por eso es screen space) y el algoritmo confunde dónde debe aplicarlo (o quizá el radio es muy grande), por las barandillas lo digo. Pienso que ha de hacerse bakeado. Las reflexiones son muy muy mejorables, hemos de aprender a afinar todos los parámetros de los probes, lightmass y demás.

De la sensórica y el Big Data a la vivencia más deslumbrante en VR pasando por BIM

22 febrero, 2017

Del artículo al que hace referencia Esteban Campos en LinkedIn me sale esta entrada sin quererlo, puesto que lo que pretendía ser una respuesta de acompañamiento y cortesía a la suya, simplemente no cabe como respuesta en LinkedIn por mi exceso de incontinencia literaria.

El análisis de los patrones del comportamiento humano en edificios y sus entornos próximos a través de cámaras y sensórica (el sistema de posicionamiento indoor de Phillips por ejemplo), de la influencia en el tiempo de agentes externos (más sensórica, de todo ello sabe bastante mi colega Manuel Meijide y así lo demuestra con su sensacional herramienta eVidens by Ilux) o de los consumos de suministros de forma sectorizada supone un volumen de información que podríamos considerar Big Data. Este análisis convenientemente estructurado nos da un punto de partida sólido y argumentado a la hora de plantear el programa de necesidades de edificios futuros o reformas o ampliaciones de existentes y evitar bochornosos resultados como este:

image_20161024_092344

La famosa demostración que todos conocemos de la red

Más allá de la intuición que brinda la experiencia y los pálpitos que cada cual tenga, dicho análisis ofrece fundamentos de peso para acompañar los argumentos tradicionales.

Las simulaciones a las que hace referencia el artículo sobre una propuesta de un edificio en cuanto al comportamiento del personal, su deambular o su actividad son muy interesantes. En el mundo de los videojuegos y cine 3D, es muy común dotar a cada miembro de una masa de “personas digitales” con una IA con un cierto sesgo “random” dentro de una horquilla común de comportamiento. En nuestro sector esto ayuda mucho a comprender la eficacia del diseño y se lleva haciendo desde hace tiempo, por ejemplo para simular tiempos de evacuación en espacios ocupados por grandes aforos como estadios o salas de conciertos.

Teniendo en consideración el punto de partida del primer párrafo y las observaciones obtenidas a partir de las simulaciones del segundo, podemos remitir el diseño primigenio en su formato más abstracto a alguno de los nuevos sistemas que de diseño generativo van apareciendo y desarrollándose.

La formidable cubierta del edificio que alberga la Filarmónica del Elba, diseñado por Herzog & de Meuron, fue desarrollada a partir de un concepto más o menos abstracto con un fin único pero determinado por una serie de condicionantes. Codificado todo ello en Dynamo, dejamos que el algoritmo itere (si existe “iterar” como verbo) las veces necesarias hasta dar con el diseño final, que entra dentro de lo esperado, pero convenientemente refinado para caber dentro del marco establecido por los condicionantes, los que sean. Pues considerando esos condicionantes, vengan de donde vengan, Big Data de la sensórica del primer párrafo, y diseños más o menos conceptuales o abstractos del programa de necesidades, las iteraciones del diseño generativo computacional acercarán dicho diseño a una fase mucho más refinada o quizá definitiva de la solución pretendida.

Image © Iwan Baan via ArchDaily

Image © Iwan Baan via ArchDaily

Este ejemplo de “autorouting” óptimo de tuberías en un entorno existente obtenido como “point cloud” tras una sesión LIDAR me parece excelente.
Y luego, si queremos, ya experimentaremos en realidad virtual un modelo digital funcional del resultado obtenido, por ejemplo del cálculo de trazado de tuberías que menciono, a ver si el personal de mantenimiento se escalabra contra una de ellas o no.

img_20160617_124328