Saltar al contenido

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

Primer ejercicio curso Unreal Engine para Arquitectura Interactiva en tiempo real

21 febrero, 2017

highresscreenshot00008

Como ya sucedió hace unos años con el Máster en BIM de 300 horas que realicé para ponerme firme con algo que hoy es imprescindible en mi flujo de trabajo, ha sido necesario pagarme un curso con un buen temario para buscar el hueco en mi agenda diaria y forzarme en una disciplina y rigor de otro modo imposible cuando cada día uno tiene infinidad de tareas productivas, comerciales o administrativas por llevar a cabo. Y deja las de aprendizaje de lado esperando mejores tiempos. Y es que lo que pica en el bolsillo al final te obliga.

Unity, Unreal Engine, Cryengine, Stingray y Lumberyard son motores de render en tiempo real comerciales con mejores o peores aspectos en cada una de las muchísimas facetas que un monstruo de este tipo debe contemplar. Sin ahondar más, y tras haber probado Unity unos años atrás y Stingray desde hace un año, considero Unreal Engine la opción ideal a día de hoy.

El rompecabezas que quiero montar como flujo de trabajo desde Revit a Unreal Engine y VR ya comienza a tener algunas de sus piezas colocadas y como un camino a medio pavimentar se pueden ver ya algunos avances, como este ejercicio propuesto por el profesor del curso, José Vicente Carratala, docente de Aula Interactiva, que es con quien estoy realizando este curso del que tan solo llevo 4 sesiones de media jornada. Nos ha pedido que colguemos en nuestra web o blog el resultado y aquí está. Por un lado capturas de pantalla, instantáneas que tanto se alejan del concepto render en la incomparable diferencia de tiempo entre unas y otras. Aquí no hay render, puesto que el render se hace de forma inmediata, a 60 por segundo, más o menos…. También hay que añadir que hay un proceso previo a todo esto que es el cálculo de iluminación que puede llegar a tardar bastante. Infinidad de parámetros y de fases preparatorias, en las que un modelado correcto y revisado, el proceso de «unwrapping» adecuado, el diseño de materiales PBR con incorporación de aplicaciones de terceros como Substance Designer o Painter, la adecuación de «blueprints», la colocación de «assets» bien prefabricados, LOD’s y un largo etcétera serán imprescindibles para llegar a esto.

Y aquí el «gameplay» también solicitado, un poco largo, demasiado tranquilo, pero que cumple con lo solicitado.

Testando interactivos VR con WebVR y Oculus Rift CV1

6 febrero, 2017

Los recorridos panorámicos interactivos basados en enlazar imágenes 360, realizados con el software Kolor Panotour Pro, tienen como objeto ser mostrados en web browsers, que serán ejecutados desde ordenadores de sobremesa, portátiles, tablets o móviles. Estos últimos pueden pasar además a modo VR haciendo uso de una Cardboard.

Sin embargo la posibilidad de que se puedan mostrar en VR desde un ordenador de sobremesa o un portáil, haciendo uso de unas HMD Oculus o Vive, pasa en primer lugar por la dependencia que el software de Kolor tiene del desarrollo de Krpano, y en segundo lugar por la adopción progresiva de los web browsers actuales de las API’s en javascript del standard WebVR.

Eso no parece tarea fácil: sólo Nightly (Mozilla VR) y Chromium (Chrome) son los navegadores que actualmente garantizan la ejecución de código WebVR y por tanto de disfrutar de este tipo de experiencias VR fuera del entorno Cardboard. Y dichos navegadores, en una eterna fase experimental, no acaban de madurar lo suficiente como para transferir a sus hermanos ampliamente adoptados esta funcionalidad. ¿Quizá WebGL2 o A-Frame hagan que la madurez deseada alcance su fin?

WebVR Nightly Oculus Test

El ejemplo que muestro se está ejecutando con Nightly en unas Oculus Rift CV1. El código reside en un servidor remoto al que se accede a través de una wifi con cierta saturación ese día. De ahí la aparición progresiva en mosaico de las imágenes 360. Por lo demás, la experiencia supera con creces en framerates y latencias a las vividas en móviles de gama alta.

La navegación es muy sencilla y sin touch alguno: gaze points, es decir, dirigir la mirada a puntos calientes preestablecidos que nos teletransportan a otro lugar en el entorno.

AEC: ¿mejor HTC Vive o Oculus Rift?

20 diciembre, 2016
HTC vs Oculus

