Saltar al contenido

Vriverity, habilitada como operadora de RPA (Drones)

21 marzo, 2019
(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_Thread_use

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:

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.

DCIM100MEDIADJI_0024.JPG

Datos de posicionamiento de esta foto

 

Protegido: Revit to Unreal Studio beta plugin

13 enero, 2019

Este contenido está protegido por contraseña. Para verlo introduce tu contraseña a continuación:

UnrealStudio 4.21: plugin Revit a Datasmith

15 noviembre, 2018

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.

Revit_DS

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

Revitcategorias_como_capas

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.

Revit_tipos_como_SM

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.)

Revit_actores_con_hospedados_agrupan_elementos2

Revit_actores_con_hospedados_agrupan_elementos

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.

RevitMasterMaterial

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”

Revit_DS_Import_opsRevit_UvsRevit_Uvs_2

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

4 abril, 2018
DGX2

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 $

DGX1-4Voltas

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!

20 marzo, 2018

 

(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.

ML_Package_Manager

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.

ML_Simulator

 

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”.

ML_Launcher

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.

ML_UE_Editor_Sample

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.

ML_Plugins

Variables de toda clase en Project Settings con tooltips interesantes que nos guían de por donde tienen planteado que vaya todo esto:

ML_Platforms

Interesante ver cómo montan el Level Blueprint

ML_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.

ML_Blueprint_nodes

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í.

19 marzo, 2018
(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?

12 febrero, 2018
(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.

hp-omen-x-compact-desktop.jpg

2.- recepción/transmisión inalámbrica

vive-wireless-adapter2w.jpg

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é.