Realidad Virtual inalámbrica de alto rendimiento
Llegar a esto, a visitar a un cliente con un portátil, unas Oculus Quest y mostrar nuestro proyecto en VR de alta calidad de forma inalámbrica, sin sensores, sin cables, sin configuraciones complicadas, a plena potencia, sin compilar APKs para Android con sus limitaciones. VR nativa Win. Con gráficas RTX.
Potencia a raudales: una workstation HP Zbook con una gráfica Quadro P4500 junto a un viejo MSI con una GTX980Ti, unas Quest y un repetidor Wifi 5G. Es todo lo que necesito. Y algo de software. Aquí os lo cuento.
Antecedentes: primera generación de VR
Este artículo lleva desarrollándose en mi cabeza desde hace dos o tres meses, pero he tenido que madurar la forma de hacerlo y sobre todo constatar que el final del viaje sea fiable y esté listo en su forma comercial, B2B.
Todo comienza cuando en 2015 mi sueño juvenil de materializar el concepto de «realidad virtual» deja de ser virtual (libros, cómics, bla, bla) y se hace real a través de unas gafas Oculus DK2, el kit de desarrollo de la fase pre-Facebook de Palmer Luckey y su compañía Oculus. Simultáneamente HTC también estaba llevando a cabo el desarrollo de su alternativa.
Primera generación de soluciones comerciales VR
Hago el inciso de que como especialista de visualización AEC con 23 años de carrera vengo considerando los renders tradicionales y las animaciones o visitas guiadas herramientas del pasado, puesto que el avance en computación gráfica y las sinergias del sector AEC con el sector de videojuegos y VFX hacen converger todo hacia el tiempo real y render online con latencias muy bajas.
Ambos casos, Oculus y HTC, son soluciones de seis grados de libertad, es decir, realidad virtual plena, con detección de posicionamiento absoluto y orientación de las gafas en el espacio, nada que ver a soluciones de tres grados de libertad tipo Cardboard y demás. Son soluciones claramente orientadas a mundos virtuales 3D plenos, no a recorridos virtuales basados en imágenes 360 o videos 360 aunque sean estereoscópicos.
Dando unos resultados muy precisos en el posicionamiento requerido, esta primera generación de dispositivos VR (Outside-In «tracking») tienen como primera desventaja que hacen uso de otros dispositivos añadidos a la configuración: sensores de luz infraroja (los sensores de Oculus) o emisores de luz estructurada (los «lighthouses» de HTC).
Instalación estacionaria en showroom
Para instalaciones estacionarias, llamémosle «showroom», esto en principio no es ningún problema: el «setup» más o menos complicado que hay que hacer al comienzo de su uso queda registrado para «siempre». El problema se manifiesta cuando hay que ir a las instalaciones de un cliente en lugar de que venga a las nuestras. El cliente tiene ciertas reticencias para montar el tinglado en una sala donde quizá no hay espacio o quizá no hay el tiempo necesario para el setup. Añadamos el hecho de que el equipaje es un bulto importante, que si vamos en coche al cliente no es demasiado negativo, pero si vamos en avión, siempre con prisas, y evitamos facturar, con este flujo de trabajo no es posible. Esto es suficiente no ya para que haya detectado reticencias, directamente rechazo.
Tenemos un segundo hándicap: el cable que une gafas al ordenador que procesa. Alimentación y señal. Por experiencia puedo afirmar que los novatos se lían con el cable, lo pisan, se enrollan y quienes sufren de impericia con la tecnología necesitan de una mano amiga. Si además se sufre de algún patrón Asperger y se rehúsa del contacto físico de la mano amiga, la experiencia no es muy premium.
Todo esto no quita que siga considerando el seguimiento Outside-In de extraordinaria precisión y que así considere también soluciones como Valve Index, Varjo o Pimax, todas basadas en SteamVR Base Stations 2.0 como candidatas para aconsejar a cualquier cliente que me pregunte por una solución estacionaria puesto que la calidad que ofrecen en visualización (densidad de pixel, no «screen-door efffect», «mura», frecuencia Hz, trackeo de ojos, bla, bla…) es la más alta. El asunto del cable y el lío se resuelve de varias formas.
Fórmulas de fortuna, más o menos ingeniosas para suspender el cable: correa de perro y lámpara de Ikea.
VR de segunda generación
Sirviendo lo leído hasta aquí como preámbulo, y no perdiendo el objetivo inicial de ofrecer al cliente una solución compacta para tener movilidad, sencilla, rápida de instalar, ligera y de calidad para poder visitar a sus clientes, desde aquello a los años 2018 y 2019 nos encontramos que los sistemas de reconocimiento de imagen y las unidades magnético inerciales de la telefonía móvil (IMU) han avanzado lo suficiente y tanto como para comenzar a pensar en una VR sin sensores externos, en unos casos autónoma, en otros cableada a un ordenador.
Aparece HTC con Focus, una solución especialmente pensada para el mercado asiático, aquí tuvo poca fortuna. Adquirí un kit de desarrollo, pero quedó bastante desamparado por falta soporte, más que un SDK para UE4 poco documentado. Comercialmente noté poco esfuerzo. Quizá también no le dediqué demasiado tiempo. Fue el primer modelo que tuve autónomo y 6DOF (seis grados de libertad) y funcionaba, claro que sí, si bien lleva un sólo controlador y no se hace seguimiento de él si no que se intuye su posicionamiento por IMU. Actualmente lo enfocan al mundo de los negocios y no le he prestado más atención.
También llega Oculus con su solución Go, una propuesta 3DOF, no detecta movimiento, sólo orientación, dirigida al entretenimiento, museos, exposiciones y demás. Experiencias 360 y 180, retransmisiones deportivas (Copa Lavert, muy buena), estar sentado en el sofá y ver cualquier contenido preparado para VR. También un sólo controlador y seguimiento por IMU.
Primeras propuestas autónomas de calidad. Segunda generación de VR. Posicionamiento Inside-Out.
Pero no es hasta que Oculus da un paso mayor, que considero trascendental en la segunda generación de VR, al proponer sus Oculus Quest y Oculus Rift S cuando uno toma conciencia de la evolución que vivimos en aquel momento. Seguimiento Inside-Out, y en las Quest, gafas autónomas, encuentro una calidad excelente por el precio y el momento en que son lanzadas. Dos mandos de los que se hace seguimiento óptico. Yo era escéptico con la tecnología Inside-Out, consideraba que no podía estar tan avanzada la resolución del posicionamiento a partir de análisis de imagen e IMU, pero sí, son muy precisas. Y repito, son autónomas, no necesitan ordenador, no necesitan cable. Luego vuelvo con ellas.
También HTC responde con su gama Cosmos. Inside-out basada en PC, como las Rift S y con dos «motion controller» también.
Cabe añadir la solución o plataforma Windows MR, con propuestas como la de HP con Reverb, cuya calidad visual es sobresaliente, confirman esta segunda generación de VR en su conjunto, libre de sensores, ideales para viaje. Además, al caso de HP se suma su propuesta autónoma de alto rendimiento en forma de «mochila-ordenador». No sé cuál es el límite en espacio recorrido caminando con unas Reverb conectadas a una mochila, pero sé que es muy grande a tenor de algunos experimentos. Al ser ISV Partner de HP he tenido la fortuna de testar para un proyecto un equipo completo así y encuentro que son una solución excelente.
La solución Omen de HP. Muy potente como solución autónoma. Y además el portátil funciona también de manera estacionaria en una base de sobremesa.
Decía de Oculus Quest que son unas gafas muy versátiles, y quiero añadir que reconocen diversos setups según la habitación en la que uno se halle si ya ha pasado antes por ella, que son precisas, que la disposición periférica de las cámaras hacen que el seguimiento de los mandos no se pierda casi nunca, pero…, siempre el pero: son un smartphone de gama alta sin capacidad de telefonía. Su capacidad de computación autónoma se basa en un chip Snapdragon 835, con bastante potencia gráfica y de proceso en un móvil, pero no la suficiente para una VR de alta calidad. Además su frecuencia máxima de pantalla es de 72 Hz, suficientes, pero 18 por debajo de los sugeridos siempre 90 Hz.
Un juego extraordinario en calidad gráfica como Robo Recall en las Oculus Rift, tuvo que ser repensado casi en su totalidad para portarlo a Quest.
Las ya maduras Oculus Rift a la izquierda, las Oculus Quest a la derecha
Mi sector, como he dicho, es AEC y el flujo de trabajo es normalmente muy rápido en la respuesta que he de dar. No hay, que yo sepa, aplicaciones de visualización AEC, que es a lo que vamos, que compilen de forma directa para Quest. La única solución pasa por editores de motores de videojuego como Unreal. No hay una solución «Oneclick» como la que uso de forma cotidiana, Enscape, que genera ejecutables para ser disparados desde cualquier ordenador con relativa potencia, también hacia unas gafas VR de forma instantánea. No hay APKs, el formato Android de aplicación, que es lo que son, no lo olvidemos, unas Quest.
Sí que hay aplicaciones nativas para Quest de revisión de modelos BIM en la nube de forma colaborativa, muy interesantes como InsiteVR, IrisVR Prospect, The Wild, y otros que no recuerdo ahora, cuya calidad gráfica es menor que lo que se pueda obtener desde Unreal, pero suficiente para su objetivo de revisión conceptual.
Pantallazo de una sesión de un modelo en InsiteVR
Por tanto, Opción 1 para desarrollar contenido de visualización para Quest: Unreal (o el motor de videojuego que sea) y el conjunto de añadidos necesarios de Android. Builds complicados y sensibles al SDK de Android que se esté utilizando, shaders limitados, cálculo y almacenamiento limitados. Calidad visual regular, pero suficiente en muchos casos.
Calidad gráfica obtenida en un build nativo de Quest, una APK de Android hecha en UnrealEngine. Es un test en el conocido VR template. Iluminación precalculada.
En Octubre de 2018 la multinacional Abbott llevó al congreso LabClin un stand con una zona VR que preparamos ex-profeso. El contenido que mostramos se preparó en Unreal Engine para unas HTC Vive Pro. A tenor por lo comentado, la experiencia de tres días tuvo bastante éxito, más de 50 profesionales del sector experienciaron un laboratorio de análisis clínicos hospitalarios en VR con diversas mecánicas de interacción, quizá demasiadas. Y nosotros aprendimos mucho de ellos, de sus reacciones y de un setup en un entorno que no se mostró como el ideal: cristales, reflejos e iluminación LED poco propicia. Hubo y hay que cambiar algunas cosas.
El contenido tardó en desarrollarse un par de semanas, y eso que ya teníamos una librería al 50% tanto de actores como de «shaders». Hoy no llevaría aquellas gafas, llevaría unas Quest, pero querría la calidad gráfica que tuve en aquél evento en las Vive a través de una experiencia hecha en UnrealEngine. ¿Es posible combinar el conjunto de bonanzas de unas Quest con la calidad gráfica del renderizado en un ordenador de altas prestaciones? En aquel momento NO. Por otro lado una cosa es la calidad gráfica que yo quiera y otra es con la que se conforme un cliente neófito en VR, con poca base crítica o incluso pragmática, a veces no es necesaria una calificación triple A, me han convencido.
Las gafas Bowie
En noviembre de 2019, en el evento Oculus Connect se presenta de forma oficial algo que se venía cociendo durante el verano: Oculus Link. Conectar por cable USB las Oculus Quest a un ordenador y convertirlas en unas Rift S. Un cable un tanto especial, eso sí.
Anker Powerline USB-C to USB3.0 – Model: A8167011 (3 m.)
El cálculo se realiza en el ordenador, como en cualquier modelo de la primera generación con total calidad, incluso con bakeado de iluminación premium, ya que no hay límite de memoria ni de proceso. Podemos hacer cálculos previos de iluminación con soluciones de muchos procesadores como la de la foto o con soluciones de cálculo en la nube como la de SimpleCloud o EC2 de AWS. A fin de cuentas se crea esta posibilidad para poder jugar con cualquier juego que lo haga en una Rift.
Es decir builds convencionales. La Quest queda convertida así en una propuesta doblemente versátil, de segunda generación y sin sensores. Tanto que se ha cuestionado la necesidad de Rift S. Son unas gafas camaleónicas.
Sin sensores y sin cable: el santo grial de la VR
Seguimos teniendo cable. Ya nos hemos deshecho de los sensores. Pero para esto nos quedamos con unas Rift S, con unas HP Reverb o con unas Cosmos.
Ya hace tiempo HTC proponía una solución inalámbrica con su adaptador, es decir, el viaje contrario, convertir unas gafas de cable a unas autónomas. Pero es que el adaptador es un poco…
Aparatoso
También había soluciones de terceros como TPCast pero requerían de una tarjeta especial que no se podía poner en ordenadores portátiles. Y seguíamos con sensores en ambos casos.
La solución de TPCast, algo menos aparatosa
Por último las gafas Vive Cosmos también disponen de la posibilidad de convertirlas en inalámbricas a través de el mismo adaptador, pero sigue siendo necesario un slot PCIe para el transmisor Gigabit y eso sólo lo hay en ordenadores de sobremesa.
Las gafas Cosmos, sin sensores, inalámbricas, pero necesario un slot PCIe
Así la idea de unas gafas 6DOF autónomas, con controladores con buen seguimiento, y con contenido retransmitido de forma inalámbrica desde un portátil se desvanece, aunque hay esperanzas, ya que John Carmack en el mismo Oculus Connect sugería que la posibilidad de conectar unas Quest via Wifi a un ordenador que haga el trabajo sucio es certera pero de lanzamiento indefinido en el tiempo.
El truco del Wifi 5GHz
Desde los foros de usuarios de Enscape un día el usuario annevanzwol comenta que más allá de ALVR, Virtual Desktop, un viejo desarrollo de los comienzos de la VR actual para ver/trabajar en nuestro ordenador desde unas gafas, ha acabado siendo tan refinado y depurado que es capaz de enviar los frames a la velocidad necesaria a través de Wifi 5G a la aplicación Virtual Desktop de las Quest como para considerar olvidarnos del cable para siempre. Es decir, que funciona como una interfaz entre Quest y la aplicación VR que queramos ejecutar, interceptando la búsqueda directa de unas gafas conectadas y reenviando y recibiendo datos de forma inalámbrica.
Yo cuando leo esto me doy cuenta de que por fin hay un rayo de esperanza. Compro licencia, instalo router 5GHz y…¡funciona!
Opción 2: Virtual Desktop y WiFi 5G. Hacemos los builds de Unreal normales y corrientes para Windows. Además, funciona Enscape cuando cambiamos a modo VR. Todo se ejecuta en el PC o portátil y se retransmite via Wifi a las Quest.
Tan simple como:
- El ordenador host conectado por cable de red a uno de los nuevos router 5GHz (imprescindible).
- Las Quest conectadas a la misma red.
- Arrancar la aplicación VR desde las propias Quest y el retransmisor en el host.
En realidad no lo es tanto, ya que también hay que (si no lo está):
- Instalar Oculus Setup sin configurar ningunas gafas, no es necesario. Sí hace falta cuenta en Oculus.
- Instalar Steam. Hace falta cuenta en Steam.
- Instalar SteamVR.
- Instalar Virtual Desktop Streamer, que a su vez puede instalar, si no lo están, varios «redistributables C++» y reinicia un par de veces. Este preguntará por el usuario en de Oculus. Por eso hay que tenerlo.
- Instalar SideQuest que es libre.
En las gafas:
- Instalar Virtual Desktop versión Sideload con SideQuest.
Esto es debido a que a Facebook no le gustan estas chulerías, les han adelantado en su publicación de la opción inalámbrica y además le torean quienes publican juegos para Quest sin pasar por la tienda.
¿Y si tienes que ir a un cliente y este no tiene Wifi 5GHz, bla, bla? Bueno, eso es un poco más complejo, puesto que Virtual Desktop comprueba la licencia en internet cada vez que se arranca, y si no tiene acceso, pues no arranca.
Solución: llévate tu propia Wifi 5GHz. Accede a internet para la comprobación de licencia a través de los datos de tu móvil o tablet.
TPLink AC1750 WiFi range extender. Model RE455. La doble IP tiene sentido ya que en el estudio tiene esa IP fija, y en visita tiene esa otra. Para acceder a la configuración debemos hacerlo por esa IP según a qué red se haya conectado. También podemos configurar desde el móvil.
Es decir, que convertimos nuestro móvil en puerta de acceso y con este aparatito creamos una red Wifi 5GHz en cualquier lugar. El portátil, conectado como se puede ver por cable. Autonomía de verdad.
Veamos el procedimiento de uso. Arrancamos Virtual Desktop Streamer en el ordenador. Los parámetros por defecto funcionan.
La primera vez hay que dar el nombre de usuario de Oculus
Es imprescindible que las versiones del Streamer y la del Virtual Desktop en Quest sean las mismas, cuidado.
Ni que decir tiene que las Quest deben estar configuradas para admitir aplicaciones de origen desconocido y en «developer mode» para lo cual puede ser necesario estar registra docomo desarrollador en Oculus (tampoco se podría, si no, hacer compilaciones desde Unreal y enviarlas a las Quest, por ejemplo). Aquí el proceso.
Se sugiere instalar el Launcher y yo lo hice, pero en posteriores ocasiones he podido arrancar Virtual Desktop desde la biblioteca. Viene bien tenerlo para arrancar Apks hechas en Unreal.
En ejecución y comprobada la licencia vemos esto:
El host que va a retrasmitir ha sido reconocido y hemos conectado al estar ambos en la misma red. La pantalla nos indica en la parte inferior el modelo de gafas conectadas, versión de VD y varios indicadores de prestaciones. Importante en la parte superior el tipo de Wifi y el ancho de banda detectado, así como la IP de las gafas.
Desde aquí podríamos manejar sin ningún problema nuestro PC. Algo relativamente convencional y para lo que fue creado este programa.
Lo mandos tienen diversas funciones que es importante tener en cuenta. Por ejemplo el botón del izquierdo «Options» pulsado una vez es muy importante ya que muestra esta interfaz si ya estamos con la pantalla de nuestro ordenador, pero si está corriendo SteamVR hay que pulsarlo dos veces seguidas, ya que con la primera aparecen las opciones de SteamVR. Son cosas que hay que ir probando e interiorizando.
La pestaña Settings muestra un montón de opciones que mejorarán la experiencia según la calidad de nuestra red 5G y la potencia del ordenador.
Todas las capturas anteriores fueron realizadas con SteamVR encendido, por lo que no puedo mostraros un botón muy importante, que no aparece, y es el de «Launch SteamVR«, cuyo espacio ocupa ahora el que dice «Exit SteamVR«.
Antes de arrancar cualquier aplicación VR hemos de enceder SteamVR desde este botón, desde las gafas. Si no, es posible que VD no haga su función de interfaz. Cuando arrancamos SteamVR desde las gafas es posible que aparezca el Home de esta aplicación, ese entorno familiar desde el que lanzamos juegos. Tendremos que volver a Virtual Desktop para poder arrancar nuestra app.
Con SteamVR en marcha ya podemos buscar y arrancar nuestra aplicación VR desde las gafas, e incluso alternar entre estar en una aplicación VR que se esté ejecutando o ver el escritorio de nuestro PC con los botones «Switch to VR» y «Switch to Desktop», botones que aparecen sólo cuando SteamVR está en marcha.
He constatado que precisamente la aplicación VR de la que hablaba que presenté con Abbott en el LabClin de 2018 funciona perfectamente aún siendo pensada para Vive. El refresco de 72 Hz no se nota demasiado pese a que fue diseñada para correr a 90 Hz.
Tiene exactamente la misma calidad. Interpreta correctamente la altura sobre el suelo. El mapeo de botones de los controllers funciona perfectamente y los triggers de la aplicación responden. ¡Es sensacional!
SteamVR «se cree» que tiene conectadas unas Quest, los iconos son esos…
Por supuesto esto no era para mí suficiente. Utilizo a diario Revit y Enscape y quiero comprobar si va a ser igualmente fácil llevar un EXE de Enscape a Quest. Arranco el ejecutable que comienza siempre en modo desktop.
Desde el propio Virtual Desktop cambio a realidad virtual en la app:
Ajusto algunos parámetros
Y a visitar el laboratorio
He de decir que Enscape no se comporta con la misma fluidez que un ejecutable nativo Win de Unreal en el mismas circunstancias de gráfica y procesador. También es cierto que el ejecutable que menciono tiene la luz precalculada en su mayor parte y está bastante aligerado de polígonos, mientras que Enscape NO precalcula GI ni sombras ni nada, es una bestia que lo hace todo en tiempo real según toma el modelo de Revit. En una ejecución con cable, no se nota, pero con este camino sí. Se puede limitar la calidad, hay cuatro niveles, y según el modelo vale uno u otro. Posteriormente he hecho una prueba con el mismo ejecutable de Enscape en una Z8 dual Xeon equipada con una RTX2080 y va muy bien. P4500
¿Qué es lo siguiente? ¿Podría evitar el uso de un ordenador y realizar la computación en la nube en cualquiera de las soluciones que hay? Sí pero aún no. Se están poniendo más que los cimientos. Amazon Wavelength considera que colocar sus infraestructuras para crear instancias EC2 en los mismos centros de datos y cálculo de los operadores de telefonía móvil y fibra óptica es parte fundamental del concepto (Edge Computing). Si el ancho de banda de fibra óptica hoy y telefonía 5G mañana es igual a los más de 800 Mbps que habéis visto en Virtual Desktop, la latencia máxima está garantizada para hacerlo.
Eso se lleva haciendo en el High Frecuency Trading para alojar algoritmos y procesadores (especulación de valores en tiempos ultracortos donde los milisegundos cuentan a la hora de comprar o vender grandes paquetes de títulos) desde hace años, acercar los centros de datos a donde se cuece el asunto.
Bueno, hasta aquí hemos llegado. Me consta, por una publicación que hice hace varias semanas en LinkedIn, en la cual me comentaban algunos compañeros que esperaban anhelantes este ladrillo por el que pido disculpas por su extensión y tecnicismos.
Carta RAL para Unreal Engine
Esta es parte de un proyecto de Agosto de 2018 que me he decidido a compartir. En aquel proyecto podía cambiar en Realidad Virtual la pintura de pilonas, impostas, estructura y barreras de un viaducto de estructura metálico.
Puesto que la carta industrial más utilizada con mis clientes de estructuras metálicas es la RAL me decidí a programar un «Blutility» que creara todos los «assets» a partir de la tabla de colores, tabla que no es facilitada por el propietario del standard. Sin embargo, en la red se encuentra de todo y dí con un CSV con un montón de datos, entre ellos el RGB. A mi parecer los datos son fiables puesto que los he comparado de forma aleatoria con un ojo educado en color y coinciden.
Las «Blutilities» son «Blueprints» para usar en el editor, hoy ya superadas por nuevas clases y «widgets» como son las Editor Utility Widgets y Editor Utility Blueprints.
Quien le baste con la colección de materiales, he de decir que son MIC, Material Instance Constants, basados todos en un mismo padre, otro Material Instance, basado a su vez en un Material Base. El material base tiene cuatro parámetros: Color (Color lineal, Vector 3), Dieléctrico o Metálico, Especularidad y Brillante o Mate (estos tres son escalares). Así, todos los materiales de la carta son creados por defecto con un aspecto ciertamente brillante, pero cambiando cualquiera de sus parámetros podemos obtener acabados diferentes. Ni que decir tiene que los parámetros obedecen al sistema PBR de diseño de materiales. Si no se necesita más, se pueden borrar estos «assets»: BP_Creador_RAL, DS_RAL y DT_RAL_Standard.
A quien le apetezca toquetear el Blueprint lo primero que ha de hacer es habilitar la plugin que posibilita los nodos que uso:
Sin esta activación no funciona. Si lo quieres probar, elimina todos los materiales con nombre M_RALXXXX, menos el Base y la Instancia de referencia (sin ellos no funciona), arrastra BP_Creador_RAL a la escena y tendrás un botón en la pestaña Details que dice Crear Carta. En unos instantes tenemos toda la carta RAL si todo funciona como se espera.
Desde un punto de vista de lógica, la Blueprint es bastante sencilla. Lo principal es tener una Data Structure que defina una Data Table cargada con los datos de un CSV preparado ad-hoc. Iterando por toda la tabla componemos el nombre y obtenemos el valor RGB que transformamos a espacio lineal. Inmediatamente vamos creando Materiales Instancia a partir del Material Instancia base e inyectando los cuatro parámetros. Tenía previsto poder ajustar los parámetros Metal y Roughness desde Details y que pudieran ser variables, pero ya se andará.
Quisiera hacer otra versión haciendo uso de lo que he comentado antes, Editor Utility Widgets y Editor Utility Blueprints, para incorporar una funcionalidad que cree sólo el RAL que necesito desde un menú, pero no he tenido tiempo de aprender a hacerlo. Lo que es seguro es que hay que activar otro plugin:
El contenido del ZIP ha de ponerse como cualquier otro conjunto de assets en la carpeta Content de cualquier proyecto. La descarga, aquí:
Recorridos Virtuales en 2020, ¿aún?
No me cabe uno de esos titulares de los que soy tan amigo, lo resumo como lo he puesto. Pero esta entrada obedece a una reflexión confirmada a su vez por otra entrada en LinkeIn del amigo José Corraliza Miranda, Aecom: los recorridos virtuales nodo a nodo basados en renders 360 siguen siendo una de las herramientas más demandadas de presentación, por increíble que parezca.
Galimatías monumental de 44 equirectangulares en PanoTourPro. Hay que prever todos los movimientos posibles que una visita puede ofrecer.
Da igual estar preparados de sobra para ofrecer interacción plena basada en motores de render en tiempo real de altísima calidad como Unreal Engine o Unity, da lo mismo si agilizas el proceso mediante soluciones más o menos «oneclick» del estilo de Enscape, Twinmotion o Lumion, da igual si ofreces VR con más o menos interacción, da lo mismo si prescribes soluciones de VR colaborativa para evaluación temprana como InsiteVR, Iris Prospect o The Wild: si el cliente final no tiene soporte corporativo en forma de máquinas con prestaciones gráficas elevadas, si aún no le seduce llevar unas Quest a su cliente para presentar las propuestas o si tener reuniones en el metaverso para decidir sobre modelos en desarrollo no forma parte del horizonte de su mirada, no hay nada que hacer.
El caso es que el número de recorridos virtuales que han sido despachados en este estudio desde 2015, siendo un concepto y una tecnología más viejos que un bosque, no ha dejado de crecer. Se ha constituido como la herramienta fundamental de visualización, bastante más allá del video, de los renders tradicionales y muy por encima de interactivos de render en tiempo real.
Esquema de la visita en Revit. Una cámara por cada panorama. Una familia de detalle sirve de guía y planificación. ¿Era para esto eso del BIM?
Del render tradicional es que no quiero saber nada, pese a que 3dsMax y Vray Next siguen entre mis herramientas, no son para nada ya las habituales. ¿Ni siquiera para obtener los render 360 para los recorridos? Ni siquiera.
El nivel de calidad exigido queda garantizado de largo tirando los panoramas desde sesiones de Enscape y Revit. PanotourPro, que quedó congelado en esta version 2.5.14 tras la desaparición de Kolor, sigue siendo la herramienta de autoría, y el resultado sigue siendo hospedado en buckets S3 estáticos en AWS. Un poco de Photoshop para la Splash y el esquema de navegación y poco más.
¿Se factura?. Sí. ¿Es lo que más te gusta hacer?. No. Me motivan otros retos, pero quizá llevado por la riada, el hype, de VR desde 2015, del tiempo real, etc., me voy dando cuenta 4 años después que el mercado no está preparado aún para este tipo de soluciones: las grandes corporaciones, conozco más o menos a fondo un par de ellas, se mueven como dinosaurios, paso muy lento, justificando cada movimiento. En algunas ocasiones determinadas se logra realizar algún desarrollo fuera de lo habitual, pero las pocas. Las empresas pequeñas aún peor, no hay cultura más allá del socorrido render, en un 90% de los casos ni la más remota idea de qué hay detrás de la cúpula donde vivió Truman su show gran parte de su vida, esperando a que por fin encuentren todos la puerta que les saque de la caverna del mito. Con estos tiro la toalla, porque encima no pagan lo que vale, y llevo 30 años tirando renders.
Enscape hace un buen trabajo tirando panoramas, aunque necesita hacerlo por lotes. Ya está apuntado el consejo para la próxima versión.
Con lo cual, de 2019 puedo decir que sí, que he despachado recorridos virtuales 360 no sólo en España: Portugal, Reino Unido, Grecia, Israel, Francia, Alemania, Sudáfrica y Australia. No está nada mal y bien que me alegro, pero me gustaría que hubieran sido productos más avanzados a los que he dedicado mucho I+D+i, mucho tiempo, mucho dinero, mucha ilusión y mucho esfuerzo. A final de año queda un sabor agridulce. Me permito terminar con este verso libre heptasílabo que no viene a cuento.
¡Felices Fiestas a tí,
lector perdido que has
perseverado hasta aquí,
heróico o aburrido!
Oculus Link (beta)
¿Quién no ha oído hablar a estas alturas de Oculus Link? Si aún queda algún rezagado, vamos con una pequeña descripción sobre qué es para poder continuar contando mi opinión personal acerca de dónde me / nos puede llevar desde un punto de vista teórico y a dónde desde un punto de vista eminentemente práctico con un proyecto real, en herramientas reales, que a fin de cuentas es lo que vale.
Las ya maduras Oculus Rift a la izquierda, las Oculus Quest a la derecha
Como la palabra «Link» indica, es un enlace físico entre unas gafas Oculus Quest y un ordenador mediante un cable USB algo especial. Por ahora el cable oficial aún no se despacha, pero Oculus sugiere un modelo en concreto:
Anker Powerline USB-C to USB3.0 – Model: A8167011 (3 m.)
Como todos los productos de Oculus, las Quest están diseñadas y fabricadas con mucho detalle, gusto y atención. Son ligeras, equilibradas, muy atractivas al tacto y sus controllers son los que mejor caen en las manos de todos los que he probado. Cierta tendencia a abrirse la tapa de la pila, que va sujeta por pestaña e imán y si estás echando una partida de Beat Saber, se corre el riesgo de que salga disparada. Se puede comprar aparte el estuche donde queda todo muy bien recogido y listo para viajar, como si fuera un neceser.
No son actualmente las que mejor resolución tienen del mercado (no son unas Varjo VR-2 ni unas Pimax 8, vale), pero superan significativamente a las Rift. Como es lógico mejoran en «screen door effect», «god rays» y mura.
Muy compacto y bonito el estuche de las Quest
Muchos se preguntarán qué sentido tiene conectar unas Quest, que son unas gafas autónomas con seguimiento «inside-out», luego no precisan de sensores externos como sus predecesoras Rift, mediante un cable. Aparentemente ninguno, pero por razones comerciales Facebook decidió que Quest pudiera ejecutar cualquier juego, tanto los nativos de Quest como los de Rift y Rift-S. Los juegos de Quest se ejecutan haciendo uso del potencial gráfico de las mismas, que es el de un móvil de gama más o menos alta: Snapdragon y Vulkan. Cualquier desarrollo dirigido a Quest, por ejemplo desde UnrealEngine 4, debe comenzarse prácticamente desde cero, y pensando en los polígonos que puede mover, los shaders que puede calcular y los efectos que puede simular: lo típico de móvil, «Mobile / Tablet y Scalable 2D or 3D». En resumen una APK con toda la configuración y riesgo de una compilación de Android.
Estos que aquí enlazo, Elara Systems, saben «un puñao».
Pero ahora pongámonos en el día a día, y más concretamente en nuestro mundo BIM + Tiempo real como herramientas / metodologías / objetivos fundamentales. En un estudio como el mío se «despachan» decenas de laboratorios cada mes en todo el mundo desde Portugal hasta Australia pasando por Sudáfrica o Israel. Con ese ritmo uno no puede plantearse hacer APKs a menos que logre un flujo de trabajo muy definido y afinado y siempre y cuando la actitud del cliente sea proactiva al uso de Realidad Virtual de forma cotidiana.
Podría entonces plantearse la compilación de experiencias VR desde UE4 para PC haciendo uso de Oculus Link. Más fácil y más rápido, es la gráfica del PC la que se encarga del streaming a las Quest. Pero es que resulta que hay herramientas muy válidas para evaluación de modelos en fases tempranas (y no tan tempranas) como es la combinación de Revit + Enscape.
Veamos cómo fue el proceso tras recibir el cable. Sin demasiadas esperanzas arranco la aplicación de Oculus, la cual, tras actualizarse (hacía un tiempo que no desarrollaba nada sobre Oculus) muestra esta nueva pantalla:
Emoción. Conecto el cable y… Lo detecta. El de esta pantalla será el propio de Oculus, algo más largo que el de Anker.
Oculus Link reside en el PC y en las gafas, por lo que hay que actualizar software. Se precisó de un reinicio manual ya que tras la descarga, las Quest se quedaron un poco como durmiendo el sueño de los justos.
Reiniciadas, la App de Oculus en el PC nos muestra esta novísima pantalla donde podemos seleccionar de las gafas conectadas las que queramos utilizar:
Evidentemente lo que quiero es probar las Quest:
Por cierto, el mensaje de que el ordenador no cumple los requisitos mínimos tiene una explicación: desde Oculus no conciben que alguien pueda usar un ordenador con 2 Xeon Gold para VR.
Y llega la hora de la verdad. Probar lo más difícil, nada de juegos. Abierta una sesión de Revit con un laboratorio que no existe porque es un lab show room con unos productos nuevos, lanzo Enscape, y ya en la pantalla, activo VR. Aunque las gafas son usadas en diversas estancias, parece que reconocen dónde han estado antes sin pedir de nuevo trazar el «Guardián» (algo, por otro lado, en lo que se tarda menos de un minuto). Únicamente y a veces hay que recalibrar la altura del suelo, como sí que sucedió en esta ocasión. Pues aquí está el resultado. Del modelo a experienciarlo en VR en menos de 20 segundos, un poco torpe yo, pues con la emoción dejé que el cable se enredara en una silla y notaba los tirones.
El resultado de este viaje es el siguiente: del mismo modo que vamos a clientes a hacer sesiones en tiempo real con Revit donde modelamos a la carta la automatización de su laboratorio quiero terminar las sesiones dándoles la oportunidad de poder experienciarlo en VR sin tener que llevar más trastos que un portátil potente y unas Quest, algo que cabe como equipaje de cabina en cualquier vuelo. Ni sensores ni más historias. Lo que no quita que se pueda y se deba tener unas gafas de gama alta como las mencionadas previamente para explorar productos mucho más refinados y maduros como los que se pueden obtener desde UE4.
Termino comentando mi esperanza de que se haga realidad lo que John Carmack dijo en la última Oculus Connect: «no descartamos un Oculus Link inhalámbrico en 2020». ¡Toma!.
Realidad Virtual en procesos creativos
Entrada corta. La Realidad Virtual la hemos comenzado a ver en el sector del entretenimiento, donde ha ido cogiendo fuerza con mayor o menor fortuna, de acuerdo a precios, requerimientos y espacios.
Posteriormente, casi simultáneamente, y gracias a la fuerza que los motores de render de videojuegos han aportado, hemos visto cómo en el entorno profesional y empresarial de toda clase de sectores se ha hecho un hueco casi más importante que en el del entretenimiento.
Y lo que se veía venir, que podamos usar herramientas profesionales desde el otro lado, embebidos en una experiencia VR, es ya un hecho.
El otro día llego a mi estudio y me encuentro a Claudia Rivera Arranz modelando en Maya, a modo de test, un asset con el que llevaba un par de días.
-¿Estás cómoda modelando así?
+No sólo es que esté cómoda, creo que estoy modelando mucho más rápido, estoy más inmersa, más concentrada, con más libertad creativa (suena a Tilt Brush).
-¿Cuánto tiempo llevas así, y cuánto tiempo crees que podrías estar, así digo de pie?
+No sé cuánto tiempo llevo, pero como modelo más rápido, estaré menos tiempo de pie del que estaría sentada modelando en pantalla.
Al rato, como una media hora, la veo sentada en el suelo, el asset prácticamente terminado. Y ella muy contenta por la experiencia. Terminado el trabajo un rato más tarde le pregunto.
-¿Qué pros y qué contras le encuentras a este cambio de paradigma en el modelado?
+Los principales pros son dos: la abstracción tiene como consecuencia mayor concentración, la ausencia del marco de una pantalla aporta mayor libertad creativa, me puedo mover alrededor del objeto, incluso meterme dentro y realizar detalles que de otra forma no sería posible. Los contras van ligados a las gafas principalmente en el sentido de la ergonomía y la calidad: en primer lugar, estas HTC Vive, por alguna razón, dan calor o sensación de calor. En segundo lugar, no están equilibradas y se acaban haciendo notar sobre la cara al cabo de una hora. Un peso en la parte posterior, quizá llevar parte de la electrónica a una caja detrás sería una solución para equilibrar las gafas y que una no acabe con mala experiencia.
La última versión de Oculus Home tiene muy mejorada la visión de la pantalla del ordenador dentro de las propias gafas. Hice una prueba, tratar de hacer algo en Revit. Como es lógico, fue una tarea imposible, no está preparado para ello y seguimos confinados a un espacio 2D que muestra objetos 3D con mayor o menor suerte. Pero ¿podríamos imaginar una interfaz para Revit al estilo del Unreal Engine VR Editor?
Más. ¿La podríamos imaginar en multiescala libre, trabajando a escala 1:1, dentro del edificio, o a otra cualquiera, como un «hacedor»? Y aún más: ¿colaborativa, al estilo InsiteVR?
Sólo pedimos, como conclusión, dos cosas:
1.- sea para ZBrush, Substance Painter, Revit, o lo que toque, que la interfaz esté diseñada para estar sentado, que es la forma natural de trabajar, y el que quiera trabajar de pie, que también lo pueda hacer.
2.- HMD’s equilibrados, ligeros y frescos. Y como mínimo con una resolución como la de las HP Reverb o ya puestos, unas Pimax 8K…
Herramientas VR para toma temprana de decisiones
A finales de 2016 evaluaba una aplicación de desarrollo incipiente como era entonces Iris Prospect e Iris Scope. La segunda basada en recorridos virtuales apoyados en imágenes equirectangulares 360, lo que llevo resolviendo por otros caminos desde hace ya 4 años. La interesante para mí era la primera:
Está claro que no permite elaboraciones mucho más cuidadas en interfaz y calidad como este desarrollo realizado en UnrealStudio en verano de 2018:
Permitía Prospect en cambio, y permite, montar de forma rápida una revisión en VR de un proyecto, sin demasiado esfuerzo. Más allá de formatos de entrada, de calidades finales, de integración en herramientas cotidianas o de UX, la intención hace casi 3 años estaba ya clara de por dónde podían ir los tiros.
La madurez de Iris VR es patente, como empresa sólida y solvente. No se ha esfumado como tantas otras en este plazo, al contrario, ha seguido desarrollando y mejorando ahora su producto con dos líneas que me han gustado especialmente.
La primera un porting a Oculus Quest. La segunda la integración en Navisworks. El binomio no es baladí. A nadie se nos escapa que tiempo real y VR ya se mira desde el mundo empresarial como soluciones que van más alla del ¡WOW! inicial. Aunque les sigue costando. Pero la actitud es ya otra.
Por mi trabajo cotidiano estoy muy acostumbrado a realizar muchos proyectos pequeños, pero muy rápidamente y sobre los que tomar decisiones prontas. Modelos en Revit con multitud de conjuntos y opciones de diseño, cuyas combinaciones dan como resultado muchas propuestas diferentes.
La idea de usar UnrealStudio y hacer modelos interactivos de alta calidad se desestima en estos casos, quedan más del lado del marketing para epatar en presentaciones a gerencia, congresos o ferias, tomando ahora el protagonismo soluciones que antes no me gustaban, como Enscape, InsiteVR, Prospect, Lumion o Twinmotion, las denominadas «OneClick«. En España tenemos soluciones fantásticas, como la de VTLab: VTPlatform, apoyada, como otras que no merecen que las olvide (disculpas), en Forge, la API de Autodesk para desarrollos web íntimamente relacionados con Revit.
En todas ellas la unión con BIM es fundamental. Pero lo que más me llama la atención para tenerlas en consideración en la toma temprana de decisiones es:
1.- integración con herramienta, en mi caso Revit.
2.- colaborativa: el hecho de poder integrar a varias personas en lugares diferentes en un encuentro VR (o no) sobre diversos dispositivos (HMD’s y pantallas).
3.- contenido alojado en nube.
4.- «portings» a HMD’s inside out y autónomos (como Oculus Quest, quizá Vive Cosmos con Wireless, no parece que Vive Focus).
5.- anotaciones por parte de los usuarios.
La suma de todas ellas y unas Quest hace que las reuniones puedan tener lugar en el espacio virtual constituido por el gemelo digital, cualesquiera que sean los integrantes de la misma, donde quiera que estén presencialmente. El cliente final no tiene aún porqué disponer de unas gafas de gama alta y el precio de unas Quest es lo suficientemente bajo como para que en el mundo empresarial no sea un disparate ponerlas a disposición del cliente final, darle diez minutos de formación y finalmente enseñarle a entrar en el proyecto en las reuniones que se convoquen. O viajar a la reunión con el cliente con las Quest en la cabina del avión y no tener que hacer un setup complicado (outside-in) en sus instalaciones.
Mi experiencia con InsiteVR ha sido más que satisfactoria, tanto en Rift, Vive, Quest o pantalla. Han sido corregidas algunas carencias iniciales, pero cumple con las 5 premisas indicadas. La calidad es insuficiente, no alcanza a Enscape, Lumion o Twinmotion ni de lejos, pero es suficiente para comparecer virtualmente un grupo que va a tomar decisiones. Me faltan algunas cosas, como cambiar de opción de diseño, pero tenemos capas como categorías, pudiéndolas activar / desactivar.
Hemos tenido sesiones conjuntas con VtLab y José María Catena, saliendo de ellas todos satisfechos. Aquí un ejemplo aunque es una sesión donde estaba solo.
*La calidad de video tan mala es debido a que fue capturado de un streaming desde la Quest a un Ipad. Supongo que lo habrán mejorado.
La razón por la que me he animado a escribir hoy este artículo, cuando pensaba haber escrito otro es que aunque no haya vuelto a probar Prospect y del cual estoy esperando autorización para testar la versión Quest, es la plugin que tiene para Navisworks. Uno podría pensar que la toma de decisiones tempranas se basa sólo en la valoración común de razones espaciales, estéticas, funcionales o simplemente de cumplimiento de pliegos, pero el hecho de poder vivenciar de forma plural un modelo de coordinación de forma instantánea a escala 1:1 me pareció lo suficientemente significativa como para dejar en un segundo plano las conclusiones de la reciente Oculus Connect 6.
La detección de colisiones es algo que encontraba yo con frecuencia cuando ilustraba de forma artística planificaciones de obra 4D (de Gantt a render). Sucedía entonces una llamada de teléfono para advertir a constructora u oficina técnica de insconsitencias en el modelo o en MSProject.
4d «artístico» para ilustrar un avance de obra de un centro penitenciario
Todos sabemos hoy que con Navis esto ya no puede suceder, pero la posibilidad de hacerlo a escala 1:1 de forma inmersiva me parece sencillamente maravilloso. Otra cosa es la adopción que se haga de ello en el mercado, en la oficina técnica, en la obra. Hemos de acostumbrarnos a ser pacientes.
He de volver a probar Prospect en situaciones reales, y especialmente la versión para Quest.
Qué podemos esperar del Raytracing en Unreal Engine 4.22
5 minutos de lectura
Editado: esta entrada llega un día tarde. Ya ha sido publicada la versión 4.22
Hablo de lo que podemos saber de la prerelease.
Al fin!
Cada nueva versión oficial de Unreal Engine viene precedida por 2, 3 y hasta 4 ‘previews’. Y cuando digo oficial me refiero a la lanzada por Epic Games desde el ‘laucher’, porque al ser un editor y motor de render de código abierto y residir sus cientos de miles, o millones, de líneas de código en Github cualquiera que se atreva puede personalizarlo a su gusto como sabemos de muchas versiones ‘alternativas’.
Las ‘previews’ de las que hablo permiten depurar errores de última hora, poniéndolas en manos de decenas de miles de entusiastas que reportan incidencias que serán corregidas en los cuarteles de Epic. Por supuesto estas versiones nunca deben utilizarse en producción, por mucha ilusión que nos haga probar las decenas de novedades que trae cada nueva edición.
Ofertón del año pasado, se las quitaban de las manos
Pero la 4.22 va a ser un caso especial. Cuando en el GDC2018 Nvidia presentó la primera gráfica con ‘raytracing’ en tiempo real, fue como si se encontrara el Santo Grial perdido hace 2000 años. Y se presentó sobre cinemáticas calculadas en tiempo real en UE4, lo que hacía presagiar aquello que en una o dos semanas tendremos de forma oficial. Entonces las demos se realizaron sobre carísimas estaciones equipadas con 4 gráficas Tesla GV100. Hoy el RT (raytracing, no retweet) que tenemos a nuestra disposición funciona sobre una sola RTX2080Ti, algo que buscaban en Epic Games para hacerlo mucho más accesible.
Hace volar a Enscape, a ver a UnrealEngine
Ya vamos (íbamos) por la ‘preview’ 7, algo que al menos a mi me lleva a pensar que la final va a ser lanzada evitando en lo posible cualquier ‘bug’, especialmente en lo que a ‘raytracing’ se refiere.
Ha habido que cambiar esta captura, la de antes era de la preview
El RT, aunque ya válido para cualquier producción, aún es un WIP, un ‘early access’. Está habilitado para iluminación global (preferentemente primer rebote), sombras difusas de cualquier emisor, ‘ambient oclussion’, reflexiones, translucencias e IBL basado en imágenes HDR, entre otras, dejando a un lado ‘lightmaps’, ‘sphere and cube reflection captures’, ‘planar reflections’ y ‘ambient oclussion’ entre otros efectos en ‘screen space’.
Brutal, la demo «A Hands-on Look at Using Ray Tracing in Games with UE 4.22 | GDC 2019»
Lo mejor de todo es que es híbrido, por lo que podemos elegir el camino tradicional para unos efectos y raytracing para otros.
En la 4.22 tenemos en realidad dos motores de RT:
1.- RT hibridado con los efectos raster: el que hay que usar.
2.- Path tracer, un RT puro, ‘unbiased’ usado como referencia para aprobar internamente los desarrollos del primero. Es una herramienta de uso interno.
Reflejos nítidos por fin
La principal ventaja de raytracing frente técnicas consolidadas es que para el usuario es mucho más sencillo de implementar: no ha de preocuparse de añadir ‘reflection probes’ para las reflexiones, y estas, al no ser en ‘screen space’ serán de calidad excelente, tampoco habría de preocuparse del tedioso ‘unwrapping’, ni de afinar con decenas de valores en el cálculo de iluminación, las sombras serán físicamente perfectas, y los resultados no se verán afectados por imperfecciones en el modelado. Todo esto, claro, en función del balance entre pases rasterizados y calculados por RT. Lo mejor de todo es la naturaleza híbrida de la propuesta.
Lo que sí
Lo que no
Para hacer uso de RT en la 4.22 hay dos premisas ineludibles: Windows 10 1809 y una gráfica RTX, sea Quadro o GeForce.
Requisitos
Este último punto, que es obvio, conlleva a una reflexión a la hora de determinar el objeto de nuestro desarrollo, es decir, si el cliente dispone o está dispuesto a disponer de una máquina con RTX o no. Decisión que por otro lado, y con el paso del tiempo, perderá importancia en la medida que la computación en tiempo real en ‘server side’ sea cada vez más común: Pixel Streaming, GForce Now, RTX Server Line, 5G, Stadia, bla, bla, bla.
Por otro lado también pienso si el cliente notará o no la diferencia de una escena en RT o no, pero eso es otra historia. Mi visión se basa más en un B2B que en B2C. Son públicos distintos.
Variables de consola, muchas
Actualmente la mayoría de las funcionalidades de RT se controlan desde la consola de comandos por medio de un nutrido grupo de variables, algo que se habilitará con una interfaz de usuario en la 4.23. Hay otras funciones que se controlan desde los propios actores, como algunas de ellas desde el PostProcess Volume.
Importancia añadida del Postprocess Volume
Mientras el cálculo se haga sobre RTX local, hemos de tener en cuenta que algunos procesos RT son muy rápidos, incluso más que los tradicionales (sombras, AO), y otros no (reflexiones de más de un rebote, GI de muchas luces, interiores, reflejos muy difusos, pese al Denoiser). De ahí que la posibilidad de hibridarlos o repartirlos entre RT y procesos tradicionales es una opción excelente pero que habrá que distribuir mediante un ‘profiling’ bien segmentado.
Importante decidir qué y qué no será calculado en RT
A través del PostPro y las variables podremos buscar un balance adecuado para cada ocasión
Las zonas que delimitan reflexiones nítidas de reflexiones totalmente difusas tienen un coste significativo. Hay variables para mitigar esta pérdida de FPS
Ojo con la autoría de materiales complejos. Sobre todo mejor tirar de un Ubershader o padre súper paramétrico y materiales instanciados para reducir drawcalls. A ver Substance Designer… A ver las importaciones de Datasmith y sus réplicas de Vray.
Conclusiones para la 4.22
Conviene mencionar que pese a haber sido habilitadas en versiones precedentes las luces rectangulares no han tenido una funcionalidad plena hasta esta 4.22, momento en el que al disponer de RT, su semejanza con la realidad es ya total. Además se ha añadido la función ‘barn door’, que determina la apertura del cono de iluminación, como en los focos de iluminación de estudio.
Muy buena implementación de las luces rectangulares
En fin, que a falta de la publicación final, que es de esperar que sea esta semana (ya ha sido, 16:00 del 2 de Abril), esto es todo lo que puedo decir de una versión que supondrá un antes y un después.
Recientemente se generó de forma espontánea y desde LinkedIn un #debate interesante sobre el nivel de detalle que «deberían» tener los objetos #BIM de acuerdo a la potencia gráfica de las estaciones de trabajo más o menos comunes hoy día. Este debate surgió a partir de la publicación de un post acompañado de unas imágenes extraordinarias, de renders de uso comercial, de donde comentarios propios le sugerían al autor la posibilidad de realizar objetos BIM a partir de modelos muy detallados destinados a renders comerciales como las imágenes mencionadas.
Estos modelos quedan definidos por topologías con muchos polígonos, sin mapas de curvatura, ni de normales, ni de «ambient occlusion», tampoco «height maps», es decir, polígonos a manta y a pelo. Ideales para renders de muy alta calidad, lo que hoy llaman “off-line”.
Se mencionaba en el debate que bien esos modelos tan detallados, dados algunos ejemplos de eficiencia a la hora de servir desde la nube modelos muy detallados a dispositivos de poca capacidad gráfica, como los smartphones, siempre desde un punto de vista comparativo con estaciones de trabajo, podrían servir como modelos BIM, al seguir ese esquema cliente-servidor, o de virtualización de escritorios.
Mi opinión es diferente. Quizá al estar centrada en #Revit, donde sé que tenemos hasta tres niveles de detalle y vistas 2D para los objetos BIM, tengo más que entendido que esos mismos objetos, repetidos cientos o miles de veces en un modelo, hacen que si no están optimizados al máximo para el uso BIM que se le vaya a dar, con sus niveles de detalle, con un modelado relativamente simplificado, no destinado a un render de alta calidad, harán del modelo un ladrillo que conducirá al usuario al hastío y la decepción en el uso habitual.
Actualmente no creo, ni con una gráfica GV100, que se puedan utilizar topologías para render comercial en un modelo BIM. Ponía en el debate ejemplos del mundo de los videojuegos, con activos representados en varios niveles de detalle, con materiales que a través de mapas de normales y otros simulan relieves y topologías complejas, incluso con impostores o «billboards». No parece que estas técnicas hayan sido replicadas en el mundo BIM, sea cual sea el programa, luego queda lejos la idea de representar con buena calidad comercial renders desde estas aplicaciones. Es cierto que Revit hace una gestión interna de la complejidad de la escena digamos que singular y eficaz, pero no es raro encontrarme aún así modelos que se mueven torpemente.
Hace ya un tiempo publiqué un post donde mencionaba la sorpresa que me llevé al descargar un objeto desde un repositorio tipo Bimobject, Bimetica o Bim&Co y comprobar que tenía sólo un nivel de detalle y que además era un modelo importado a la brava desde #Solidworks, o #Catia o tal: inasumible en metodología BIM, fuera cual fuera el programa de destino.
Al contrario, hoy mismo, comprobaba como un fabricante de mobiliario de oficina bastante conocido tiene sus objetos BIM modelados en primer lugar con las herramientas de modelado de Revit, con un conjunto de metadatos relativamente pequeño y racional, abierto y con materiales nominados bajo el prefijo del fabricante para poder ser fácilmente mapeados en cualquier automatización. Bravo por ellos. Que sí, que no servirán para render de alta calidad, muy detallados, muy «BRICK», pero servirán para su destino, metodología BIM «for the masses’’, democratizada.
En mi metodología tengo una serie de librerías replicadas según la herramienta: unas en Revit, para su destino, metodología BIM, para objetivos y usos racionales, sus réplicas en #3dsMax, para renders offline de calidad on #VrayNext, y por último otras réplicas como activos en #UnrealEngine para #RealidadVirtual, tiempo real y render instantáneo. El hilo conductor son una serie de automatizaciones en diversos lenguajes de programación y estructuras de datos tabuladas así como diccionarios para mapeo de datos entre ellas. Hasta ahora es lo que mejor me ha ido y del carro que no me bajaré hasta que tenga en cualquier «workstation» metodología BIM, render de calidad, tiempo real y realidad virtual en la misma plataforma. Lo que por otro lado tampoco me seduce. #Enscape da una calidad bastante aceptable dentro de Revit para la mayoría de las situaciones de planificación y diseño con la mayoría de los clientes.
Vriverity, habilitada como operadora de RPA (Drones)
(6 minutos de lectura)
No recuerdo bien qué año era cuando recurría a los servicios de Paisajes Españoles, quizá el año 2002 fue la última vez, para que alguna de sus avionetas que salían de Cuatro Vientos, pilotadas por sus diestros pilotos, realizara un reportaje aéreo que servía como fondo de fotomontajes que me eran solicitados. Desde aquellos que sirvieron para reflejar los diversos impactos que la M50 podría tener, o alguna de las radiales rescatadas hoy, a proyectos urbanísticos en lugares de toda índole.
Hace un par de años el uso de drones para estos objetivos ya comenzaba a ser habitual, y de algún encargo para otro proyecto urbanístico en el que recurrí a un vuelo fotográfico me vino una idea que hoy ya es una realidad: poner algún huevo en otra cesta ofertando servicios de operaciones de fotografía y video aéreo así como de fotogrametría, que es al fin, el ejercicio para el que hemos sido habilitados (2.8 del listado de actividades AESA). Prestación de servicios o a lo peor, autoconsumo.
Pero para ello, hablamos de vuelos profesionales y no recreativos, hay que poner en marcha una secuencia de requisitos, donde el más sencillo sea quizá la elección y adquisición del equipo. DJI es ya una marca muy de confianza (¿la manzana de los drones?), con calidades excelentes, un software bastante depurado y con actualizaciones frecuentes y un parque de aparatos extendido y con pocas malas experiencias.
DJI Phantom 4 Pro V2.0
Este fue el RPA elegido, en resumen, por su estupenda relación calidad / precio. Menos de 2 Kg., incluida carga de pago: la cámara. Carácterísticas: la cámara con la que viene equipado es realmente buena, un sensor CMOS de 1″ y 20 MP, obturador mecánico, gimbal estabilizador excelente, video en 4K a 60 fps, codecs H264 y H265, RAW y Jpeg, transmisiones en doble banda con la estación (para evitar bandas saturadas), transmisión de video en 1080p, detección de obstáculos en 5 direcciones y evasión de los mismos en 4 en modo autónomo, 3 modos de vuelo, incluído manual total y Return to Home fiable, incluso tras obstáculos o perdida de señal y unos 30 minutos de vuelo por batería (safe mode pongamos 20, que es cuando empieza a protestar).
Momento unboxing
La legislación de AESA permite que la adquisición de un dron comercial habilite al comprador para vuelos recreativos, pero no comerciales. Por lo tanto es necesario habilitar a una persona física o jurídica como operadora de vuelo. Y para esta habilitación, entre una burocracia de decenas de requisitos, el imprescindible es contar con un piloto profesional. Entre muchas otras opciones la más sensata fue que mi hija, Claudia Rivera Arranz, que es artista 3D, ampliara conocimientos y posibilidades de trabajo realizando la formación y obtuviera a lo largo de unos meses y tras concienzudos exámenes y prácticas las certificaciónes básica, avanzada, práctico de Phantom 4 y de radiofonista. Esta última le habilita para volar en zonas urbanas y espacios aéreos controlados, entre otras. Cumplidos también fueron los requisitos del certificado médico y seguro de responsabilidad civil.
En los vuelos, uno no sabe nunca con total certeza ni las condiciones físicas y ambientales que se va a encontrar, ni si los planos que uno pensaba tomar inicialmente serán buenos o no y habrá que repetir vuelos por iluminación incorrecta, sombras, reflejos, etc. Por lo tanto además del RPA hay que contar con una «batería» de baterías dispuestas (más inversión, no son nada baratas):
El nicho de carga
Toda la información de vuelo, que es mucha, se recibe y procesa a través del software DJI Go, que funciona sobre un Ipad decente (otra adquisición más).
Todo dispuesto para el despegue
En cada sesión se ha de realizar un ritual muy de aviación, con calibraciones, revisiones de hélices y motores, revisiones de carga de baterías, fijación de punto de despegue para un RTH fiable, etc.
Uno de los requisitos que pide AESA es la cumplimentación del libro de los vuelos de prueba, donde poner en práctica maniobras evasivas ante situaciones imprevistas (ataque de un milano, p.e.), RTH incluso por acompañante, evaluación de riesgos potenciales del volumen de vuelo (cables aéreos, propiedades particulares, otros drones en la zona, anidaciones de aves que no deben ser molestadas y un largo etc.).
Todo dispuesto para cumplimentar vuelos de prueba, aquí con esa niebla castellana que se pega durante semanas
Tras 4 o 5 sesiones de vuelo en diversos escenarios libres de regulación aérea (por evitar los trámites de las solicitudes de autorización, sede electrónica AESA – Ministerio de Fomento, certificado digital, bla, bla, bla) reunimos secuencias suficientes como para montar uno de los primeros videos (que fue un encargo para mi hermano).
Hemos completado la inversión con diversos accesorios, como una mochila de transporte, para cuando no se puede llegar en coche que no haga falta llevar la maleta, una sujección para la estación, que tras 40 minutos de uso ya se termina con los brazos cansados, y una plancha plegable de aterrizaje, para despejar el suelo de maleza y permitir un RTH más limpio.
Además de fotografía aérea y video, la tercera intención de la oferta es generar modelos mediante fotogrametría. Hemos probado diversas soluciones, como Recap (incluida en nuestra suscripción AEC Collection de Autodesk), Aegis Photoscan y Reality Capture. Finalmente nos hemos quedado con esta última, por suscripción trimestral, porque entre otras virtudes es muy rápido en sus cálculos, y hace uso de todos los threads que encuentra.
Primer trabajo comercial, para Cesma Ingenieros, Salamanca
Algunos ya saben de mi fijación con el uso de toda la potencia posible en una máquina para cualquier cálculo y Reality Capture lo hace. No estoy seguro que los adversarios lo hagan, la HP Z8 G4 llegó después de la elección de Reality Capture, y la verdad no hemos probado en ella ni Photoscan ni Recap.
Reality Capture fundiendo Xeones
Los fotomontajes de este trabajo no los puedo publicar aún, pero sí un primer test para generar un modelo, que fue convenientemente retocado en ZBrush y Substance Painter (¿he dicho ya que Claudia es 3D Artist y pilota también y muy bien en estos programas?) y subido a Sketchfab:
https://sketchfab.com/models/041de519c959406b9c854272017cf93e/embed
En fotogrametría diferencio dos escenarios:
1.- la toma de una «fotografía 3d», es decir reflejar de forma exacta las circunstancias del contexto (tiempo atmosférico, gente, animales…) lo que conlleva a que en principio no importe que el cielo esté despejado o no, que haya sombras duras arrojadas. En el último caso habrá que tomar las fotos muy rápidamente para evitar que las sombras se hayan movido demasiado. Pero no es un modelo reutilizable, asset, puesto que ya tiene sombra y su textura no es un difuso puro, si no que tiene información de iluminación.
2.- la toma de fotografías en lo que en esta casa se llama «photogrammetry day», es decir, día de cielo cubierto, sin sombras duras, sin iluminación directa y poca iluminación, escenario plano lumínicamente hablando, lo que nos dará difusos puros o que tengan que ser poco procesados (somos betatesters de Substance Alchemist y parece ser que prepara unos difusos ideales). Calibración con un Color Checker de Xrite Passport para neutralizar influencias de temperatura de color y tal. La consecuencia son assets ideales para formar parte de una librería que luego podrán ser iluminados de forma sintética en cualquier autoría 3D (UnrealStudio, por ejemplo) con total confianza. (Luego no hay cliente que perciba todo este trabajo, pero bueno).
Ejemplo de lo que sería un asset obtenido siguiendo parcialmente el segundo punto (el día no fue un puro «photogrammetry day» ya que había nubes y claros y algunas fotos salieron con sombra…):
Finalmente y rematando el último vuelo de prueba con RTHs complicados, con anidaciones de cigüeñas desconfiadas, con un milano acechando, volando casi en EVLOS (obstáculos impiden contacto visual con el UAV) y no pudiendo sobrevolar todo un volumen de vuelo debido a unos árboles que tapaban los encuadres hicimos este otro modelo, mucho más complicado que el del puente. Los detalles de las ruinas nos han gustado especialmente, cómo los ha resuelto el software. Nos hubiera gustado hacer muchas más fotos, pero no fue posible, por esas circunstancias contextuales que menciono unos párrafos arriba. Razón por la cual el modelo es incompleto en su parte posterior. Insisto, son muy pocas fotografías para lo que hubiera sido deseable.
Cabe destacar que los datos GPS del Phantom, que le sirven para muchas cosas, quedan embebidos en los datos EXIF de las imágenes, es decir que son fotografías georeferenciadas que ayudan en los cálculos de Reality Capture a obtener resultados de mayor precisión.
Datos de posicionamiento de esta foto
Vriverity 