He aquí unas Oculus DK2 con Leap Motion, unas HTC Vive con sus Touch controlers nativos y una Oculus Rift con sus Touch controlers recién lanzados al mercado el pasado 6 de Diciembre.

Para quien no quiera leerse todo el artículo, lo resumiré a continuación:

HTC

Pros:

  • mayor espacio de interactuación «room scale»
  • mejor tracking puesto que es full 360 (sin zonas oscuras en el seguimiento de los touch)
  • más cómodas para quienes llevamos gafas
  • mayor longitud de cable, sistema «Chaperone» para delimitar virtualmente en pantalla los límites «room scale» en el mundo real

Contras:

  • más aparatosas y menos «bonitas» que las Oculus CV1
  • los mandos son un poco grandes en comparación también a los de Oculus
  • vienen sin auriculares, que hay que conectar y desconectar cada vez

Oculus

Pros:

  • más ligeras y bonitas
  • quizá sea impresión mía, pero se ve muy ligeramente mejor calidad de pantalla
  • auriculares integrados
  • controles más ligeros, caen perfectamente en las manos y detectan la posición de los dedos, por lo que en las gafas podemos ver no sólo una réplica de los controles, si no también de las manos
  • sistema «Guardian» para delimitar virtualmente en pantalla los límites «room scale» en el mundo real, incluso delimitación irregular

Contras

  • experiencia «room scale» más pequeña y no 360 real hasta disponer de un tercer sensor y que tal opción deje de ser considerada «experimental», el seguimiento de los controlers puede perderse por ocultación en algunos casos
  • muy incómodas con ciertas monturas de gafas

Para montar un showroom corporativo personalmente y a día de hoy me decantaría por la solución de HTC. Para experienciar modelos AEC a mí me parece de peso fundamental no tener que orientar nuestra posición siempre hacia un lugar del mundo real (por los sensores de Oculus, digo), siendo HTC la opción que actualmente brinda esa posibilidad sin ninguna cortapisa. Además, puesto que nuestras intenciones van dirigidas a ser vividas por un público con una media de edad en la que el porcentaje de usuarios de gafas es alto, la solución de Oculus es verdaderamente incómoda (hay en el mercado terceros que facilitan interfaces más adecuadas que la original), de hecho yo uso dos pares de gafas, uno de ellos específico para las Oculus.

Showroom provisional

La solución de HTC me parece también más brillante en lo que a número de cables necesarios se refiere, ya que los sensores sólo precisan de una toma de corriente, no van conectados al PC, por tanto sólo hace falta la conexión HDMI y un USB.

Tinglado correspondiente a las Oculus DK2. en el modelo comercial la cosa se ha reducido a 3 USB en la versión con 2 sensores.

Tinglado correspondiente a las Oculus DK2. En el modelo comercial CV1 la cosa se ha reducido a 3 USB en la versión con 2 sensores.

Insisto en que todas estas impresiones las contextualizo en lo que a nuestros intereses se refieren, que no son los videojuegos aunque tengan tantas cosas en común.

Y ahora la versión larga

Más de un año ha pasado desde que puse mis manos en el DK2 de Oculus (en la parte superior de la imagen de la entrada) hasta haber completado esta trilogía con la llegada de los Oculus Touch (en la parte inferior derecha) la semana pasada.

Estas tres configuraciones de HMD se caracterizan por tener (o poder tener) un modo de interactuar con el espacio en el que nos podemos mover en el proyecto representado en cada una de las gafas.: teleportación, conseguida por medio de los controladores o de gestos, a gusto de quien diseñe la interface de usuario. Así nos comenzamos a alejar de la idea de videojuego con gamepad desde el minuto uno cuando pensamos en «gamificar» cualquier experiencia AEC.

Teleportándome alrededor de una abadía inglesa

Teleportándome alrededor de una abadía inglesa. El camino marcado en verde es donde me puedo posicionar desde donde estoy apuntando con el controlador.

En la DK2 que menciono instalé precisamente un dispositivo Leap Motion al poco de comprobar en varios proyectos que la navegación con un gamepad (la única forma que había hace un año de interactuar) suponía añadir más posibilidades de marearse (motion sickness). Cualquier movimiento en el espacio con un HMD que no lleve emparejado el mismo movimiento natural en la realidad puede acabar por marear al usuario neófito, especialmente en entornos que nuestro cerebro interpreta como movimiento natural el acto de avanzar andando. Se hicieron tests con varios usuarios en varias demos con clientes y el balance fue ese, que contrastado con estudios y pruebas de otros desarrolladores confirma tal impresión. Por tanto quede el gamepad para experiencias de volar o conducir.

