El retorno de PrioVR
14 FEB 2014 23:20
Alguien bajito, de color verde y maestro de Jedi dijo una vez: hazlo o no lo hagas, pero no lo intentes. Eso mismo han debido de pensar en PrioVR, que vuelve a la carga con una nueva campaña de Kickstarter después de que la anterior se quedase al 50% de financiación. Esta vez se han fijado un objetivo más alcanzable y nos ofrecen nuevos packs y un par de mandos, muy necesarios si pretendemos jugar. El competidor de Sixense STEM no se da por vencido.
PrioVR utiliza sensores inerciales de alto rendimiento para proporcionar un seguimiento de movimiento en tiempo real y con muy baja latencia en 360º, sin necesidad de cámaras, sistemas ópticos ni dependencia alguna de una línea de visión con el usuario. Los sensores se colocan en puntos clave de nuestro cuerpo y capturan nuestro movimiento y lo reflejan en tiempo real en la pantalla. Además de ello, PrioVR no utiliza cables para conectar con el ordenador y funciona en cualquier parte.
Hay tres versiones disponibles dependiendo del número de sensores: Core, Lite y Pro, y todas ellas incorporan un par de controladores con botones, gatillos y joysticks para tener un control total de nuestro alter ego virtual. Pero lo bueno de PrioVR es que, además de poder divertirnos metiéndonos en nuestros juegos de una forma nunca vista, también es un sistema de captura de movimientos de muy bajo coste, al menos en comparación con los precios de mercado de este tipo de dispositivos.
Como vemos, las diferencias entre los distintos packs radican únicamente en la cantidad de sensores.
- PrioVR Lite: 8 sensores repartidos entre nuestros brazos, cabeza y torso
- PrioVR Core: 12 sensores, los de Lite y 4 más en nuestras piernas
- PrioVR Pro: 17 sensores, los de Core y 2 más en las piernas, 2 en los hombros y 1 en la cintura
Todos los packs incluyen demos para que podamos experimentar desde el momento en que lo recibamos, que debería ser en junio de este año, si la campaña de Kickstarter logra su objetivo de $75,000, apenas un tercio de lo que pedían en la campaña original. Los precios de los tres packs se mantienen prácticamente igual que por aquel entonces (después de la rebaja que hubo a mitad de campaña), pero con la diferencia de que ahora se incluyen los dos mandos de control. Eso sí, si somos lo bastante rápidos, los podremos conseguir por $250, $309 y $350 respectivamente.
La campaña concluye el 31 de marzo y los kits se enviarán en junio de este año, un poco antes que los STEM de Sixense. Podéis consultar el resto de detalles en la página de Kickstarter, aunque os mostramos aquí un cuadro resumen con todas las opciones. Nos llama mucho la atención la de $500, con la cual nos convertirán en un zombi y saldremos en uno de los juegos incluidos con PrioVR.
Kun
#22 15 FEB 2014 19:56
Lo primero, me alegro de que hayan vuelto a la carga y de que ya se hayan financiado.
El hecho de que los dispositivos (en este caso STEM y PrioVR) utilizasen OpenVR (algo que aún no se ha anunciado) no acabaría con el problema.
¿Por qué? Porque luego hay que estar programando (implementando más o menos funciones según el número de sensores y también las mismas de manera diferente) dependiendo de cada dispositivo en cuestión.
Es decir, imaginad que sois programadores third party. Para un juego dado, primero debéis adaptarlo a las características de cada uno de los HDM para los que vayáis a programar (la RV empieza por el HMD) y me estoy refiriendo "simplemente" en desarrollar para que el juego se vea en las distintas gafas, no a las funciones especiales específicas que puedan incorporar cada una de ellas (las first serán las más interesadas en éste sentido)
Tras esto, cuando ya estés trabajando con los sensores de movimiento, hay que estar implementando más o menos funciones dependiendo del número de variables que tengas y en este caso, la cantidad está directamente relacionada con el número de sensores de cada dispositivo.
Si realmente quieres hacer las cosas bien y buscar el mayor nivel de realismo, ves que simplemente con un sensor más ya obtienes todo un conjunto nuevo de posibilidades y querrás explotarlo, no te limitarás a incorporar una pijada para justificar ese sensor.
Pero claro, al aumentar el número de variantes a programar, aumenta también la complejidad y con ello la cantidad de trabajo.
Dicho de otra manera (y es un ejemplo) tenéis que hacer una versión de vuestro juego para CastAR, otra para InfinitEye, otra para Oculus Rift, etc.
En estas versiones, vuestro juego debe ser completable sin usar sensores de movimiento más allá de los del HMD.
Aparte, hay que programar una versión para STEM, una versión para PRIO 8, otra (más compleja) para Prio 12 y otra (más compleja) para Prio 17.
En definitiva, un curro. Y esto es sólo el comienzo, tal vez en 1 año hayan más tecnologías alternativas. Posiblemente en unos meses los programadores se decanten por uno concreto.
Si yo fuese a elegir una tecnología, la compatibilidad sería una de las cosas a tener en cuenta. Tanto la del presente como la que crea que vaya a tener en el futuro.
Otro factor es la fiabilidad. Sixense es el sucesor de Razer Hydra y sabemos que son serios y trabajan bien, de YEI Technology no sabemos nada aún.
Para terminar, aprovecho que estoy escribiendo sobre el tema para decir que he visto ya dos detalles en esta gente que no me ha gustado.
No sé si lo recordáis pero hace tiempo hicieron un movimiento que en lo personal no me hizo mucha gracia por lo que denotaba. Aquí está mi respuesta.
www.realovirtual.com/es/noticias ... -de-priovr
Ahora resulta que pueden sacar el proyecto con el 33% de lo que pedían anteriormente y aún así ganar beneficios. ¿?
Entonces, ¿qué es lo que pretendían antes?
¡Sacarnos los cuartos!
A pesar de todo, tal y como han dicho en este hilo la relación número de sensores/precio es la mejor. Es justo mencionarlo también.
Hace tiempo comenté en otro hilo que tenía la impresión de que los wrappers podrían cobrar una importancia notable en un futuro. Me reafirmo.
Otra cosa será ver si las funciones que obtendrás al usar más sensores justifican la inversión, porque con un wrapper no se podrán implementar las mismas funciones que trabajando nativamente.
Ejemplo: Dado un juego sin soporte nativo para sensores de movimiento y teniendo en posesión dos sensores, con un wrapper se podrá hacer lo siguiente:
"Cuando levante y pose tal pierna, equivale a un paso y por ende el personaje se desplazará tal cantidad en el escenario", pero no se podrá implementar el pegar patadas si no es una función incorporada nativamente en el juego.
De todas formas, no creo que tarde mucho en aparecer una empresa cuyo proyecto sea un traje que cubra todo el cuerpo hasta el cuello, ideal para una versión inalámbrica del Rift.
Mientras tanto, la miniaturización sigue avanzando a paso firme.
¡Un saludo a todos!
jahrv
#23 16 FEB 2014 0:29
Kun, el tema de implementar los juegos con PrioVR, Stem o lo que venga no lo veo como tú.
Habrá una API standar, de Valve, que ya ha echado a andar, y luego los dispositivos como PrioVR o Stem lo que aportarán a los juegos es la posición de todas las articulaciones (el mocap http://en.wikipedia.org/wiki/Motion_capture). El cuerpo humano se puede simplificar en un juego a un armazón de 10 a 12 articulaciones. Con que los juegos sepan que el dispositivo de entrada le va a dar la info de la posición de esas articulaciones es suficiente. Es como los joysticks, hay muchos y variados, pero al final tu tienes una pantalla de configuración donde le dices al juego qué hará cada botón o cada toque de palanca. Y en cuanto a las gafas pasará lo mismo. Como dispositivo de entrada, las gafas de Oculus son una cosa muy simple, pues sólo aportarán los tres giros y los tres desplazamientos de la cabeza. No va a haber unas gafas que aporten más, quizá menos. Si un dispositivo de entrada aporta menos, como es el caso de Stem, que sólo contará con 5 trackers, el sistema de Sixense interpolará y ofrecerá una aproximación para lo que falta. Al final todos los aparatos, en cuanto al input, aportarán lo mismo, unos valores de x, y, z y unos giros. Ya hay mucho hardware de captura de posición como TrackIR y demás, y ahí tienes OpenTrack. Juanlo nos mostró un estupendo video de Outerra con una solución casera para el tracking que le falta al DK1, y no tuvo que recodificar el Outerra o bajarse una versión específica.
Todos los dispositivos se podrán integrar con facilidad en cualquier juego de RV, y no habrá que recodificar ningún juego ni habrá versiones de juegos para cada dispositivo. Eso quizá te pase con los dispositivos que pueda sacar Sony, que seguro que los harán incompatibles para amarrarlos a su PS4.
Laugt
#24 17 FEB 2014 0:41
Sigo pensando que ambos tienen la gran pega del coste, alrededor de 300 € para un sistema de control me parece excesivo, aunque no sea aquí una opinión generalizada. Ya me parece excesivo el coste de kinect por ejemplo y es 1/3 de la media de estos sistemas.
Opino que la gente esta muchísimo mas dispuesta a gastarse los 300 en oculus, porque bueno una tele hd viene a costar por ahí, que a gastárselos en un sistema de control, no hablo de el grupo concreto de gamer´s pro, por llamarlos de algún modo, sino al grueso de consumidores
Kun
#25 18 FEB 2014 19:15
Buenas jahrv, voy a responderte por partes y ordenándolas según la importancia que les doy.
¡Sin problema! Aquí no creo que nadie vaya a tener nunca un problema conmigo por pensar diferente, no sólo porque me gusta que la gente deje ver sus puntos de vista, sino porque tolero todas las opiniones, las comparta o no. Además, en este caso tu discrepancia me ha venido bien como verás a continuación así que aprovecho para agradecerte que te hayas animado a responder
La idea que tú comentas no sólo tiene sentido sino que, tras haber estado viendo varios videos (no sólo de PrioVR y STEM sino también de otros dispositivos) observo que ese sistema es el estándar que están implementando los desarrolladores para aplicaciones de Realidad Virtual, algo que yo desconocía por completo (se nota que no acostumbro a ver los videos de éste tipo de hardware, ¿no? )
Así que por si a alguien le surgieron dudas a raíz de leer mi comentario anterior, aclaro que la parte relativa a cómo creía que se implementarían los juegos utilizando estos sistemas no es correcta, será sustancialmente más sencillo y también más fideligno con respecto a los movimientos de las personas en el mundo físico (¡más inmersión aún!)
Yo pensaba que había que estar implementando artesanalmente más secuencias de animaciones, pero el tener un número de sensores suficientes (y gracias a la interpolación, como bien dices) permite representar un cuerpo entero digitalmente y además, realizar un mapeo de los movimientos relativamente fideligno y suficiente para la mayoría de los juegos.
Va a ser importante el número de sensores que se compren pues necesitaremos tener un número mínimo para poder representar según qué movimientos.
Dejando a un lado el tema de los sensores, donde también va a haber diferencia de unos dispositivos a otros es en el resto de canales de entrada de datos aunque esto es extremadamente sencillo de adaptar porque al fin y al cabo no son más que mandos con más o menos botones/crucetas/sticks/gatillos etc.
Sí, como mínimo (y menos mal) sabemos que estará el Steamworks VR, el cual ayudará a desarrolladores de dispositivos.
Primero tendrían que anunciar el soporte. De todas maneras, a pesar de ser una ayuda de cara a la puesta a punto de los dispositivos y también en términos de compatibilidad con los juegos, no todos los dispositivos de RV están obligados a usar ese estándar. Algunos tal vez no quieran depender de Valve, otros prefieran utilizar su propio software, aún pueden nacer otras alternativas, etc.
A pesar de ello y teniendo en cuenta cuál es el contexto en que se encuentra actualmente la RV (despegue) veo bastante probable que la utilicen.
He visto que a veces en vez de situar el sensor en una articulación, lo ponen en otra parte del cuerpo como puede ser un antebrazo o una pierna, pero esencialmente la manera de trabajar es similar.
El desarrollador debe modificar la imagen que manda a la gafa según el tipo de lente y el panel de la misma. Como bien se comenta en el último Rovcast, es algo que se hace en horas.
Realmente es poco trabajo pero también hay que tenerlo en cuenta y por eso lo comenté. A esto me refería cuando escribí "primero debéis adaptarlo a las características de cada uno de los HDM para los que vayáis a programar (la RV empieza por el HMD) y me estoy refiriendo "simplemente" en desarrollar para que el juego se vea en las distintas gafas"
Sobre las "funciones especiales específicas que puedan incorporar cada una de ellas (las first serán las más interesadas en éste sentido)" me estoy refiriendo por ejemplo a la estimulación vestibular galvánica que Oculus tiene intención de implementar en futuras versiones.
http://medgadget.es/2010/08/la_estimulacion_vestibular_gal_1.html
/*---------------------------------*/
Viendo ésto del mocap y como funcionan éstos dispositivos, posiblemente en poco tiempo hayan discotecas virtuales online donde cada uno de los participantes pueda hacer gala de sus dotes cinestésicas.
Alguien a sus amigos del mundo físico, en vez de decirles "nos vemos esta noche a las 23:00 en el Pacha", les dirá: "Hey, nos vemos a las 23:00 en la Palmer Disco" y no tendrá que ducharse ni arreglarse para salir XD
Una vez en las discotecas, imagino que alguno se aprovechará del anonimato para hacer gracia y dar la nota haciendo según qué gestos con atuendos llamativos en medio de la pista de baile Puede ser una risa total.
Es decir, imagina estar en la discoteca virtual, ves por un lado a gente que " se toma en serio" Se ponen a hablar en la barra, a bailar, etc. pero por otro, miras al centro de la pista de baile y ves a un tío haciendo gestos "políticamente incorrectos" de todo tipo, qué risa.
1.bp.blogspot.com/_9sJQa_4QBEI/S ... 282%29.JPG
Aprovecho que estoy comentando sobre los juegos ONLINE para decir que tengo interes (no sé si vosotros también) en conocer hasta qué punto afectará el lag de las redes FTTH en las experiencias RV. Por ejemplo, hasta qué punto permiten que algo sea jugable sin marearse. Me parece algo importante a tener en cuenta para juegos online como los de tipo Second Life.
La distancia a la que estén los servidores de los juegos es un punto a tener en cuenta pero de por sí la FTTH incorpora unos ms de retardo a sumar con los del HMD etc.
Me imagino que en Internet se crearán hilos en un futuro próximo sobre este asunto "¿Qué tal os va tal juego con tal conexión desde Sevilla?" "¿En qué servidor jugáis?" "¿Jugaré bien con X ms de retardo?" "¿Cómo saber el retardo que voy a tener sin tener que instalar el juego?" "¿Cómo hacer un ping a tal servidor?" Y posiblemente haya también gente que elija operadora de Internet y el HMD en función de la latencia.
Por si a alguien le interesa el tema y los valores que está dando la fibra en España, he encontrado algunos hilos al respecto.
http://bandaancha.eu/foros/latencias-cable-ono-vs-ftth-movistar-1707021
http://testvelocidad.eu/velocidad-ftth
http://www.adslzone.net/postt286347-45.html
Os dejo por aquí también algunos videos del funcionamiento de PrioVR y de STEM:
(Aquí se ve que no siempre se han de poner en articulaciones)
Saludos a todos y gracias nuevamente a jahrv por responderme