Parte: 13 — VR, AR y experiencias inmersivas · Fuente: Khronos Group — OpenXR Overview y guías de diseño XR ⏱️ Duración estimada: 60 min · Nivel: Avanzado
La realidad extendida (XR) es el término paraguas que engloba la realidad virtual (VR), la realidad aumentada (AR) y la realidad mixta (MR). Cada una plantea un contrato distinto con el jugador: la VR lo aísla en un mundo sintético, la AR superpone información al mundo real y la MR combina ambos permitiendo que lo virtual reaccione al entorno físico. Entender estas diferencias no es teoría: determina el hardware, el presupuesto de rendimiento, el estilo de interacción y, sobre todo, el confort del usuario.
En esta clase construyes el mapa mental completo antes de tocar Godot. Verás los casos de uso donde cada modalidad brilla, por qué el mareo (cybersickness) es el enemigo número uno de la VR y cómo el rendimiento se vuelve una restricción de salud, no solo de fluidez. El laboratorio es analítico: partiendo de una idea de experiencia, elegirás VR, AR o MR con criterios explícitos y defenderás la decisión.
La decisión de modalidad es la más barata de cambiar ahora y la más cara de cambiar después. Elegir bien aquí condiciona positivamente todo el resto de la parte: qué hardware asumes (clase 229), cómo mueves al jugador sin marearlo (clase 232) y cómo diseñas la interacción con las manos (clase 233). Por eso empezamos por el panorama y no por el código.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | VR: inmersión total | El jugador sustituye su entorno; máxima presencia y máximo riesgo de mareo. |
| 2 | AR: superposición | Añade capas sobre el mundo real sin aislar; ideal para utilidad y contexto. |
| 3 | MR: fusión reactiva | Lo virtual respeta la geometría física; passthrough y anclajes espaciales. |
| 4 | XR como paraguas | Un mismo estándar (OpenXR) cubre todo el espectro. |
| 5 | Cybersickness | El mareo define límites de locomoción, fps y diseño. |
| 6 | Presupuesto de rendimiento | 72–90+ fps no es lujo: es requisito de confort físico. |
| 7 | Ecosistema de hardware | Quest, PCVR y AR móvil imponen restricciones distintas. |
| 8 | Grados de libertad | 3DoF vs 6DoF cambia radicalmente qué experiencias son viables. |
| 9 | Presencia | La sensación de "estar ahí" es la métrica de éxito de la VR. |
Esta clase es conceptual, así que no necesitas escribir código todavía, pero sí tener el marco correcto. Ten a mano la documentación de XR en Godot 4 (https://docs.godotengine.org/en/stable/tutorials/xr/index.html) y la OpenXR Overview de Khronos (https://www.khronos.org/openxr/). Si dispones de un visor (Meta Quest, por ejemplo) o un móvil con soporte AR, tenerlo cerca ayuda a intuir las diferencias.
Prepara una plantilla de decisión sencilla (una tabla) donde para cada idea anotes: nivel de inmersión deseado, movilidad del usuario, necesidad de ver el entorno real, precisión de tracking requerida y presupuesto de hardware. Esa tabla será tu entregable del laboratorio.
Como material de referencia, revisa un par de ejemplos comerciales por modalidad: un juego VR de acción (inmersión total), una app AR de medición o filtros faciales (superposición sobre el mundo) y una experiencia MR de decoración de interiores (objetos virtuales anclados a tu sala). Ver casos reales calibra tu intuición antes de puntuar tu propia idea.
Este laboratorio es analítico: elegirás la modalidad XR correcta para una idea concreta con criterios verificables.
Elige una idea de experiencia. Ejemplo de trabajo: "una app para practicar el montaje de un motor de bicicleta".
Redacta en una nota los cinco criterios de decisión: (a) ¿el usuario debe ver sus manos y el mundo real?, (b) ¿necesita moverse por un espacio?, (c) ¿la experiencia debe ocluir el entorno?, (d) ¿qué precisión de anclaje espacial exige?, (e) ¿qué hardware asumen los usuarios?
Puntúa cada modalidad (VR / AR / MR) de 1 a 5 en cada criterio. Para la bicicleta: ver el mundo real puntúa alto en AR/MR y bajo en VR.
Suma y contrasta. En el ejemplo, la MR (passthrough en un standalone) gana: el usuario ve la bici real con guías virtuales superpuestas y ancladas.
Justifica en dos frases por qué las otras dos modalidades pierden. VR aísla del objeto físico real; AR móvil obliga a sostener el teléfono y libera menos las manos.
Deriva tres implicaciones técnicas de tu elección. Para MR: necesitas passthrough, anclajes espaciales estables y un presupuesto de fps alto porque el confort no es negociable.
Escribe una conclusión de una línea con la modalidad elegida y la restricción de rendimiento asociada (por ejemplo, "MR standalone a 72 fps mínimos sostenidos").
Como validación cruzada, repite el análisis para una segunda idea de naturaleza opuesta (por ejemplo, "un shooter espacial frenético"). Observa cómo, para esta, la VR gana claramente: la inmersión total y el aislamiento del entorno son deseables, y el mareo se mitiga con teletransporte y una cabina fija como marco de referencia.
Contrasta ambos resultados en una frase: la misma matriz de criterios lleva a modalidades distintas según el objetivo. Esto demuestra que la elección es metodológica, no de gusto personal.
Aunque no toques Godot, este análisis es exactamente el primer paso de cualquier proyecto XR profesional y evita rehacer todo el diseño más adelante. Un error de modalidad detectado tarde obliga a rehacer arte, interacción y locomoción; detectado aquí, cuesta una tabla.
Guarda el documento resultante: será tu punto de partida en la clase 229, donde traducirás la modalidad elegida en requisitos concretos de hardware, y volverás a él en el capstone de la parte para justificar todas tus decisiones de diseño con una traza clara desde el concepto inicial.
Toma una idea de experiencia inmersiva (propia o asignada) y produce un documento breve de decisión que incluya: la matriz de puntuación de las tres modalidades sobre cinco criterios, la modalidad elegida, la justificación del descarte de las otras dos y tres implicaciones técnicas (hardware, tracking y presupuesto de fps).
Criterio de aceptación: el documento presenta una matriz con puntuaciones numéricas por criterio, una modalidad ganadora coherente con esas puntuaciones, y al menos tres implicaciones técnicas concretas (incluida una cifra de fps objetivo) derivadas de la elección.
| Síntoma | Causa y arreglo |
|---|---|
| Confundir AR con MR | AR solo superpone; MR ancla y ocluye. Aplica el criterio "¿lo virtual reacciona a la geometría real?". |
| Elegir VR "porque impresiona más" | La inmersión total no siempre encaja. Puntúa por criterios, no por espectáculo. |
| Ignorar el mareo en el diseño | El confort es de diseño, no de post. Decide locomoción y fps desde el inicio. |
| Asumir 6DoF sin verificar hardware | Muchos móviles/gafas son 3DoF. Confirma DoF antes de prometer movimiento libre. |
| Prometer passthrough en cualquier visor | No todos lo ofrecen con calidad. Verifica soporte MR del dispositivo objetivo. |
| Tratar el confort como un "arreglo final" | El mareo se evita en el diseño. Decide locomoción, marco de referencia y fps desde el concepto. |
❓ ¿La MR necesita gafas transparentes? No necesariamente. Muchos visores standalone hacen MR por passthrough: cámaras que muestran el entorno real dentro de una pantalla opaca.
❓ ¿Por qué se marea la gente en VR y no en AR? En AR el mundo real sigue como referencia visual estable. En VR todo el campo visual es sintético, así que cualquier discrepancia con el oído interno provoca conflicto.
❓ ¿XR es lo mismo que "metaverso"? No. XR es un conjunto de tecnologías; "metaverso" es un concepto de producto/mercado que puede o no usar XR.
❓ ¿Necesito hardware caro para aprender? No para esta clase. El análisis es conceptual; el hardware ayuda a intuir, pero puedes seguir el curso con el simulador de Godot en las clases prácticas.
❓ ¿Una experiencia puede combinar modalidades? Sí. Hay apps que arrancan en passthrough (MR) para situar al usuario en su sala y luego oscurecen el entorno para pasar a VR total. La clave es que cada transición sea deliberada y cómoda.
Clase 227 - Capstone Parte 12: un juego web publicado