La idea con Leap Motion era gestualizar con las manos la interactuación deseada en el entorno: apuntar con el índice dónde queremos ir y confirmar con el pulgar el lugar al que estamos apuntando. Quedó en idea, no descartada, porque al poco recibí las HTC Vive con sus controladores y el entusiamo la dejó aparcada. Sin ningún género de dudas la teleportación con cualquiera de los «Touch controlers» es el camino, porque a su vez, con la buena cantidad de botones que contienen nos dan un enorme abanico de posibilidades añadidas de interactuación.

htc-touch

Controles para HTC Vive, un poco «tochos», pero muy eficaces

oculus-touch

Oculus Touch: caen como un guante a medida, pequeños, cómodos, una maravilla, la verdad.

¿Cómo experienciar un proyecto de arquitectura o ingeniería en Realidad Virtual?

Parto de la base de que considero que hay tres estados o fases de experienciar un proyecto.

1.- Temprano: baja calidad en acabados e iluminación, poco refino en optimización de poligonización y por tanto riesgo de un framerate demasiado bajo. La ventaja es que hay software que se ocupa de ello, no se requieren conocimientos muy especiales. La misión de esta fase es la toma de decisiones mientras se desarrollan las ideas que vertebran el proyecto. Por ejemplo experienciarlo inmediatamente después de unos esbozos primarios en SkechUp o por Masas Conceptuales en Revit o FormIt 360 y tomar decisiones en tiempo real con el cliente. Anteproyecto.

2.- Medio: ya con acabados definidos y mejorados e iluminación, pero sin demasiado detalle, sin una optimización HQ y sin una iluminación global buena. También existe software para ello, pero no da lugar en mi opinión para un producto final depurado y comercial. Básico.

3.- Final o comercial: con mucho trabajo por hacer para definir texturas y materiales PBR para los acabados, para la retopologización de high a low poly del modelo, definición HQ de iluminación global, postprocesos, sistema de navegación e interactuación, variantes del modelo y un largo etc. Ejecución y ojalá «As Built».

Y además dicha experiencia podrá ser vivida por una sola persona abstraída en sus gafas, compartida de forma mixta si la ven varias personas en una pantalla además del usuario que la vive en VR, o compartida de forma inmersiva si son varias las personas que disponen de gafas y se monta un sistema semejante a Destinations de Valve (lo que nos llevaría a una VR corporativa)

Dicho lo cual, en cualquiera de sus tres fases y formas de ser experimentada, por la naturaleza de cualquier modelo AEC que deseamos vivir «al otro lado de las gafas» hemos de considerar que se nos debe brindar libertad total de mirar donde queramos, 360º, y que el sistema debe realizar un seguimiento de los tres dispositivos (HMD + 2 Controladores) sea cual sea nuestra postura y posición.

A continuación un ejemplo de lo que entiendo por fase temprana:

 

HTC Vive me parece la mejor opción, con independencia de otros factores donde Oculus vence con acierto y eficacia

Insisto en que no quiero desmerecer ni mucho menos cómo encaja la solución de Oculus en nuestro contexto profesional, pero al no ser una solución full 360, se ha de habilitar en los controladores un giro virtual a izquierda o derecha para mantener al usuario «mirando» hacia los dos sensores y que no les dé la espalda, momento crítico de darse puesto que los controladores quedarían en zona oscura y dejarían de ser percibidos por el sistema provocando en el usuario desconcierto.

Y en cualquiera de los dos casos añado que los HMD’s no están balanceados en lo que a su centro de gravedad se refiere. Me explico: todo el peso recae sobre la cara, los músculos faciales, más o menos aliviado por el sistema de cintas adaptable a cada usuario, insuficiente en evitar que tras una o dos horas «al otro lado» se produzca una fatiga en la cara, algo que nunca había experimentado y que es verdaderamente molesto.

