UnrealStudio 4.21: plugin Revit a Datasmith
Quienes llevamos desde septiembre de 2017 en el programa de betatesting de Unreal Studio hemos visto cómo la propuesta ha ido pasando de prometedora a genial. El márketing también ha hecho lo suyo y ahora el producto se presenta como una solución realtime y VR indiscutible para el sector AEC.
El juego Fortnite no solo ha llenado de dólares las arcas de EpicGames potenciando toda clase de desarrollos e innovaciones, también ha colaborado en innumerables mejoras que se han ido desvelando en sucesivas versiones, accesibles ahora para todos.
Quienes trabajamos de forma habitual haciendo uso de la metodología BIM nos las hemos ido apañando para llevar nuestros modelos a UE4 mediante flujos de trabajo propios, hibridaciones, automatizaciones y demás historias. Aún así, la parte arquitectónica del asunto, es decir, toda clase de elementos no sujetos a instancias y de dimensiones y características completamente variables, debían de seguir un proceso que pasa por 3dsMax. Allí ajustamos UVs para lightmaps, editamos mallas y hacemos diversas tareas que mejoran de formas sustancial el resultado.
Hace un tiempo se hizo una consulta acerca de qué grado de aceptación tendría un exportador de Revit a formato Udatasmith, y qué funcionalidades nos gustaría que incluyera. Bien, con la 4.21 se ha publicado la primera versión y puedo decir que es verdaderamente prometedora en su concepción.
He explorado algo sus funciones y sus posibilidades, cómo organiza una estructura de datos como es la de Revit en otra estructura de datos como es la de Unreal, pero no será hasta la puesta en producción cuando sepa realmente el alcance del éxito indiscutible.
En una primera mirada he recopilado una serie de aspectos interesantes.
1.- La exportación se hace de lo que se ve en la ventana desde la que lanza, tal cual.
2.- Por cada categoría presente en el modelo de Revit se crea una capa en Unreal
3.- Los nombre de los Static Meshes en el Content Browser obedecen al nombre de tipo que tienen en Revit, y darán tantos actores como instancias hubiera de ese tipo en el modelo, con sus respectivas transformadas.
4.- Elementos con otros elementos hospedados quedan agrupados en un actor vacío que tiene como hijos al elemento y sus huéspedes (muros cortina, elementos con huéspedes por cara, techos con luminarias alojadas, etc.)
5.- Los actores ya no vienen con la escala 30.48 propia de fbx importados desde 3dsMax donde se importaron / enlazaron desde otro fbx o rvt.
6.- Todos los materiales son instancias de un material padre, «RevitMaster» con 6 grupos de parámetros que permiten toda clase de instancias.
7.- En las pruebas realizadas las luminarias no vienen como points o spots, luces propias de UE4, que además desde hace alguna versión tienen valores reales de luminancia e IES, si no como superficies con material emisivo.
8.- Cada muro cortina es un actor que agrupa paneles y montantes. Cada panel y montante se refiere a un Static Mesh en el Content Browser, pero no hay repeticiones, si no que queda todo muy bien «instanciado».
9.- La generación de UVs para lightmapping queda determinada de un modo algo «chusco»: tamaño mínimo y tamaño máximo. No hay opción a dar «padding»
No es lo mismo una puerta que un suelo, pero la parte del suelo que queda «fuera» no tiene porqué ocupar el mismo espacio UV que la de dentro…..
Ya hablaré otro día de cómo pienso que puede mejorar este flujo, o al menos de cómo lo hago yo.
Real Time Ray Tracing y su uso comercial
Deme dos de éstas, por favor
(4 minutos de lectura)
Otros ven series (y yo antes también), pero ayer comencé a ver las casi dos horas y media de la ponencia de Jen Hsun Huan, el animado CEO de Nvidia en el pasado GDC 2018. Interesantísimo lo que cuenta y explicado de una forma amena y apasionada, un showman, no a la altura de Steve Ballmer, claro. Aquí un ejemplito de RTRT bien majo:
Y explicaba Jen, unas horas después de que Epic Games desvelara la combinación de la tecnología RTX de Nvidia, DXR de Microsoft (la capa ray tracing para DirectX12) y los desarrollos realizados dentro de la misma división de ray tracing de Epic Games (con Juan Cañada, nuestro paisano, allí metido), explicaba digo, de una forma más pormenorizada la tecnología que subyace detrás. Y sobre todo de una forma más… comercial, que para eso estaba allí.
Y es aquí donde quería llegar. A lo comercial. Hemos alcanzado un punto en el que con cualquier ordenador de gama alta podemos desarrollar realtime de calidad a un ratio de fotogramas y resolución muy buenos. Y podemos, puesto que no es RT si no rasterizado, precocinado (lightmaps, lightbaking), realizar los cálculos (swarm agents en UE4) en nuestras propias máquinas o en la nube con servicios como las instancias EC2 de AWS (lástima que el servicio Deadline de AWS no contemple lighmassing, sólo a través de instancias personalizadas).
Y es que Jen menciona que el hardware en el que fue hecho el famosísimo corto de los stormtrooper es esa caja denominada DGX Station, equipada con 4 Voltas…. y que cuesta 68,000 $
Quiero un par, oiga!
Si en mi negocio B2B yo me las veo y me las deseo para que los clientes acepten un equipamiento para realtime HQ (no ray tracing, no VR) que rondaría los 2,000-3,000 € (me estoy planteando seriamente la cesión por renting para que no tengan que comprar nada) ¿cómo diablos vamos a convencer a nadie de que tenga en su showroom esta DGX para estar a la última de la última y así tener realtime ray tracing en demos convencionales y VR? Por eso mi convicción es que este tipo de máquinas NO las vamos a ver en nuestras oficinas, ni mucho menos en las de nuestros clientes, si no que irán a sustituir las granjas de render offline y servicios en la nube, y generando secuencias a 60 fps casi on the fly usando editores como el Sequencer de Unreal Engine y como ya hemos visto en muchos ejemplos (Hellblade: Senua’s Sacrifice de Ninja Theory).
En Roman Paladino: van dirigidas a estudios que realizan contenido para cine y televisión, donde todo se hace con motores ray tracing unbiased y granjas de render y muchas horas de cálculo y donde la posibilidad de obtener secuencias en tiempo real y poder corregir tantas veces como sea necesario sin morir en el intento es el Walhalla prometido si no caes en la contienda.
Pero sí abren el camino a tres promesas:
1.- hibridación de técnicas lightbaking para iluminación global + raytracing para reflejos y ambient occlusion (y así huir de estas técnicas en screen space, ya que es lo que más se nota).
2.- bajada progresiva de precios de las arquitecturas Pascal y más tarde Volta a medida que Nvidia amortiza inversiones vendiendo las nuevas Quadro GV100 a quien las quiera pagar (minar Ethereums y tal).
3.- buenas ofertas de segunda mano de buenos servidores enrackables que han sido sustituídos por estas tecnologías.
La DGX-2 de la imagen que abre el artículo está en oferta: 400,000 $ y mina que es un primor.
Magic Leap SDK released!
(4 minutos de lectura)
Dos entradas en dos días, ¡lo nunca visto!, pero es que en una semana se está poniendo en el mundo VR / AR / MR patas arriba. Si ayer colgaba un artículo relacionado con el advenimiento al fin de una experiencia LightField, unas horas después se publicaba el SDK para el HMD de Magic Leap. Y mañana en la inauguración del GDC Epic dará la campanada con el ¡al fin! Ray Tracing en tiempo real sobre GPU a través de DirectX12 y la tecnología de Nvidia RTX…
Esto sin contar con que también se acaba de poner a la venta en preorder el HTC Vive Pro, pero… ¡sin controladores ni faros! Pero eso es otra historia que ya criticaré.
Quien hoy día no esté al tanto de qué es Magic Leap se lo tendría que repensar. Que busque y estudie. En resumen se trata de la compañía que ha recaudado en crowdfounding más dinero en la historia para un producto del que apenas se sabía nada hasta hace un par de meses. En ella han invertido las más importantes multinacionales y fondos de inversión. Producto y modelo de negocio de AR verdaderamente prometedor. De AR aditiva, diría yo, y refiriéndome a algo que dudo pueda dar nadie aún como sería AR sustractiva.
Medio mundillo ayer dejó lo que tenía que hacer y hasta las tantas estuvo instalando, leyendo con los ojos ya achinados, y quizá soñando con lo que podremos hacer en breve. Creo que en todas las cuentas corrientes hay una reserva de 1000$ para pillarlo en cuanto salga.
Yo desarrollo en Unreal Engine, y el proceso de instalación, bien descrito por Magic Leap y Epic viene a ser el siguiente:
1.- Descarga del Magic Leap Package Manager. Para este paso, para este programa, para haberlo descargado y cada vez que se accede a él, hay que poner un «código secreto» diferente que te mandan al correo. No sé muy bien de qué van, pero es irritante.
En el que además de instalar el SDK, documentación y extensiones de Visual Studio podremos instalar ejemplos y documentación para las APIs tanto de Unity como de Unreal .
2.- Otra pieza clave es el simulador. Como es lógico, salvo unos cuantos privilegiados, nadie dispone de un ML One, por lo que para hacer los tests habrá que disponer de un simulador, de algo que emule el comportamiento del dispositivo. El ejecutable está escondido en una carpeta del SDK, la documentación dice dónde, puesto que cada instalación puede ser diferente.
3.- Hay una versión de Unreal Engine editor específica para Magic Leap. Descargable desde el Launcher de Epic tras haber realizado el paso anterior. Viene a ser una 19 «customizada».
4.- La página que ha preparado Epic con la documentación es una guía imprescindible. Hay que leerla, lo mismo para la documentación preparada por Magic Leap.
5.- Epic provee un ejemplo genial (LuminsSample) para ver cómo hacer de la mejor manera experiencias. Con el ejemplo cargado y en el mapa «PlayerLocationAndGaze» nos encontramos a un par de personajes de Robo Recall, cuya única misión en la vida será dispararnos.
Urgando ya en el editor tras haber descargado el ejemplo que provee Epic Games encontramos las plugin que permiten el gobierno del dispositivo y otras significativas: como Magic TV Apps o Analitycs que auguran, como ya se puede observar en la página web, una tienda, como ya las tienen Oculus, Vive y demás.
Variables de toda clase en Project Settings con tooltips interesantes que nos guían de por donde tienen planteado que vaya todo esto:
Interesante ver cómo montan el Level Blueprint
Pero sobre todo y especialmente el Pawn de ML, «LuminSamplePawn», mucho para analizar aquí, para entender cómo acceder a los muchos sensores del HMD, cómo acceder a los datos del Totem (el controller de MLO (MagicLeap One)). Tenemos mucho GetMotionController, como es costumbre, para interactuar con las experiencias que realicemos.
Por último en esta entrada mencionaré que insertar un nuevo nodo y comprobar la cantidad de nodos disponibles bajo la búsqueda MagicLeap es una delicia, nos hace imaginar la cantidad de cosas que podremos hacer.
Bueno, hay que volver a producción, al trabajo cotidiano, y seguir restando tiempo a nuestro poco tiempo libre para ponerse manos a la obra con todo esto. Semana Santa de lectura, me temo.
Y hablando de restar, termino con esta reflexión: la realidad aumentada es lo que dice por definición, aumentada porque suma, añade a la escena real. Sin embargo en muchas de mis aplicaciones profesionales, que tienen que ver con reformas, obras, etc, lo que sucede es que se modifica o derriba. Realidad DISMINUIDA. #Diminished Reality. ¿Cómo desde un ML One vas a mostrar esos patinillos que albergan unas bajantes ya inoperativas, modificados, reducidos? Algo que sólo se puede conseguir por ahora con Realidad Virtual, en la que todo el entorno es sintético.
Welcome to Light Fields!!! Ahora sí.
(Tres minutos de lectura, 6 enlaces, un video)
Llevo desde 2015 haciendo recorridos virtuales en pantalla o VR (Cardboard o WebGL) basados en imágenes esféricas, reales o sintéticas (aquí). En cualquiera de los dos casos, aunque fueran estereoscópicas el problema que tiene esta técnica en VR es que es sólo 3DoF, tres grados de libertad. Dicho de otro modo, si te mueves, si andas o te agachas, la imagen, la experiencia, se mueve contigo, lo que le resta de manera sustancial credibilidad. No es VR plena como sí lo es la que se renderiza a 90Fps a partir de modelos 3D.
Aunque se intentara 6DoF a través de un motor de render permitiendo ligeros desplazamientos dentro de una esfera en la que se proyecta la imagen equirectangular, el resultado seguiría sin satisfacer.
Desde hace ya bastantes años se persigue dotar a las imágenes de voxelización, por llamarlo de algún modo, una especie de píxeles volumétricos, para enterderlo fácilmente.
En inglés se llama LightFields y vamos a oir hablar de ello mucho a partir de ahora. Básicamente se trata de una función (plenóptica) que describiría la intensidad, dirección y polarización de cada rayo de luz que incidiera en una matriz de puntos (x,y,z) en un espacio concreto, matriz tan discreta como se quiera y permita la máquina que soporta los cálculos,. Como puede imaginar uno la cantidad de datos que esto supone es estelar, pero da como resultado que uno puede moverse dentro de una fotosfera, es decir fotografía 6DoF plenamente inmersiva y con multitud de aplicaciones en las que ahora no voy a entrar pero que están bien descritas aquí. De algún modo es como si tuviéramos un número masivo de fotosferas que describen lo que vemos desde cada una de ellas dentro de un ámbito. Evidentemente no se puede alcanzar tal número masivo por lo que se recurre a trucos e interpolaciones entre puntos dentro de ese ámbito.
Hasta ahora la aplicación a VR quedaba al albur de la imaginación puesto que fuera de los laboratorios no se había publicado nada, quizá en algún congreso. Los pioneros en todo esto, ya con resultados comerciales, han sido Lytro , quienes hace tiempo sacaron al mercado un par de cámaras para LightField 2D muy interesantes e incluso asequibles. Las de ahora son dispositivos, estos sí, masivamente caros y grandes, tanto que algunos se alquilan, no se compran, al menos hasta donde yo sé. Visitad la página y ved lo que tienen, que es espectacular, se ve pero no se toca, muy lejos de lo que podríamos considerar «mainstream»
El miércoles 14 de Marzo pasado me enteré por un tweet de Vrscout de que mi admirado Paul Devebec (que trabaja en Google) había sido entrevistado en el blog de Google y anunciaba una experiencia libre para HTCVive y OculusRift fruto de las investigaciones de su equipo, del «rig» de 16 cámaras que han preparado, de los cálculos que han implementado y de lo impresionante del resultado como para que la Nasa les haya dejado meterlo en un transbordador. Para mí supone un momento clave en la historia. Raudo descargué la experiencia de Steam y probé. Es sencillamente alucinante.
Como quiera que no muchos aún disponéis de modelo alguno de gafas VR de gama alta, me he decidido a grabar la experiencia en primera persona para que os hagáis una idea.
Esta misma técnica aplicada a imágenes sintéticas está siendo desarrollada, aquí ya no hacen falta cámaras reales, por Jules Urbach y su equipo de Otoy, es decir, rendear desde programas de síntesis de imagen para obtener el mismo resultado. Ahora bien, ¿qué será mejor en este caso, moverse en este tipo de imágenes prerenderizadas o moverse en un modelo 3D que es renderizado al vuelo? Por cierto, Lytro también está desarrollando en este contexto, pero al contrario que Google, no han publicado nada que pueda escapar a su control. ¡Error!
Por último, es evidente que todo esto es aplicable a video, por lo que podemos imaginar pronto el «video light field«, 6DoF total.
«Cordón umbilical» VR, ¿sí o no?
(Tres minutos de lectura, sólo 3 enlaces)
Vamos camino de los 3 años atravesando los páramos más o menos yermos de nuestro viaje por este territorio desconocido, expedito pero apasionante, hacia una nueva forma de comunicar intenciones, nuestros proyectos al fin, como es la Realidad Virtual.
Una nueva forma en la que todos los que estamos metidos en ella descubrimos métodos, desbrozamos caminos, nos metemos en laberintos y cosechamos fracasos y triunfos. Lo que es seguro es que nada está escrito, que hay unos pocos dogmas a tener en cuenta, y que una de las partes más importantes como es la experiencia de usuario y la interactuación en un paradigma virtual queda al albur de opiniones y vicios propios y ajenos.
He visto gente perderse, no saber cómo interactuar con partes «vivas» de un modelo por usar farragosos sistemas demasiado «gamer» . Cosas que NO suceden en la vida real no pueden ser replicadas con tanta alegría en un entorno VR para la gran mayoría de público empresarial porque el resultado será una mala experiencia de usuario (UX). Bastante tenemos con afianzar el sistema de movimiento por teleportación, que al final es el más intuitivo y menos mareante.
Una de las características que definen la VR HQ es el «cordón umbilical» al que me refiero al comienzo de este artículo. Creo que estamos cerca de prescindir de él, lo que redundará en una mejor UX.
Habrá quien diga: «pero si eso ya existe desde hace mucho: Gear VR, Daydream, …». Mire, eso NO es HQ bajo mi punto de vista. Podrán ser experiencias prerenderizadas, basadas en imágenes esféricas (360 3DOF), o quizá algo más elaborado 6DOF, pero con iluminación y texturas elementales, que en un estilo cartoon o gamer puede funcionar, pero no en experiencias de alta calidad. Olvídelo, no mienta. Nos valdrá para una promoción, una fiesta, un concurso, un regalo, una campaña publicitaria… pero no es 6DOF, no es HQ.
Una de las razones por las que la VR no encaja entre el gran público es que quienes lo han probado, lo han hecho en un móvil… Y creen que ya todo es así. Sin haber probado unas HTC Vive o unas Oculus Rift conectadas con su «cordón umbilical» a un PC de gama alta, no saben de qué estoy hablando. La otra es que necesitas un espacio en tu casa libre de obstáculos, espacio que suele haber en empresas y oficinas, pero no en casa.
Libres del cable, la UX HQ mejora sustancialmente, sin riesgo de pisar la manguera que alimenta tu experiencia. Tenemos así ya nuestro cálculo diferido en un PC con gráfica potente (980Ti mínimo) sin cable.
Dos son las opciones, mencionadas en un artículo meses atrás:
1.- ordenadores de mochila.
2.- recepción/transmisión inalámbrica
Los integrantes de la primera opción, que yo sepa, no han tenido el despegue necesario. Conozco compañías que anunciaban a bombo y platillo la idea y su desarrollo, pero no he pulsado la respuesta, no he visto el feedback esperado.
Y en mi opinión, ahora ya es tarde, debido al desarrollo de las segunda opción. TPCast ha vendido montones de unidades en el mercado asiático, y la nueva versión de HTC Vive, la Pro, puede venir acompañada con la antena que podéis ver sobre la cabeza de este señor. Los probadores de Youtube aseguran que apenas se nota en «Motion to Photon latency»: hay que evitar alejarse de los 11 milisegundos.
Por lo que creo que las mochilas quedarán relegadas para experiencias mayores a «room scale», «warehouse scale» he leído por ahí el término. En el momento en que se puedan utilizar más de 2 emisores (lighthouses) en Vive, por ejemplo, pero sin andar con código ni soldador…. Hay estudios que aseguran que se pueden enlazar espacios con múltiples faros, muchos…. Y hay instalaciones al efecto: The Void.
Más pronto que tarde entrará en este laboratorio una TPCast y/o la nueva Vive. Ya contaré.
¡Hola Vriverity!
El año pasado se cumplieron 21 años desde que decidí aventurarme por mi cuenta y riesgo en el mundo del 3d, infografías, o como se le quiera llamar. He visto nacer, desarrollarse y morir muchas empresas, muchos clientes, muchas iniciativas, unas de más duración, otras más efímeras. Creo haber superado un par de crisis que a muchos otros se ha llevado por delante.
Yo sigo aquí, haciendo lo que todos los que han confiado saben que hago y que no debo hacer mal cuando repiten, me recomiendan o vuelven. Pero uno ve venir los cambios: de la infografía para edificación residencial a la infografía para edificación singular tras el primer embite de la crisis, y de la edificación singular a los avances de obra 4D (de esto aquél nombre de 4dconstructionphasing) en el segundo periodo.
El segundo embite, ya saturado el mercado español, a obra pública me refiero, hace que todos miremos hacia el exterior, con mayor o menor fortuna.
Con tal de no tener todos los huevos en la misma cesta comienzo a formarme, a estudiar, a reciclarme, a mis 50 años: impresión 3d, un máster en BIM, un máster en Arquitectura Interactiva y Realidad Virtual y muchas, muchas horas, días, semanas y meses de estudio, restando casi todas las horas que tiene mi escaso tiempo libre. Han sido cerca de cuatro años de reciclaje y un dineral.
Dicho lo cual he montado una sociedad para dar lugar a todas las iniciativas que han ido madurando en mi cabeza y que unen BIM y REALIDAD VIRTUAL dando por superado, aunque no enterrado, el periodo de 20 años de servicios basados en imágenes estáticas y vídeos lineales. Y esto no para, hoy he terminado un cursillo de Power BI: estoy muy interesado en mostrar la ingente cantidad de datos que almacena un modelo BIM de una forma atractiva, y porqué no, en VR.
VRiverity ha nacido.
One click BIM2VR (o casi)
Quienes me conocen saben que llevo ya unos dos años sopesando el concepto de tiempo real de calidad y VR aportado por motores de gaming como Unity, Unreal Engine o Cry Engine aplicado a Arquitectura e Ingeniería Civil, coloquialmente AEC.
En noviembre de 2015 tenía listo un test formal para un cliente premium como Abbott Laboratories, división de diagnósticos automatizados. Fue realizado en Unity y testado en una Oculus DK2, con más o menos éxito y «Wows» varios. Un tiempo de desarrollo no adaptado a la dinámica del cliente dejó en el desván la iniciativa, decantándonos por recorridos virtuales apoyados en renders esféricos, como los ejemplos que hay en entradas anteriores a esta, mucho más rápidos de llevar a cabo, normalmente 3 o 4 días como mucho. Y han debido tener mucho éxito cuando no solamente los realizo para España y Portugal si no que están teniendo también una demanda notable en Reino Unido con esperanzas en Italia, Holanda y Oriente Medio.
Desde entonces y hasta ahora me he volcado mucho más en «BIMificar» las planificaciones a nivel de anteproyecto para licitaciones, teniendo como resultado la posibilidad de realizar hasta 6 opciones de una planificación de un laboratorio medio en menos de dos horas, por supuesto con todas las ventajas que aporta BIM a un LOD100. Para una multinacional que viene de planificar en Visio no está nada mal.
Pero durante los últimos meses he establecido más o menos el flujo de Revit a VR para ofertar modelos interactivos inmersivos en una semana realizados en Unreal Engine, el motor finalmente escogido por razones que ahora no vienen al caso. Faltan por adaptar unas librerías o assets a UE4 en VR (objetivo no superar 11 ms de latencia) como lo fueron adaptadas como familias en Revit para tenerlo todo hilado.
Durante este tiempo han ido apareciendo diversas soluciones de tiempo real. De entre todas ellas la más atractiva y con un grado de madurez cierto es Enscape. Algunos clientes hacen uso de ella y la considero relativamente buena a un nivel de calidad medio. No he tenido tiempo de testar el producto pero sé por ensayos publicados y terceros que es bueno según para qué objetivos. Fases tempranas de diseño y sin pedir un producto muy refinado son su nicho de funcionalidad. He descargado una demo no de fábrica, que amablemente Phil Read, CEO de Read | Thomas (y sosías del gran Phil Read, piloto mítico de motociclismo), deja para descargar de un producto que hace uso de una técnica que comenta en un post en LinkeIn. Me interesaba especialmente por venir de Revit de forma directa. En pantalla Full HD no va mal, bien de FPS, pero la iluminación no es nada del otro mundo, amortiguada en gran medida a través de Ambient Oclussion en Screen Space. No creo que hagan uso de GI bakeada. Materiales regulares, pero es una solución pura One click, por lo que no es la mía si no la de estudios y clientes con cierto grado de autonomía y conocimiento como para hacer tiempo real con herramientas como esta. La versión VR es tristemente inutilizable, al menos en un equipo que mueve algo tan refinado como Robo Recall sin despeinarse, por lo que este producto tal cual sale no me vale para VR, un mareo total. Quizá han olvidado activar algún parámetro para VR, porque me extraña lo mal que ha ido la demo. Aquí el game play de pantalla que sí va muy bien:
Otra cosa que me ha extrañado es la ausencia de colisiones, por lo que podemos andar por el modelo como un fantasma, atravesando todo. En VR no hay el equivalente a «navigation mesh» para teleportación lo que conduce a que a la mínima que queramos llevar al límite la experiencia acabaremos subidos en muebles y otras cosas.
Pero durante el último mes se han dado a conocer dos soluciones realmente disruptivas, como se dice ahora, en el escenario.
Twinmotion 2018
Una es Twinmotion 2018, de Abvent. Una solución que hace uso de UE4 como motor de render, e inspira por tanto la confianza de una calidad superior a Enscape y a años luz de LIVE. Tengo una beta recién descargada de la que haré uso la semana que viene si es posible y poder tener así una opinión bien fundada. Enlace directo a ArchiCAD y Revit, prácticamente una solución «One click» de alta calidad. Mientras tanto he descargado una demo que he testado tanto en modo pantalla como en VR y de la que ofrezco este gameplay de pantalla, porque la versión VR no me ha satisfecho. Quizá ha sido realizada con versiones precedentes a la que se ha publicado ayer.
Esta demo se centra principalmente en materiales, con todas las características que UE4 puede dar por sí solo. Hay que recordar que en tiempo real y aún más VR las texturas deben tener tamaños realmente considerables, lo normal es 4K, ya que es normal estar muy cerca de los objetos. Así, la memoria gráfica se puede saturar de mapas y comenzar el streaming o intercambio de mapas según necesidades. Bien, pues esta gestión en esta demo se ve realmente bien. Hay algunos objetos sin colisión y al poco de comenzar ya se ve un bug en navegación, pero bueno, la solución es realmente buena para acortar plazos. En VR tiene algunos problemas, no tantos como la mareante demo de Enscape & Read, pero los tiene: probada tanto en Oculus Rift como en HTC Vive, en ambos casos no he encontrado teleportación, ni forma de moverse ninguna. Al ponerse las gafas uno está a una altura que no le corresponde, por lo que algo ahí dentro no funciona bien. Y los fps no son estelares, más bien malos, nada que ver con apps más maduras y hechas a propósito de forma nativa. De hecho ya he preguntado si la app cambia de Deferred a Forward rendering.
Datasmith (ex Project Nile)
Lo que he realizado en los últimos meses, es decir, aprender el flujo de trabajo óptimo de un modelo BIM (Revit) a tiempo real y VR incluye una larga lista de operaciones creativas y trabajosas. Orientadas todas ellas al máximo de FPS, mínimo número de polígonos, bakeo de GI de calidad, rendimiento en ordenadores no gaming, programación de eventos, redes de navegación VR, unwrapping adecuados, materiales PBR, y más cosas. Muchas más. Al parecer Datasmith sería un middleware capaz de realizar bastantes de estos pasos de una forma automatizada, previsible y de calidad. Lo que nos podría conducir a ejecutables nativos, abiertos (Twinmotion da un resultado cerrado, no se puede abrir en UE4 en esta versión), escalables y buenos como si los hubiera hecho uno mismo. Estoy pendiente de que me aprueben mi solicitud a betatester. Si hay suerte podré testar, pero si no, tampoco es un drama. Sé que lo que debe dar es algo muy cercano a un trabajo puro realizado de manera amanuense y con la pinta de cualquier producto nativo UE4 bien hecho. Como no puedo colgar ninguno de los dos productos recientes que he realizado de esta manera en UE4 por razones de confidencialidad (siempre igual) pongo esta demo testada de los chicos de ArchVirtual, realizado eso sí, en Unity. Pero se trata más o menos de lo mismo:
¿La hora de VR HQ sin cables?
TPCAST montado sobre la Vive
Actualizado 2/8/2017 – SIGGRAPH Los Angeles
Presentada HP Z VR Backpack PC. La hermana «Enterprise» de la Omen.
Se afirma, y yo creo que es cierto ahora que Apple ARKit ya es un hecho, que este es el año cero de AR.
Como el año pasado lo fue de VR. Mientras AR y MR comienzan a despuntar, de lo que no cabe duda es de que VR sigue su camino con mejor o peor salud según los sectores y con la convicción, no sólo mía si no de muchas personas de diversos sectores con las que hablo, de que es en el sector «enterprise» donde está teniendo un inesperado mejor éxito que en el gamer.
De esto yo ya estaba seguro: el gasto de un equipo que entre pitos y flautas (con PC High-End incluído) se puede ir fácilmente a los 3000€ y el espacio requerido para vivencias «room scale» no está al alcance de cualquier adolescente pero sí de las empresas, especialmente AEC e industrial.
Este tipo de experiencias van ligadas a día de hoy sólo a Vive y Rift. Que no me vengan con historias, la potencia de una 980 Ti a un Titan X no cabe en un móvil por muy gama alta que sea, y las aventuras sin cable de Vive y Rift que tenemos en ciernes veremos qué aportan. Por ahora y para AEC enterprise sólo confío en estos modelos.
Hay un rasgo común que pesa sobre esta opción: el cable, el cordón umbilical que nos une a la potencia gráfica, a mover muchos polígonos con la deseada latencia de 11ms. Se enrolla, se pisa, se ensucia. Es incómodo pero necesario. Y además nos restringe a un área de actuación tan grande como lo que permite cada opción, unos pocos metros cuadrados.
Hace unos meses se han desbrozado caminos incipientes muy interesantes, que si quedan unidos a las tecnologías «inside-out» de posicionamiento de las gafas hermanas tipo Hololens o Daqri o de los desarrollos de Tango y ARKit nos podrían conducir a un concepto un escalón por encima: VR «world scale» de altas prestaciones.
Estos dos caminos son por un lado los PC’s mochila de HP(septiembre), MSI o Zotac y por otro los sistemas como TPCAST (Por ahora sólo en China).
HP Omen X VR en su dock
HP Omen X VR montada en el chaleco
En el caso de las primeras la idea es tan sencilla como crear un portátil de gama alta sin pantalla y bien nutrido de gráfica, meterle unas baterías bien grandes que garanticen suministro de corriente durante algo más de una hora, buena ventilación y colocarle un chaleco o correas que permitan ponérsela. La autonomía es segura, y el único problema es salirse del espacio destinado a VR y el peso sostenido durante mucho tiempo.
MSI VR One
En el caso del TPCast básicamente se trata de una conexión inalámbrica de 60 GHz para Vive (emisor y receptor), que se supone que perjudica lo mínimo la latencia. Transmite video y audio sin percibirse ninguna merma en la calidad, si el emisor está bien situado y no hay interferencias con otros canales Wifi. Aporta también una batería 20.100 mah, ojo, que alimenta la Vive y el propio TPCast, en un cinturón, durante más de 4 horas. Libertad total.
TPCAST Receptor
Sea la opción que sea la elegida se abren puertas que antes no teníamos y es la posibilidad de tener espacios «room scale» mucho más grandes, y aquí nos encontramos con el límite de los sensores y emisores de Rift y Vive respectivamente. La base tecnológica (outside-in) que emplean es muy precisa, para mí la mejor, dada en valores absolutos de 6 grados de libertad (9 con teleportación). Pero quizá sea el momento de pensar en una segunda ola de HMD’s de este tipo con tecnología inside-out, que siendo menos precisa bajo mi punto de vista ha mejorado muchísimo: la combinación de giroscopios de altísima calidad con la detección del entorno por medio de tecnologías como Tango y ARKit o sensórica móvil a partir de patrones de luz estructurada daría lugar a HMD’s de alta calidad con toda la fuerza bruta de gráfica delegada y «world scale». ¿Un sueño?. Antes de 2020 lo tenemos fijo.
Fig. 1: máquinas reales vs. máquinas virtuales peleando en un cálculo de lightmassing para una evaluación de un viaducto en fase de diseño para VR. Cada línea es un core, líneas cortas, proceso terminado antes, líneas largas, proceso de mayor duración o incluso sin acabar.
Con un título tan poco alentador cuelgo esta entrada que hace la número 100 en este blog.
Me suelen decir que mis artículos son demasiado técnicos, muy poco atractivos a la hora de evangelizar a las masas o de darme publicidad, pero sinceramente me da igual, ya hay quien se dedica a esos menesteres. Debo haber tenido algún antepasado luterano y así me va. Quien haya llegado aquí y no por desavisado, tendrá la oportunidad de comprobar como comenzamos la doctrina:
Según avanza el curso de Unreal Engine aplicado a arquitectura que voy haciendo (para corregir vicios y conceptos mal adquiridos) y según la carga de trabajo me permite (tarde, mal y nunca), voy por un lado ensamblando las piezas que compondrán mi flujo de Revit a Unreal Engine (BIM2VR) y por otro divagando con aventuras que creo que acelerarán ese flujo de trabajo hasta hacerlo tan cotidiano como un render de 3DSMax.
La calidad que se obtiene en UE4 responde a muy diversos factores siendo uno de ellos el cálculo de distribución de la luz, como sucede con motores de render como Vray. Si bien con objetos estacionarios o movibles y en exteriores se puede recurrir a iluminación en tiempo real, quienes desarrollamos no hemos de olvidar que el cliente ni tiene, ni tendrá máquinas como las que tenemos nosotros y que por tanto nos arriesgamos a que nuestra aplicación interactiva en tiempo real tan pulida, tan resultona y tan fluida sea un desastre en los ordenadores del cliente.
- Por tanto la primera premisa es: utilizar en lo posible iluminación precalculada, procurando tener un balance equilibrado en el número de mallas estáticas de tal forma que no las haya muy grandes que exijan mapas enormes ergo cálculos muy largos.
- La segunda es tener en cuenta el proceso distribuido, simétrico, paralelo que supone el cálculo de n lightmaps.
- La tercera es que la variable n vendrá dada en función del número de mallas estáticas que tengamos en la escena. Más o menos, y debido a que el algoritmo de lightmass decide por su cuenta o en base a escondidos parámetros guardados en algún .ini agrupar o no algunos lightmaps en atlas más grandes por optimizar recursos de memoria.
Aprovechando ofertas de amistades he dejado provisionalmente mi estudio como un taller de reparación de ordenadores, ya que en poco tiempo han entrado varios servidores (6) de todo pelo, desde «desktop» de los de poner en el suelo a un enrackable como el de la figura 2.
Fig. 2: esperanzador aspecto de la primera pantalla en el boot interminable de este System X
Me hacía especial ilusión que un IBM genuino volviera a entrar en mi vida. Aprendí a programar en los tiempos de los IBM PC y XT con pantallas de fósforo verde y cariñosas impresoras matriciales. Las características de este equipo hacían que aceptara la oferta de probarlo para cálculos que no tienen en principio nada que ver con los que llevaron a crearlo: 4 Xeon relativamente viejos (2010) que suman 16 núcleos y 128 GB de RAM. Puesto que un Windows normal sólo acepta 2 procesadores físicos, había que elegir entre Windows Server, Linux o algo para mí desconocido hasta entonces que es VMware ESXi. Opté por este último porque en su versión 5.5 es de libre disposición, muy contenido en su instalación, muy de pantalla de fósforo verde, es decir, textos y nada de interface gráfica y con un parque instalado suficientemente garantista.
Fig. 3: Interior del bicho
La modularidad de estos aparatos, en los cuales casi todo es intercambiable en caliente, es increíble. El arranque es eterno, debido entre otras cosas al número de tarjetas que traía instaladas y diversos chequeos.
Vaciado de todo lo que no era estrictamente necesario (tarjetas de red convencionales y fibre channel) e instalado el S.O., el arranque es ya más «rápido». En este momento deja de ser necesario monitor y teclado, puesto que todo el proceso de instalación de máquinas virtuales se realiza de forma remota desde VMware vSphere Client. Decidí crear dos, con las características que se puede ver en la figura 1.
Instalados los componentes que requiere Swarm Agent, Ip’s, parámetros varios y reconocidas las máquinas virtuales por Swarm Coordinator los cálculos de luz fluían…. como no esperaba, es decir, muy mal para los Xeones del servidor X. Y es que según las comparativas, estos procesadores son ya muy viejos y con unas características que se han visto superadas de largo por otros Xeon no tan antiguos e I7.
Días después realicé otras pruebas con otros servidores equipados con Xeon más recientes de hasta 16 cores que reafirmaron tan empíricamente la idea de que el x3850M2 ya no es una máquina para realizar cálculos de lightmass tendiendo en cuenta el nivel de ruido que tiene y sobre todo el consumo, más 1400 W de fuente de alimentación (redundante).
Fig. 4: lo que se llama «dar sopas con ondas» en relación a la Fig. 1. Todas son máquinas físicas.
Tanto en la figura 1 como en la 4 se pueden apreciar procesos acabados mientras otros siguen en marcha debido a que son cálculos de mayor envergadura (mallas estáticas más grandes) para los que se ha dedicado un solo core.
No sé en que medida la virtualización de máquinas recorta las prestaciones de unos Xeon de por sí anticuados, sin instalar un Windows Server que me permitiera ejecutar procesos distribuidos en 4 procesadores físicos no puedo más que especular, pero no voy a perder el tiempo, siempre tengo mucho lío y fechas de entrega muy cortas.
Lo que sí es cierto es que en el mercado abundan los servidores «enterprise» de tipo enrackable de características interesantes a unos precios muy contenidos, como este por ejemplo: HP Proliant DL580 G7 Barebone System 4x ten core e7-8867l/64gb memory / 2x 300gb 10k / rails / 4x psu
Este figura es un especialista, trabaja en un Data Center y sabe la tira, para quien quiera ahondar en este mundo.
Intuyo que esta abundancia de servidores sea debido a que se está produciendo una tendencia a evitar tener centros de cálculo «in house», por su coste de mantenimiento, por seguridad, por su coste de renovación y por su consumo, dirigiendo la demanda de proceso de cálculo a soluciones en la nube como Amazon Web Services, donde cada cual se puede alquilar por horas las necesidades de cálculo que requiera e incluso ofrecen máquinas preconfiguradas para procesos específicos.
IBM, HP, etc también llevan tiempo ofreciendo estos servicios. Si por consumo eléctrico fuera podemos utilizar las migajas.
A día de hoy están apareciendo tentativas, experimentos, aventuras de las que he hablado en LinkedIn como Project Nile, porting de Vray a UE4, nVidia VXGI, Light Volume Propagation, etc, todas ellas en fase experimental, y algunas con clara tendencia a Iluminación Global en tiempo real, (Otoy Octane integrado en el futuro Unity 2017 mete presión) sin embargo pienso que siempre será requerido el «cocinado» de luz para agilizar experiencias en equipos de rango medio, bajo o móviles, es decir, el parque de dispositivos más grande al que habitualmente optaremos para el destino de nuestros productos AEC.
«Mockups» para un nuevo analizador
Resultado final, y seguimos imprimiendo
Desde sus fases iniciales mi cliente me comentaba lo secreto del producto. Del cual ni ahora puedo mencionar su nombre. La competencia es feroz.
Como el uso de los kits impresos como éste ha sido todo un éxito, extendiéndose su uso en Portugal e Italia, y seguramente en otros países próximamente, por su versatilidad y la implicación en lenguaje natural del cliente final en la fase de diseño de la solución, pues tocaba realizar un modelo igual de versátil del nuevo analizador.
El analizador se compone de una serie de unidades que se ensamblan según las necesidades, es decir, está concebido bajo unos criterios de escalabilidad y flexibilidad. Por lo tanto el modelo que lo representa debía alumbrar desde su diseño primigenio las mismas características, y no plantearse representar las 4 posibilidades de configuración básica mediante 4 modelos diferentes, si no diseñarlo bajo los siguientes ideales de partida
1.- Mínimo número posible de unidades/máximo número posible de configuraciones
2.- Fácil conexión entre unidades
3.- Representación inequívoca de la realidad
4.- Resistencia al manipulado cotidiano (evitar anisotropía en impresión)
5.- Mejora en calidad de impresión vs. evitar material de soporte
Ya teníamos claro desde el principio que íbamos a modelar 4 unidades que iban a representar los 6 módulos reales posibles que ensamblados darían lugar al menos las 4 posibles configuraciones.
Versión 1
Veníamos de hacer uso de unas costumbres que funcionaban bien para los anteriores modelos del kit, es decir: layer de 0.2 y material de soporte. El resultado vino a ser tan malo como este:
Acabados malísimos debido a temperaturas y orientación de la impresión en el modelo inadecuadas
Machihembrado con buenos propósitos pero complicado de ajustar y frágil, detalles innecesarios, demasiado tiempo de impresión por ir con material de soporte y layer 0,1
La idea de imprimir «tumbado» venía sobre todo por una ligera pendiente que tiene el modelo en su parte superior y que prefería representar bien por la dificultad que tiene este tipo de «features» en impresión FDM si se quiere evitar el tedioso postproceso.
Versión 2
Lo más importante era simplificar el modelo sin perder la idea de lo que representa así como un machihembrado más resistente y fácil de ensamblar. Aún así el resultado seguía siendo bastante pobre, especialmente en algunas piezas.
Un machihembrado más sólido, pero difícil de manipular, demasiado ajustadas o demasiado flojas las tolerancias
Sigue habiendo fragilidad y acabado tosco
Esta versión seguía estando diseñada para usar material de soporte: «coffee break» para retirarlo con limoneno
Como todo plástico, el ABS tiene unas características térmicas de tolerancia para piezas que deben quedar ajustadas pero libres en su movimiento, por lo que hay que hacer muchas pruebas hasta dar con el modelo perfecto. Simplifiqué el modelo, sin embargo seguía siendo frágil al manipulado.
Versión 3
En la versión 3 decido cambiar la orientación de impresión, pero me encuentro con que algunas partes de alguna pieza, al ser de las últimas capas son impresas demasiado deprisa, no dando tiempo al ABS a enfriarse, y desvirtuándose por completo el resultado. El parámetro de «minimal layer duration» no funciona, por lo que decido hacer uso de «torres mártires» para obligar a que la duración de impresión por capa sea mayor. El uso de muros de limpieza laterales ayuda también a eliminar restos que quedan pegados en el extrusor, dando todo ello un resultado que mejora mucho las versiones precedentes. Seguía usando material de soporte, lo que sumado a layer 0,1 da tiempos de impresión muy largos.
Torres con igual altura que la máxima altura de pieza a imprimir y muros de limpieza
Cuidado al manipular, la impaciencia quema
Retirada de «rafts» y material de soporte, a pelo, sin limoneno ni nada porque con un nuevo diseño no hacen falta baños
Versión 4
Creo que esta fue la primera versión sin material de soporte. Engrosé también algunas características y dí aún mayor solidez a todos los elementos de cada pieza. En modelismo FDM no siempre es fácil representar a escala absoluta todo, ya que habría partes que físicamente no podrían ser impresas (mínimo ancho imprimible es 0,4 mm) y además resultarían muy frágiles para objetos que no son para estar en una vitrina y van a ser manipulados por mucha gente.
En esta versión las cosas ya van saliendo bastante mejor. El «despegue» entre las «shell» de lo que representa una pantalla es debido a que la dimensión no es múltiplo del ancho de extrusión, 0,4 mm, y además no cabe un «inshell». Hasta en eso hay que pensar.
Detalle de la evolución de los machihembrados, con un acabado tan tosco como el del «raft» que fue retirado
Versión 5
Sirvió para pulir algunos aspectos, mejorar tolerancias de montaje y reducir tiempos de impresión que aún así se van a casi 10 horas.
Bonito detalle de todos los elementos que conforman una unidad completa
Las distintas configuraciones posibles y en cualquier orden
Versiones 6 y 7
A alguien se le ocurrió rizar el rizo y probar a imprimir en dos colores puesto que no hacía falta ya material de soporte. La elección de colores fue corporativa del producto pero no nos gustó a nadie:
Versión 8 (5b)
El color verde es el de la línea gráfica del producto por lo que la decisión final fue hacer uso de él para diferenciarlo de otros analizadores. El resultado es el de la entrada y las imágenes que a continuación pego:
Cuando tras casi 7 horas de impresión ves esto te da una alegría. No todos los intentos acaban así: los atascos en extrusor por mala nivelación de cama son frecuentes, como el progresivo deterioro en el «kapton», o la limpieza necesaria en extrusor y rodillo de alimentación, por no hablar del deterioro de filamento por absorción de humedad…
Pequeño ejército de bribones que me dio mucho trabajo, y aún no hemos terminado, falta otra tanda al menos.
Vriverity 