Si cada vez vamos a pasar más tiempo abstraídos en otra realidad, sentados o de pie, es imprescindible velar por la comodidad del usuario, y no me refiero al momento de experienciar, que será más o menos breve pero siempre menor que el de la autoría. Tanto Unreal Engine desde hace 3 versiones, como la inminente de Unity tienen editores VR, algo de lo que hablaré en otra ocasión. En ese modo, en el que interactuamos con la herramienta y con nuestra creación con las gafas puestas, es previsible que pasaremos mucho tiempo y con todo el peso de las gafas, por ligero que sea sobre los músculos de la cara está garantizada la fatiga a partir de la primera hora. Es esta una oportunidad única de que cuando los HMD’s dejen de necesitar cables por haber logrado una madurez «latencia  cero» en los sistemas inalámbricos, tales dispositivos estén ubicados en la parte posterior del HMD para lograr el necesario alivio del peso sobre la cara.

AEC Realtime workflow (parte II)

14 diciembre, 2016
Avance de obra muelle

Avance de obra «tradicional» y no BIM de la ampliación de un muelle en un puerto insular

La imagen que abre esta entrada ilustra mi sentir actual en el estado de las cosas. Uno echa un vistazo al LinkedIn de vez en cuando y parece que todo el mundo está al último grito, pero, seamos realistas, la implantación de nuevas tecnologías, métodos y protocolos en la vida real de un estudio es un proceso bien largo, en mi opinión. E imagino que así debe ser para todos. Al menos cuando uno habla con unos y con otros, en producción se sigue con el lastre de convenciones y métodos anteriores que de una forma u otra siempre permiten terminar el trabajo con la calidad y plazo de costumbre. Todo el mundo tiene intenciones de migrar a BIM, de hacer puentes con una impresora 3D o de mostrar al cliente su proyecto en tiempo real, pero el día a día es bien diferente.

Esa imagen representa un momento en el tiempo de una planificación propuesta (Netai) para una constructora (Ferrovial) para una licitación pública. Ese momento está representado por un diagrama de Gantt, de MS Project:

Panorama típico por todos conocido para la elaboración de un 4D

Panorama típico (y lamentablemente cambiante) por todos conocido para la elaboración de un 4D

Obviando Syncro u otras opciones, que permiten mostrar 4D, 5D o nD estableciendo un enlace bien directo entre un proyecto modelizado en BIM y una planificación para tener como resultado unas imágenes, pero con una calidad a mi juicio bastante baja y poca flexibilidad, en la coctelera hay que meter AutoCAD, 3dsMax y Photoshop para poder entregar resultados con mayor calidad, y esto es lo que piden. Todo amanuense. El horizonte para el tiempo real HQ en estos casos lo veo bien lejos. Y como veremos más adelante, la misma situación se da entre un tiempo real más o menos automático y uno de calidad.

Una cosa son las intenciones y otra el plazo. Esta afirmación lleva pesando sobre mi carrera casi en cada proyecto. Teorizar es relativamente sencillo, pero poner en práctica el flujo de trabajo ideado con la vista puesta en la meta de la innovación no, en absoluto, cuando los plazos son tan breves como los que dan las administraciones públicas en sus licitaciones y con la documentación en el formato habitual en el que es recibida. La parte positiva de esta situación es que significa que uno tiene trabajo, que no para, la negativa es un sentimiento de frustración consecuencia de no poder subirse nunca de forma definitiva al tranvía… porque tiene bastante trabajo.

En la entrada anterior mencionaba que en el nuevo pantonero de servicios que un AEC CG Artist debe ofrecer hay nuevos colores y los más interesantes están en la gama del tiempo real: Pantalla 2D, Realidad Virtual y Realidad Aumentada.

Dejando a un lado que en la documentación entregada para las licitaciones no hay, ni creo que haya en el futuro, nada de esta gama de colores, tengo con frecuencia otro tipo de encargos, los que son para evaluar de forma temprana soluciones de arquitectura o ingeniería. Habitualmente se resuelven mediante una colección de imágenes de rápida factura que muestran de forma conceptual las diversas propuestas y que son comentadas y discutidas por mis clientes con los suyos para llegar al ansiado acuerdo. Diversas propuestas de Cesma Ingenieros:

Bien, en el largo camino para que la evaluación de proyectos AEC en tiempo real sea un hecho en mi oferta, y en la de cualquiera, y en el que me he propuesto como meta lograr un vector eficaz que comienza en BIM y termina en Unreal Engine o Unity como paradigma HQ de dicha evaluación, tengo dos primeros pasos dados como soluciones en mi cartera para poder realizar esta evaluación en fases tempranas y de forma rápida. Una se basa en imágenes reales o sintéticas precocinadas y la otra en el cálculo en tiempo real de un modelo 3D del proyecto, simplificado en topología y en acabados. Dividiré en dos entradas la explicación de cada uno de estos pasos hablando a continuación sobre el primero.

Experiencias basadas en fotografía y cinemáticas 360º

Se basa en conceptos ya conocidos y desarrollados desde hace más de 10 años pero que es ahora cuando está viviendo un renacimiento y época más o menos dorada debido a:

  • popularización de la fibra óptica y por tanto del aumento del ancho de banda
  • cámaras 360 económicas «one shot» o «stitch free» (perdón por los palabros)
  • cardboard
  • software para elaborar recorridos virtuales o telepresenciales que generen experiencias listas para visualizarse desde navegadores

La experiencia y navegabilidad de esta propuesta se basa en constelaciones de imágenes en proyección equirectangular, que cubren cada una de ellas toda una «esfera» imaginaria, 360º x 180º; vistas posibles desde un punto determinado del espacio real o imaginado. No confundir con Light Field ya que es otro concepto, complementario, del que hablaré en otra ocasión. La interconexión de todas ellas mediante puntos «calientes clicables» de una forma u otra permite la navegación desde una pantalla de ordenador o desde un móvil, tablet, etc. Como esa experiencia está codificada y alojada remotamente como si de una página web se tratara la ubicuidad está garantizada.

Autoría de una experiencia 360

Autoría de una experiencia 360

Telepresencia y cámaras 360

La imagen anterior muestra la «programación» visual de una experiencia basada en fotografías esféricas monoscópicas. Todas ellas fueron tomadas de forma instantánea y sin apenas edición con una cámara Ricoh Theta S como esta:

Cámara 360 Ricoh Theta S

Cámara 360 Ricoh Theta S

En el mundo de la fotografía 360 sabido es que hay dos formas de trabajar: con una buena cámara tradicional y un conjunto de accesorios como trípodes con cabezales especiales nodales para corregir paralajes, realizando 8, 12, 18, 24 o más fotografías para cada «fotosfera», «cosiéndolas» luego con un programa apropiado, lo que da lugar a resultados de muy alta calidad, ó con cámaras como esta que realizan el cosido de forma instantánea e internamente. En determinados entornos y circunstancias esta es la única solución porque la primera requiere de la presencia del fotógrafo durante largas sesiones donde o no es muy bien recibido o no hay tiempo para ello. Sí, vale, la calidad es menor, pero suficiente, por hoy.

Imagen esférica en proyección equirectangular

Imagen esférica en proyección equirectangular, en calidad 5K

Actualizado 15/12/2016: a día de hoy de sido informado, como el resto de usuarios de WordPress, que ya tienen habilitada la publicación de contenidos VR a partir de contenido 360º. por tanto a continuación pongo la misma foto en este formato, clicad, y disfrutad…. es el Refugio J.J. Blanc en el P.N. de Aigues Tortes

Con estos mimbres ya son unos cuantos los clientes que han solicitado experiencias telepresenciales, como por ejemplo esta visita de obra (Nomasarte):

Visita de obra

Visita de obra

o esta visita remota de una conocida pasarela sobre la M30 madrileña (Cesma Ingenieros):

Pasarela M30

Pasarela M30

Del mismo modo que las fotografías realizadas así permiten experienciar fácilmente un lugar de forma remota y ubicua, ¿porqué no hacer lo mismo mediante imágenes sintéticas de proyectos modelados en 3D para la obtención de infografías tradicionales? Actualmente casi cualquier software conocido permite obtener este tipo de proyecciones:

v008

v_16_puerta_del_mar

Algunos ejemplos propios de esto que cuento y que sí puedo publicar:

Puente Pachitea (Cesma Ingenieros)

Residuos sólidos Buenos Aires (Israel Alba)

Por lo que realizar recorridos virtuales 360º de espacios proyectados es una opción muy popular entre algunos de mis clientes. Reúne varias características que son consideradas positivas:

  • Añade poco plazo y coste al de la obtención de imágenes o infografías tradicionales.
  • Interactividad sencilla e intuitiva, y navegabilidad garantizada cualquiera que sea la plataforma de visualización.
  • Escasos requerimientos de la plataforma de visualización ya que no se realiza cálculo de tiempo real, todo ha sido ya calculado previamente.

Este último punto es importante y en él incidiré en posteriores entradas, pero una de las consecuencias que tiene es que se puede experienciar el proyecto en tablets y en móviles, haciendo una primera incursión en realidad virtual a través de… la Cardboard:

Ejemplo de Cardboard, ligeramente "premium"

Ejemplo de Cardboard, ligeramente «premium»

Este «producto» lleva un tiempo en el mercado y ha de ser conocido por casi todo el mundo como solución económica y universal de Google para quienes no tengan/quieran un móvil Samsung y una Gear VR o esperar por un móvil Pixel y un dispositivo Daydream, de Google también.

El mismo enlace (cualquiera de los anteriores) a un recorrido virtual 360º tiene la posibilidad de activar la visión a través de móvil+cardboard y así experimentar la navegabilidad y el recorrido de una forma más inmersiva e íntima.

NVIDIA ha hecho posible, a través de la integración de su tecnología Ansel a partir de la versión 4.14 de Unreal Engine, obtener instantáneas 360º de cualquier entorno ya precalculado evitando el render «tradicional» 360, pero de esto hablaré en otra entrada más adelante.

Como también la próxima entrada hablaré de mi experiencia con sistemas de tiempo real temprano como Autodesk Live y Iris VR Prospect

AEC Realtime workflow (parte I)

1 diciembre, 2016

sgionyx

O sobre el inevitable viaje hacia el tiempo real de los CGArtists en Infoarquitectura.

Corrían los años 90, yo ya enseñaba a usar AutoCAD a través de un ATC en Dragados y tuve oportunidad de iniciar relaciones profesionales con quienes luego serían considerados pioneros en España en el tiempo real. Poco duraron aquí puesto que cruzaron el charco para ir a trabajar a Estados Unidos, donde eran más apreciados, esa costumbre tan nuestra. Por ellos entendí que aquella época de Paradigm Multigen OpenFlight, Silicon Graphics Onyx Infinite Reality, VRML, Evans & Sutherland y expresiones como «frustum culling» era una especie de «arroz con cosas» tan apasionante como misteriosa donde no había estándares específicos definitivos y cualquier intento de valorar el hacer algo en tiempo real pasaba por gastarse una verdadera millonada para conseguir al fin cosas como esta:

 

La imagen que abre este artículo es una versión de estos supercomputadores, los Onyx Infinite Reality, grandes como dos frigoríficos, que eran observados con veneración mística entonces como el paradigma y canon de la potencia ideal y suprema para aspirar a algo en tiempo real. Sólo al alcance de simuladores militares y de aviación comercial y poco más. «Eso» que llamábamos tiempo real entonces poco tiene que ver con lo que consigue cualquier videojuego Triple A de hoy en día, sin ir más lejos, un GTA. Por lo que hemos de entender que una videoconsola de 2016 supera de largo todo aquello.

Y todo este preámbulo para afirmar que considero este como el año cero en la democratización del tiempo real para «experienciar» proyectos de arquitectura e ingeniería con calidad. Ahora sí. Tres son las razones que valoro para poder hacer esta afirmación:

1.- La potencia gráfica de las arquitecturas Nvidia GTX y AMD Radeon, al alcance de cualquier bolsillo.

2.- La madurez de un conjunto de herramientas para el modelado BIM y el modelado 3D «tradicional», los procesos de texturado y acabados PBR y finalmente los motores de tiempo real comerciales y asequibles

3.- La interiorización del flujo de trabajo cuyo origen es un proyecto realizado en BIM y el final un «front end» que permite visualizar de forma no lineal, con o sin «headset» de realidad virtual, el proyecto planteado con una calidad igual o superior a la de los videos de infoarquitectura «tradicional».

4.- El advenimiento comercial de los dispositivos de realidad virtual y aumentada, que no sirven para nada sin todo lo mencionado en los tres puntos anteriores, pero que han hecho sin pretenderlo una labor de evangelización social del concepto tiempo real.

Estos cuatro hechos han permitido dar un salto como nunca antes se había dado en relación a lo que se podía hacer con aquellas máquinas de color violeta.

Lo que tiene como consecuencia que el propio trabajo de AEC CGArtist está cambiando de forma acelerada, como nunca antes. Las opciones que han de formar parte de su oferta ya no son «sólo» infografías, videos y avances de obra, si no experiencias en tiempo real, navegables, intuitivas en su navegación y de máxima calidad y adaptadas al cliente en experiencia de usuario (UX) y plataformas de uso. Tanta calidad que ante determinadas circunstancias y proyectos ya no se valoraría dejar «varias imágenes o una secuencia para que se calculen durante la noche» en el estudio con los procesos de render tradicionales, si no migrar todo el proyecto a Unreal Engine o Unity y hacer en tiempo real instantáneas con Nvidia Ansel o cinemáticas con Matinee, por mencionar algunas opciones. Si bien no van a caer en desuso motores de render con un extensísimo parque asentado como Vray, o últimamente Corona u Octane, sí que van a quedar como soluciones para trabajos a muy corto plazo, dejando paso al tiempo real para proyectos en los que haya más margen, más plazo. Como muestra de lo que es posible lograr con Unity, CryEngine o Unreal Engine pongo aquí este enlace de Unreal Paris:

Aunque tiene ya casi dos años, equivale salvando las distancias, a lo que fue aquel mítico The Third & the Seventh del amigo Alex Roman (con quien  trabajé y aprendí en el pleistoceno) en el mundo de la infoarquitectura «tradicional».

Sin embargo el flujo de trabajo que menciono en el punto 3 no es nada fácil de establecer y asentar a corto plazo por varias razones que trataré en posteriores artículos. Se compone de muchos pequeños procesos enlazados convenientemente. Y tocan tanto las disciplinas de arquitectura e ingeniería como videojuegos.

Un ejemplo: un pequeño proceso imprescindible es el llamado «Unwrapping» sin el cual nada que se lleve a un motor de render «realtime» tendrá una calidad decente tras el proceso de «backeado» de iluminación. Es un proceso propio del mundo de los videojuegos y que no se utiliza prácticamente nunca en el de infoarquitectura y que tiene un aspecto así:

unwrapuvws

Algo intimidante para quienes arreamos por la calle de enmedio con plazos muy justos para terminar un 4D o unas imágenes de evaluación temprana de diseño. Muchos no lo han visto nunca.

Pues como este muchos más.  Y en muchos programas diferentes. Pero tras ellos el resultado es tan bueno como el mejor de los renders tradicionales. Y en tiempo real.

Para quienes no quieran complicarse la vida demasiado hay otras soluciones que yo considero de evaluación temprana como Autodesk Showcase, Iris Prospect o Autodesk Live (estos dos últimos para VR) o con una calidad media como Enscape o Lumion. Todas son muy útiles, cada una en su contexto, pero en la actualidad estoy convencido de que están aún muy lejos de alcanzar la calidad de la que hablo. Y afortunadamente esto nos da esperanzas a quienes vivimos de ello, para poderlo seguir haciendo.

Google Earth VR

20 noviembre, 2016

20161118141939_1

Quienes trabajamos por cuenta propia no nos queda más remedio que, para tratar de estar en la cresta de la ola y no perder competitividad, dedicar mucho, mucho tiempo a formación y reciclaje de conocimientos, lectura dedicada de repositorios de noticias y revisión contínua en redes sociales de canales o cuentas interesantes para nuestros propósitos, tanto de fabricantes como de gurús.

Entre todas las de la semana pasada, que fue verdaderamente intensa en innovación relacionada con realidad virtual y aumentada, las que mas llamaron mi atención fue la publicación el jueves de Google Earth VR, la integración de la tecnología de nVIDIA Ansel en la nueva versión 4.14 de Unreal Engine y el primer móvil con cámara 360 (ya estaban tardando), entre otras (el kit para convertir la HTC Vive en un dispositivo inalámbrico también lo es).

No tardé mucho en buscarme un hueco para instalar a través de Steam Google Earth VR, y menos aún en hacer los primeros tests desde la HTC Vive. Lamentablemente no hay versión aún para Oculus Rift, probablemente porque la interacción se realiza a través de los «touch», algo que se empezará a enviar al público a partir del 6 de diciembre.

Google Earth ya dispone de una amplia base de datos global en 3D desde hace cierto tiempo, me refiero a ciudades, con sus edificios, parques, árboles, monumentos y patrimonio en general, todo ello obtenido conjugando técnicas de fotogrametría y fotografía satelital. Todo ello encima de la topografía existente desde hace aún más tiempo con mayor o menor detalle según qué zona.

Lo primero que hice nada más colocarme las gafas y superar un ligero entrenamiento que hace de la experiencia algo muy intuitivo (excelente Ux el que han logrado) fue dirigirme hacia la Plaza Mayor de Madrid. La sensación de volar, de desplazarse con total libertad por toda la ciudad hasta encontrar el lugar elegido, de poner pies en la tierra y sentirse un gigante caminando por las calles es verdaderamente espectacular, una experiencia completamente nueva, sencilla de dirigir y sobrecogedora en sus resultados. Puerta del Sol, Cibeles, Gran Vía, Palacio Real…. Ya lo habíamos visto en 2D, pantalla, pero esto es otra historia, completamente.

Aproveché una visita en mi estudio para testar la aplicación en una segunda persona. Es una pena que no hiciera foto cuando se quitó las gafas o grabara en video los comentarios, creo que sensacional es un adjetivo que se queda corto si interpreto sus expresiones. Puesto que es de Barcelona, no tardamos en dirigirnos hacia allí.

img_20161119_111850 img-20161119-wa0016

Grandes, esta gente de Google. Con Tilt Brush lo bordaron al prestarnos la posibilidad de pintar en 3D en el espacio. Pero esto, teniendo una aplicación menos artística, es igual de impresionante o más. Su aplicación en AEC es clara y directa. Poder contemplar en 3D de forma inmersiva el lugar donde irá un puente o un edificio ya es posible. Ahora toca esperar que poco a poco todas las ciudades y poblaciones importantes estén actualizadas en 3D. Y añadir prestaciones sociales para poder interactuar varias personas en el mismo lugar de GE VR desde distintos lugares físicos, una especie de Webex de Cisco pero en versión Google Earth. ¿Porqué no?

Adobe y Autodesk: dos puntos de vista diferentes y casi antagonistas

21 octubre, 2016

Llevo relacionado con Autodesk desde 1988, cuando AutoCAD andaba por la versión 2.5 y venía en 10 floppys de 5 1/4″ que costaba una eternidad arrancar en MS/DOS. Quienes no hayan nacido antes de 1970 no saben de qué hablo. La matriz no tenía representación en España y tratábamos directamente con la delegación en Basilea, Suiza, un tal Jean Claude Nidegger. Formé parte de el primer ATC empresarial (Authorized Training Center) en Madrid y mantuve una estrecha relación durante los 6 años que trabajé como instructor de AutoCAD y 3dStudio.

Valga el preámbulo por dos razones: le tengo cariño a la marca y llevo usando sus productos desde entonces. Me creo con el derecho también y por ello a criticar lo que no me parece de recibo.

Como autónomo que lleva capeando temporales (dos crisis, la de 1993 y esta que no acaba) y como tantos otros, la capacidad de desembolso para adquirir licencias de uso no es la misma que la de corporaciones, multinacionales y demás fauna con la que convivimos en este «Ecosistema». 3dsMax 4, 3dsMax 6, etc, licencias y dongles que aún pululan por los estantes de mi estudio, recuerdo de lo que uno ha podido ir adquiriendo al paso del tiempo. Recientemente y en previsión de unos cuantos encargos he «alquilado» el derecho de uso de una Building Design Suite Premium 2017, lo que ahora es una «Collection», durante un año por el «módico» precio de más de 3000 euros. En mi estudio sólo estoy yo. Y vence el año que viene en Agosto. Las ofertas actuales de las Collections no son mucho más atractivas. Al menos para los pequeñitos. Que somos muchos.

autodesk_oferta

Un par de estudios de arquitectura, clientes míos, ya andan pensando en ir implantando BIM, seguramente haciendo uso de Revit, pero están asustados del precio y formato de uso: licencia de uso anual. Valoran otras alternativas… Una multinacional, también clientes, y con capacidad de solvencia, han adquirido el derecho de uso por un año de un Revit LT, al considerar que el precio de su hermano mayor es desorbitado.

Al contrastar los planes de uso de Autodesk con los de Adobe, con productos complementarios pero de mercados claramente diferentes, y no por ello productos menos complejos o complicados de crear y mantener, la diferencia es sobresaliente, a favor de Adobe.

adobe_oferta

Para empezar tienen planes diferenciados según sean individuos, pequeños estudios o empresas. Coinciden en el apoyo a la comunidad estudiante y docente (el de Autodesk excelente por lo que he podido comprobar).

Y dentro de los planes para individuos o profesionales, el de Adobe es claramente favorable, diría que excelente, no es posible ser ajeno a él si se van a usar sus productos profesionalmente. Todo lo contrario de Autodesk, cuyos precios favorecen otras intenciones menos virtuosas.

Acabo manifestando así mi descontento con la casa con la que durante tanto tiempo he estado unido profesionalmente y lanzando al aire la pregunta: ¿porqué hay semejante diferencia de precios y de actitudes o facilidades hacia el profesional independiente?