TrainBeyond — Player de capacitación / Training Player

La capacitación de una unidad como aplicación propia: qué ve y hace el alumno, cómo se publica y cómo se prepara una unidad. La propuesta interactiva tiene su propia documentación: Propuesta interactiva. / A unit's training as an app of its own: what the trainee sees and does, how it is published and how a unit is prepared. The interactive proposal has its own documentation: Interactive proposal.

---

ESPAÑOL

1. Qué es

El player es la capacitación de una unidad como aplicación propia, separada de la propuesta interactiva. Vive en DEMO: https://demo.trainbeyond.com/player/CODIGO/ (ALF, TAC…). La escena 3D, las estaciones, las lecciones, la guía de voz y las revisiones son las mismas piezas de la propuesta (los capítulos 4 a 8 y 10 se comparten tal cual con ella); lo que cambia es todo lo que rodea al ejercicio:

• Un módulo del LMS con sus ejercicios. La unidad es un módulo de la plataforma de capacitación (LMS) con tres ejercicios por defecto (Tutorial, Revisión Teórica y Práctica) y un examen del módulo.
• La pantalla del módulo es la portada: la escena entera como maqueta viva, con una píldora por ejercicio y otra para el examen.
• El LMS abre el player con la identidad del alumno, y cada resultado vuelve al LMS.
• Sin presentación comercial: ni galería de paneles, ni presentadora, ni presupuesto.

La propuesta interactiva (paneles, presentadora, /gen-proposal) se documenta aparte: Propuesta interactiva.

2. Qué ve y hace el alumno

2.1 Entrar

El alumno entra a la plataforma (LMS) con su usuario y abre el módulo; el LMS lanza el player con su identidad. Primero se ve la pantalla de carga del LMS, con el nombre del módulo y de cada ejercicio, mientras se descarga la escena; después, la pantalla del módulo. Sin el LMS, el player también se abre con el código de acceso de la unidad (para pruebas). En DEMO, el usuario Test Owner de la organización de cada unidad entra con el código de acceso de la unidad como contraseña.

2.2 La pantalla del módulo

• La maqueta viva. La escena entera como maqueta, centrada y cortada solo en altura para ver el interior (sin base redonda), con la acción en marcha: si el archivo de Blender trae acciones Demo_ (la demostración que preparan los diseñadores, por ejemplo el Brokk derribando un muro), se reproducen en bucle junto con las Loop_; si no, el avatar recorre las estaciones en orden y los puntos interactivos de cada una, con sus animaciones, mientras corren las Loop_.
• Las píldoras. Una por ejercicio y una para el examen, cada una cerca de su lugar en la maqueta y unida a él por una línea corta, con su estado: sin empezar, en curso, aprobado con su nota o no aprobado. La Práctica se desbloquea al aprobar la Revisión Teórica (salvo que el LMS la abra directamente). El examen aparece cuando el LMS permite un intento.
• La insignia (arriba a la izquierda): el alumno, el módulo, cuántos ejercicios lleva aprobados y el botón Volver a la plataforma.
• La música. Una pista suave de fondo, de la biblioteca de con-mgr, que empieza con el primer clic (los navegadores no dejan sonar antes) y se apaga al entrar a la escena.
• La tarjeta de inicio. Un clic en una píldora entra al ejercicio; su tarjeta de inicio se muestra dentro del ejercicio, en la escena (no en la pantalla del módulo): el nombre del ejercicio, su misión (las tareas en orden), los controles y «Haz clic en cualquier parte para empezar», con la música de inicio de ese tipo de ejercicio. Si el alumno dejó el ejercicio a medias, la tarjeta dice dónde sigue («Continúas donde lo dejaste: tarea 3 de 8») y ofrece Empezar de nuevo.

2.3 Los ejercicios

Los ejercicios, sus nombres y resúmenes, y cuáles entran en el examen se definen en el archivo de configuración ([module.*], capítulo 10.4); sin ellos, el módulo trae los tres estándar.

2.4 Dentro de la escena

Dentro de la escena todo funciona como en la propuesta. Lo que sigue es esa misma descripción (donde dice «el cliente», léase «el alumno»):

La visita es un ejercicio por tareas: las estaciones, en su orden, son las tareas. La instrucción de cada una es la nota de la estación, y lo que hay que hacer ahí son los objetos interactivos junto a ella (el hotspot, la hoja, la persona, la pantalla, los controles). La guía pide una tarea a la vez, al llegar explica la estación y dice qué hacer, confirma cada tarea cumplida, da una pista cuando el cliente se atasca y cierra con una retroalimentación. La lista aparece a la derecha, con las hechas tachadas; se pueden hacer en cualquier orden. (El panel de ajustes permite volver al recorrido narrado o dar la tarea por hecha solo con llegar.)

Lecciones. Cada estación tiene una lección escrita al publicar a partir del material del cliente y de la configuración de la escena, con su infografía. Al llegar, la guía la enseña completa, una parte por turno; con infografías, cada una aparece al nombrarla. El botón Lección de la lista hace que la guía la enseñe otra vez desde el principio, sin cambiar ninguna tarea. Las preguntas de la revisión salen de esa misma lección.

Pantalla de inicio. Al entrar al ejercicio (y tras reiniciarlo) aparece una pantalla con la frase de bienvenida, la misión (las tareas en orden, con el número y nombre de su estación) y los controles, con su propia música. La guía calla al instante al abrirse (también si venía hablando) y no dice nada hasta que se cierra: un clic en cualquier parte de la pantalla, o sola a los tres minutos (ajuste).

Evaluación. Al terminar cada tarea, la guía hace dos preguntas cortas sobre esa estación, sacadas de lo que acaba de enseñar (el material de la propuesta y la configuración de la escena). Cuando ella termina de preguntar aparece una tarjeta en el centro de la pantalla con sus palabras, una línea para escribir la respuesta y un botón No sé; mientras la revisión está abierta el cliente no puede caminar ni activar nada. Responde de viva voz (el micrófono se abre al terminar la pregunta) o escribiendo; ella califica cada respuesta de 0 a 100 y la lista muestra la calificación de cada pregunta y el promedio de la estación ("100 · 0 → 50 %", verde si aprueba, rojo si no). Una calificación cuenta solo después de que el cliente haya hablado o escrito; si la guía califica antes, esa nota se descarta y repite la pregunta. Mientras la revisión está abierta, nada más llega a la guía. Una pregunta sin respuesta en tres minutos vale 0 y se pasa a la siguiente. Tras cada respuesta ella dice cuál era la correcta y por qué: una frase si acertó, dos si falló. La rúbrica (100 completa y correcta · 80 una omisión menor · 60 la idea principal · 30 relacionada pero incorrecta · 0 incorrecta o sin respuesta; solo contra el material de la propuesta) y todas las instrucciones que la página le da a la guía están en el panel de ajustes, grupo "Instrucciones a la guía", y se guardan por unidad. La tarjeta aparece cuando la acción terminó por completo y ella acabó de preguntar. Al accionar un punto interactivo, la guía dice en una frase qué acaba de hacer el cliente y confirma que quedó hecho. Mientras dura la acción, un recuadro muestra de cerca el instrumento o pieza que la animación mueve, para leer su valor; si el punto trae una nota con la lectura, ella la dice al terminar. Con todas las tareas hechas y revisadas viene el examen: el cliente repite todo el ejercicio solo, en el orden correcto, sin lista, sin números de estación y sin ayuda; la guía guarda silencio hasta el final. Llegar a una estación es acercarse a ella caminando (o con su marcador, fuera del examen); la estación donde empieza el examen cuenta solo después de alejarse y volver. Se aprueba completando todas las tareas con al menos el 70 % en su orden y con el promedio de las revisiones de las estaciones en o sobre esa misma nota mínima (ajuste checksCount; apagado, decide solo la práctica). El informe muestra las dos partes con su propio resultado. Al terminar, ella cierra con el resultado del examen, el de las revisiones y una retroalimentación breve, y se abre el informe del examen: aprobado o no, tareas en orden, tiempo, y la calificación de la revisión de cada estación con su promedio (verde aprueba, rojo no); suena la música de éxito o de fallo mientras el informe está abierto. Desde el informe se cierra o se reinicia el ejercicio; el botón Informe del resultado lo vuelve a abrir. Si el cliente sale de la escena con el informe abierto y vuelve a entrar, el informe aparece de nuevo, con Cerrar y Reiniciar; si recarga la página, el ejercicio empieza de cero. (Preguntas por estación, examen y nota mínima se ajustan en el panel.) El informe final ocupa casi toda la pantalla, en tres pestañas: Resumen (resultado, nota y nota por estación), Plan de estudio para el siguiente intento, que la página arma con las propias láminas (por cada pregunta fallada: la lámina que la enseña, citada, y qué hacer en la escena: repetir esa lámina con el botón Lección y pulsar los objetos de la estación), y Preguntas y respuestas (cada pregunta con tu respuesta, la correcta, el comentario y la frase de la lección que la enseña). El botón Descargar PDF guarda el mismo informe como archivo PDF; la casilla «Incluir la transcripción completa de la sesión en el PDF» (desmarcada por defecto) añade al final del PDF todo el diálogo de la sesión, con las líneas que tratan los temas del plan de estudio resaltadas y el tema indicado debajo. Al cerrar el informe, los datos del ejercicio se conservan en el navegador: en el panel de configuración (Ctrl+Shift+K), «Informe: datos guardados» permite abrir de nuevo el último informe, guardar los datos en un archivo y cargar un informe desde un archivo, sin repetir el ejercicio.

El micrófono dentro de la escena tiene dos estados, abierto y cerrado, y la insignia de arriba a la derecha dice cuál. Se abre solo cuando la guía escucha: unos segundos después de cada intervención suya, y mientras el cliente siga hablando. Caminando, con una hoja abierta o mientras ella explica está cerrado: el ruido de la sala no le llega. Para hablarle en cualquier otro momento, mantén pulsada la tecla M o haz clic en la insignia. En el visor VR no hay teclado ni insignia: se mantiene pulsado A o X en cualquiera de los controles, y un letrero bajo la vista dice si el micrófono está abierto ("Te escucha") o cómo abrirlo. Mientras una pregunta de revisión espera la respuesta, en el visor ella escucha entre sus turnos sin tener que pulsar nada (en VR no hay dónde escribir la respuesta).

Con un Avatar entregado, el cliente recorre la escena como un personaje (tercera persona por defecto); en VR ve su propio cuerpo del cuello hacia abajo y, con manos rastreadas, sus manos reales mueven las del avatar.

2.5 El informe y la plataforma

Al terminar, el informe del ejercicio (Resumen, Plan de estudio, Preguntas y respuestas, Descargar PDF) muestra además qué pasó con el resultado en el LMS:

• «Guardando el resultado en la plataforma…» mientras se envía;
• «Resultado guardado en la plataforma.», con Ver el informe (el informe del LMS) y Volver a la plataforma;
• si el LMS no contesta a tiempo, el player busca el resultado en el avance del alumno antes de ofrecer nada («Comprobando en la plataforma si el resultado se guardó…», y luego «Tu resultado ya aparece en la plataforma.»); nunca lo envía dos veces por su cuenta;
• si el LMS lo rechaza, el informe lo dice, con el motivo que da el LMS.

Cada ejercicio envía su resultado con su propio código; el examen, el resultado del examen del módulo. Al volver, la pantalla del módulo muestra la nota nueva.

2.5b La tableta

Dentro de la escena, el botón Tableta (T) (o la tecla T) abre la tableta del alumno, que se ve y se usa como un iPad. Abajo, una barra con sus tres apps, Videos, Documentos y Llamadas, con la elegida resaltada. La tableta se abre en la última app elegida.

• Videos: miniaturas grandes (un cuadro de cada video) con título y duración. Cada uno se abre en un reproductor con reproducir/pausa, barra de tiempo y duración.
• Documentos: miniaturas grandes (la primera página de cada PDF) con título y número de páginas. Cada uno se abre en sus páginas (‹ › para pasarlas).
• Llamadas (con video o solo voz, según el contacto): los contactos en fotos grandes. Sin foto, un contacto con Gemini Live Avatar muestra la imagen de ese avatar (Ben, Ingrid, Jay, Kira, Paul, Sam o Vera, guardadas con el player y recortadas como su video); si no, su avatar de voz; sin avatar, sus iniciales. El Mentor es la mentora del player, no la presentadora de la propuesta: su nombre viene del perfil global (Camila Rojas) y así se presenta en la sesión en vivo; live_avatar (Kira) es solo el identificador de Gemini para su foto y su video. El único video del player es el de una llamada de la tableta: la guía en la escena es solo voz. Llamar a un contacto con live_avatar (el Mentor incluido) abre una sesión de video propia con su Gemini Live Avatar, que termina al colgar; mientras llega el video, la llamada muestra la foto de su Live Avatar. Un contacto sin live_avatar muestra su avatar de voz: un presentador 3D en primer plano que mueve la boca con su voz. El Mentor es la guía del ejercicio, en una llamada propia. Cualquier otro contacto es su propia persona en vivo: responde con su voz y desde el material de la unidad, en su papel. La guía calla mientras dura la llamada.

Si hay más miniaturas de las que caben, se pasan de página con ‹ ›. La barra de inicio o el botón de volver regresan de un video, un documento o una llamada a su app. La tabla [tablet] del archivo de configuración dice qué hay en cada app y en qué orden (capítulo 10.4); el perfil del Mentor viene de la configuración global. En el visor (con controles o con las manos) la tableta es un panel delante del alumno: se abre con el pequeño botón abajo a la izquierda de la vista, y todo se acciona apuntando y pellizcando (o con el gatillo). Si no hay nada en la tableta ni guía (la Práctica sin [tablet]), el botón no aparece.

2.6 Salir, volver y reiniciar

• Esc sale de la escena a la pantalla del módulo; el avance se conserva y la tarjeta de inicio ofrece seguir donde quedó.
• Reiniciar progreso (abajo a la izquierda en la pantalla del módulo) borra en este navegador el avance de todos los ejercicios del módulo y del examen, como el reinicio de módulo de Unity (PROP-61). Lo que la plataforma ya registró no cambia. Dentro de un ejercicio ya no hay botón de reinicio en la lista de tareas.
• Empezar de nuevo (en la tarjeta de inicio de un ejercicio) y Reiniciar el ejercicio (en el informe) empiezan ese ejercicio otra vez, como un intento nuevo: vuelven la tarjeta de inicio, la bienvenida y la primera lección.
• La revisión de una estación en curso también se conserva: al salir, recargar o cerrar el navegador, vuelve en la pregunta en que iba, con su tarjeta, y el alumno la contesta allí (PROP-55). Una pregunta ya contestada no se repite.
• Un ejercicio terminado no se reanuda al abrirlo otra vez: empieza de cero.

3. Cómo se publica

3.1 Las fuentes

• El archivo de Blender de la unidad, en Google Drive: la escena, sus estaciones, controles y animaciones (capítulo 8).
• El archivo de configuración de la escena (TOML, capítulo 10). La primera publicación lo toma de Drive; desde entonces la copia de referencia vive en el gestor de contenidos (con-mgr, instancia DEMO), y las publicaciones siguientes la leen de ahí.
• El material de capacitación de la unidad (manuales, procedimientos), en Drive: de él salen las lecciones, las preguntas y, si el archivo no los da, los nombres y resúmenes del módulo y de los ejercicios.
• La música, de la biblioteca de con-mgr.

3.2 El comando

En Google Chat, /gen-player CODIGO. La publicación:

1. arma el paquete del player: la escena convertida desde el Blender, las lecciones, la voz de la guía grabada una sola vez con el mismo modelo de la guía en vivo (y reutilizada en las publicaciones siguientes), la música y el icono del módulo, renderizado desde el Blender (con su Icon_Camera si la escena la tiene);
2. prepara el LMS en DEMO por Support Admin, solo lo que falte: la organización de la unidad, su Test Owner (con el código de acceso de la unidad como contraseña), el módulo y sus ejercicios; nunca edita lo que ya existe;
3. publica el player en https://demo.trainbeyond.com/player/CODIGO/.

3.3 Qué devuelve

La dirección del player; cuántas lecciones y grabaciones tiene, y cuántas se grabaron esta vez; el módulo del LMS y si se creó o ya existía; y los avisos (capítulos 10.3 y 10.5).

4. Convenciones de nombres — referencia rápida

El visor no se configura: lee los nombres de los objetos y de las acciones del archivo de Blender. Lo que no coincide con ninguna convención es escenografía normal. Los nombres se comparan sin espacios sobrantes y sin distinguir mayúsculas; el separador puede ser _ o ..

Propiedades personalizadas (Object Properties → Custom Properties) que el visor lee:

Varios objetos en una acción: pistas NLA con el mismo nombre en cada objeto (Play_Arranque en el botón y en el pistón) se exportan como una sola animación. Así se hace que el botón se hunda y la máquina responda, o que la perilla gire y la aguja la siga.

Restricciones de huesos (máquinas): el visor resuelve en vivo, como Blender, estas restricciones de los armatures de la escena: Damped Track; Copy Location y Copy Transforms entre huesos del mismo armature, en espacio mundial; IK de una o dos huesos sin polo (con los bloqueos y límites de IK de sus huesos); Limit Rotation y Limit Location en espacio local. Así, con varias acciones a la vez (la pluma y el brazo), los cilindros siguen apuntando a sus soportes, las mangueras siguen sus puntos de control y la herramienta sigue en su enganche. Las acciones deben mover solo los huesos que de verdad se animan (pluma, brazo, herramienta, giro): lo que siguen las restricciones lo pone el visor. Otras restricciones quedan como las hornea cada acción, y el registro de la conversión las nombra (BLEND_BONE_CONSTRAINTS).

Un tablero en el cuerpo del visitante: un mando que el operador lleva puesto (en el cinturón) se empareja en Blender a un hueso del Avatar (tipo Bone). Viaja con el visitante, se ve en primera persona al bajar la vista, y sus controles se accionan con el puntero, con el rayo del control en VR o con sus teclas. La primera persona mira desde el centro de la parte libre de la pantalla, a la izquierda de la columna de la lista y el diálogo: lo que el operador tiene delante, el mando al bajar la vista, no queda bajo esa columna.

Solo en el player, además:

5. Formularios (Clipboard_)

El formulario es una página HTML que escribe el diseñador: cualquier diseño, la hoja de la planta tal cual como tabla, estilos en línea, incluso un script que arme los renglones. Reglas:

1. Cada casilla que el cliente llena es un <input>, <select> o <textarea> con name.
2. El archivo va en las fuentes de la unidad en Drive: en una carpeta forms, o junto a los documentos del cliente (from-client / del-cliente). Se encuentra por su nombre (p. ej. corte.html).
3. En Blender, el plano Clipboard_Inspeccion lleva la propiedad personalizada form = corte.html (también vale forms; en el objeto o en los datos de la malla). Modélalo con la forma del papel (horizontal o vertical).

Ejemplo mínimo:

<!doctype html>
<html lang="es"><meta charset="utf-8">
<style>body{font:12px Arial;padding:10px} td,th{border:1px solid #333;padding:2px} input{width:100%;border:0}</style>
<body>
<h2>Inspección · Línea de corte</h2>
<label>O.T. <input name="ot"></label> <label>Fecha <input name="fecha" type="date"></label>
<table>
  <tr><th>#</th><th>Longitud</th><th>Defectos</th></tr>
  <tr><td>1</td><td><input name="fila1_longitud"></td><td><input name="fila1_defectos"></td></tr>
  <tr><td>2</td><td><input name="fila2_longitud"></td><td><input name="fila2_defectos"></td></tr>
</table>
</body></html>

Cómo se usa: en computadora, clic en el portapapeles abre la página en la propuesta; en visor o tableta, un teléfono abre …/FCA/?clipboard y ahí aparecen todos los formularios de la escena. Lo que se escribe aparece en el papel de todos los que están en la escena. Sin página, fields = Nombre; Fecha; Observaciones... genera un formulario sencillo (... = varias líneas). Ejemplos completos: docs/examples/clipboard-forms/ en el repositorio wrk-mgr.

6. Controles de máquina (Button_, Knob_, Joystick_)

1. Nombra el control Button_Arranque o Knob_Presion (una malla, o un empty con las mallas del control debajo).
2. Crea la acción Play_Arranque / Play_Presion con keyframes del control y de lo que mueve: el botón que se hunde y el pistón que sube; la perilla que gira y la aguja que la sigue.
3. Exporta.

La acción de una perilla es una pose por valor, sin ciclos. Un hotspot sigue siendo la opción cuando el avatar debe caminar hasta el equipo y hacer un gesto.

Un tablero con varios controles. Un mismo tablero puede llevar varios botones, perillas y palancas a la vez, de cualquier tipo. Cada uno necesita su propio nombre y su propia acción (Button_Arranque + Play_Arranque, Button_Paro + Play_Paro, Joystick_Pluma + Play_Pluma_X / Play_Pluma_Y): dos controles con la misma acción se mueven juntos. Cada control cuenta como un punto de la tarea de su estación, también las copias de Blender (Button_Paro y Button_Paro.001 son dos puntos). En VR cada mano maneja su propio control: la palanca con una y el botón de mantener con la otra.

Lo que hace la máquina con varios controles a la vez (las dos palancas para avanzar, el botón de la palanca con la palanca para el brazo, un selector de modo, un paro de emergencia) se describe en el archivo de configuración, en [conditions] y [functions.Nombre] (capítulo 10.2). En la computadora, cada control puede tener sus teclas (keys) para manejar dos palancas a la vez.

7. La auditoría (/audit-showcase)

Revisa el archivo entregado antes de importarlo. El reporte llega al chat en varios mensajes: resumen y luego hallazgos por severidad.

Cada hallazgo trae en el chat qué es y cómo arreglarlo, en el idioma del --es.

8. Especificación completa de la escena

Audiencia: equipo de diseño 3D

Entregable: una escena interactiva por propuesta, mostrada dentro de la propuesta interactiva del cliente

Formato: .blend (Blender 4.x o 5.x hasta 5.2, preferido) o .fbx — entrega el archivo fuente; nosotros nos encargamos de toda la exportación y optimización

Novedades v1.1

• Presupuestos revisados: más triángulos (≤ 600 mil), pero límites nuevos de mallas y materiales — son los que realmente deciden el rendimiento. Ver tabla.
• Avatar encarnable (Avatar + clips Idle / Walk / Act_*): el cliente recorre la escena como un personaje, en tercera o primera persona.
• Interacciones (Hotspot_ + Play_ + Act_*): puntos donde el cliente acciona equipos — abrir una válvula, pulsar un botón.
• Las escenas v1 sin avatar ni hotspots siguen siendo 100 % válidas; las secciones nuevas son opcionales (pero muy recomendadas).
• El soporte del visor para avatar e interacciones está en desarrollo — entrega tus escenas igual desde ya; el pipeline valida los nombres desde la entrega.

Qué vas a construir

La escena aparece dos veces en la propuesta, desde el mismo archivo:

1. Maqueta — un modelo a escala de mesa al centro de la galería de la propuesta, como la maqueta de un arquitecto. Es lo primero que ve el cliente.
2. Vista interior — al hacer clic en la maqueta, el cliente entra dentro de la escena a escala real: de pie en los puntos que tú definas, sentado en puntos de vista que tú definas (cabina de vehículo, silla de control), o recorriéndola como un personaje (Avatar) en tercera o primera persona. La presentadora de IA narra mientras el cliente explora.

Diseña para ambas escalas. La escena debe verse atractiva como miniatura desde arriba Y sostenerse a la altura de los ojos desde cada punto de vista que coloques. Detalla lo que una persona de pie va a mirar; no detalles lo que nadie verá de cerca.

Requisitos obligatorios

Nosotros comprimimos todo (geometría y texturas) después de la conversión — no necesitas optimizar el tamaño del archivo más allá de estos presupuestos.

Convenciones de nombres — cómo tu escena le habla al visor

El visor lee nombres de objetos y nombres de acciones (animaciones) para saber cómo comportarse. Los objetos que no coinciden con ninguna convención son escenografía normal.

Station_NN_Nombre — puntos de pie (empties)

Un lugar donde una persona puede pararse. Agrega un empty por ubicación, posicionado en el piso (nosotros subimos la cámara a la altura de los ojos automáticamente). La rotación del empty define la dirección inicial de la vista (su eje +Y es "adelante" — activa Display As: Arrows para verlo).

• NN = orden del recorrido en dos dígitos (01, 02, …). El clic en la maqueta entra por el número más bajo.
• Nombre = etiqueta legible, CamelCase o con guiones. La presentadora de IA dice este nombre en voz alta — escribe Station_02_SalaDeControl, no Station_02_est2final.
• Los visitantes pueden saltar entre estaciones dentro de la escena; colócalas donde el recorrido tenga sentido: entrada → áreas clave → vista final.
• El empty manda. El visor para al visitante exactamente donde lo pusiste, sin corregir nada: por eso tiene que estar apoyado en el piso. /audit-showcase mide cada Station_ contra el piso real y te avisa si no coincide, antes de importar.
• Pon más de uno. Con una sola estación no hay a dónde navegar: no aparecen marcadores de salto y el visitante ve siempre lo mismo.

Seat_Nombre — puntos sentados (empties)

Una vista fija y sentada: cabina, grúa, silla de control. Posiciona el empty en el punto exacto de los ojos de la persona sentada (no en el piso). El visitante puede mirar alrededor desde ahí pero no moverse.

Skybox — el cielo (malla, opcional)

Una esfera o domo invertido grande, material emisivo, textura de cielo equirectangular, rodeando la escena. Se oculta mientras la escena es maqueta; se revela cuando el cliente entra. Si lo omites, el visor pone un cielo simple por defecto — uno real siempre se ve mejor.

La imagen del cielo va conectada a Emission, no a Base Color. El visor hornea el domo en un mapa de entorno dentro de una escena sin luces: un domo con la textura en Base Color sale negro y toda la escena queda a oscuras (así se entregó AER). /audit-showcase lo reporta como skybox_not_emissive.

Loop_Nombre — animación ambiental (nombres de acciones)

Toda acción cuyo nombre empiece con Loop_ se reproduce automáticamente, por siempre, cuando el cliente está dentro: Loop_Antorcha, Loop_Transportador, Loop_Trafico. Haz que el primer y último keyframe coincidan para que el ciclo sea continuo.

Demo_Nombre — la demostración de la portada (nombres de acciones, opcional)

La portada de una capacitación (la pantalla del módulo del player) muestra toda el área de entrenamiento en miniatura: cada estación, asiento y hotspot con el sujeto. Las paredes y el techo se cortan 2,2 m por encima del piso más alto donde se para el alumno. Lo que se mueve ahí lo decides tú:

• Con acciones Demo_. Toda acción cuyo nombre empiece con Demo_ se reproduce ahí, todas juntas, más las Loop_.
• Empiezan en el mismo instante y vuelven a empezar cuando termina la más larga; una más corta se queda en su último cuadro hasta entonces.
• El nombre después de Demo_ es libre, y puede repetirse con el sufijo de Blender (Demo_Controles.001).
• Si alguna mueve al avatar, aparece donde lo dejaste en el archivo; si ninguna lo mueve, no se ve.
• Sin acciones Demo_. El avatar recorre el ejercicio, ronda tras ronda, mientras las Loop_ siguen corriendo.
• Camina de estación en estación, en su orden. En cada una va a sus hotspots y hace su gesto (Act_) mientras el equipo se mueve (Play_).
• Varias estaciones seguidas en un mismo lugar son una sola parada.
• Camina por el Navmesh si lo hay; si no, en línea recta, como en un ejercicio.
• Al terminar la ronda vuelve a la primera estación y empieza otra.
• Nada de esto pasa dentro de un ejercicio. Al entrar, todo vuelve a su pose inicial, y las acciones Demo_ nunca se reproducen ahí.

En ALF la demostración de demolición es Demo_: el operador con el control remoto (Demo_Operador, Demo_Controles), el Brokk golpeando la pared (Demo_Brokk_v3) y los 50 pedazos de la pared cayendo (Demo_Pared_Trozo_033_0…). TAC no tiene Demo_: su portada muestra al avatar recorriendo sus cinco estaciones, usando el micrómetro y escribiendo.

Avatar — el personaje del cliente (armature, opcional)

Un personaje que el cliente "encarna" al entrar: puede verlo en tercera persona (cámara al hombro), mirar por sus ojos en primera persona, o soltarlo y volar libre (modo dron, el comportamiento actual). Si la escena no trae Avatar, el visor funciona como hasta ahora — solo modo dron.

• El armature raíz se llama Avatar y todas sus mallas cuelgan de él. Su posición en el archivo da igual — el visor lo coloca en la estación de entrada —, y también dónde queden sus huesos respecto a su origen: el visor lo centra en sus pies (la raíz del esqueleto).
• Clips del avatar (en NLA como todo lo demás):
• Idle (opcional) — parado, en bucle.
• Walk (opcional) — caminar en el sitio (sin desplazamiento de la raíz), a cadencia natural de ~1.4 m/s; el visor sincroniza la velocidad de reproducción con el movimiento real para que los pies no patinen.
• Si el Avatar no trae Idle o Walk, el visor usa unos compartidos (una postura y un caminar de hombre, en el esqueleto de Character Creator). Los que traiga la escena siempre tienen prioridad: inclúyelos cuando la escena necesite unos propios, por ejemplo para un avatar de mujer.
• Act_Nombre (opcionales) — acciones de una sola vez para las interacciones (ver hotspots). Un Act_Operate genérico sirve de comodín para cualquier hotspot sin clip específico.
• Avatar_Eyes (empty, opcional) — el punto exacto de los ojos; define la cámara en primera persona *y la altura de ojos en cada Station_**. Emparentarlo al hueso de la cabeza es lo recomendado, pero también lo leemos si queda suelto en la escena. Si falta, usamos ~94 % de la altura medida del avatar.
• Las mallas que deben desaparecer en primera persona (cara, pelo, pestañas, gafas) se nombran con el prefijo Head_ (Head_Face, Head_Hair). Sin mallas Head_, el visor oculta el avatar completo en primera persona.
• Se oculta a escala maqueta, igual que el Skybox. Sus triángulos cuentan en el presupuesto (~20–40 mil es lo típico).

Hotspot_Nombre — interacciones (empties) — el trío de nombres

Un punto donde el cliente hace algo: abrir una válvula, pulsar un botón, revisar un panel. Una interacción se define por hasta tres piezas que comparten exactamente el mismo nombre:

Comportamiento del visor: al acercarse (~2.5 m) aparece el aviso; al activar, el avatar se desliza al ancla y Act_ + Play_ se reproducen a la vez; después vuelve a Idle. Mientras dura la acción, un recuadro muestra de cerca lo que anima Play_ (el instrumento, la válvula): modela la lectura legible y deja la animación en el valor que debe leerse. reading en la tabla [Hotspot_Nombre] del archivo de configuración (o una propiedad note en Blender) hace que la guía diga la lectura al terminar. Por eso el ancla importa: colócala exactamente donde deberían estar los pies y la mano llegará al equipo. Sin avatar (o en modo dron), hacer clic en el marcador reproduce solo Play_ — los hotspots funcionan en toda escena, con o sin avatar.

• Clips de interacción: ≤ ~10 segundos.
• El nombre se muestra en pantalla y la presentadora lo pronuncia — Hotspot_AbrirValvula, no Hotspot_hs01.

Focus_Nombre — el sujeto de la maqueta (objeto o empty, opcional)

Dile al visor qué es lo que la maqueta muestra. En la galería la escena se ve como maqueta: el visor la escala para que su extensión más grande mida unos 4 m. Si la escena necesita mucho más entorno que sujeto — la cabina de FER tiene ventanas al frente y atrás, así que las vías y el piso deben correr lejos en ambos sentidos — el entorno se queda con esa escala y el sujeto termina diminuto.

• Nombra el objeto principal Focus_Nombre (Focus_Tren). Si el sujeto son varios objetos, emparéntalos bajo un empty con ese nombre: cuenta todo lo que cuelga de él. Varios Focus_* enmarcan su unión.
• La maqueta se escala y se centra en el Focus_, no en la escena completa. El resto del entorno conserva su tamaño real y, solo en la maqueta, se recorta a una base redonda un poco más ancha que el sujeto, como una maqueta de tren sobre su peana.
• Dentro de la escena no se recorta nada: las vías y el piso están completos, a escala real, hasta donde los hayas modelado.
• Un Focus_ sin mallas debajo no enmarca nada y el visor vuelve a medir la escena completa; /audit-showcase lo reporta como focus_frames_nothing.
• Sin ningún Focus_ todo funciona como siempre: manda la extensión más grande de la escena.

Icon_Camera — la vista del icono del módulo (cámara, opcional)

/gen-player renderiza el icono del módulo en el LMS desde este archivo: una imagen cuadrada de 1080 px, como los iconos de los demás módulos. Sin cámara, encuadra el sujeto de la maqueta (Focus_, o toda la escena) desde detrás y por encima de la primera estación, y deja fuera lo que se interponga entre la cámara y el sujeto (un barandal, los paneles de una cabina). Para elegir la vista tú, pon una cámara llamada Icon_Camera: se usa tal cual. El avatar, el Skybox (el cielo es neutro, como en la maqueta), los Collider_ y la Navmesh nunca salen en el icono. La luz es la del visor: el Sun del archivo y un cielo neutro que nada tapa salvo el sujeto, así que un sujeto dentro de una cabina queda iluminado.

Screen_Nombre_NN — pantallas con imágenes en secuencia (mallas)

Un monitor, tablet o kiosco que muestra una serie de imágenes (las pantallas de un sistema de registro, por ejemplo). Modela la pantalla como un plano con la primera imagen y duplícalo en el mismo sitio una vez por imagen: Screen_Registro_01, Screen_Registro_02, … cada copia con su propia imagen en el material (conectada a Emission, para que se vea encendida con cualquier luz). El visor muestra solo la _01; un clic, un toque o el gatillo de VR sobre la pantalla pasa a la siguiente y, tras la última, vuelve a la primera.

• Los cuadros deben coincidir exactamente en posición y tamaño (Shift+D sin mover); /audit-showcase avisa si alguno quedó desplazado.
• Numera desde _01 sin huecos. Un cuadro sin número (Screen_Menu) es escenografía normal; una pantalla con un solo cuadro no hace nada al hacer clic.
• Cada imagen cuenta en el presupuesto de texturas; exporta las capturas a 2K o menos.
• La guía de voz sabe qué pantalla está viendo el cliente y en qué imagen va; con una tabla [Screen_Nombre] con note en el archivo de configuración de la escena, la comenta.

Display_Nombre — pantalla en vivo (malla)

Un monitor que muestra, en vivo, la pantalla de una computadora: el programa real del cliente (su sistema de registro, por ejemplo) corriendo mientras el cliente practica frente al personaje. Modela el monitor como un plano de 16:9 con UV completo (la imagen ocupa todo el plano) y nómbralo Display_Registro. El material que le pongas es lo que se ve cuando nadie está compartiendo.

• La computadora que comparte abre la propuesta con ?display al final de la dirección y pulsa Compartir esta pantalla; a partir de ahí todos los Display_* de la escena muestran esa pantalla. Ambos equipos deben estar en la misma red.
• Un solo plano por pantalla; varios Display_* muestran la misma imagen.
• Para una secuencia fija de imágenes usa Screen_; Display_ es para software en vivo.

Character_Nombre — personas con las que se puede hablar (empty o raíz)

Una persona de la escena con la que el cliente practica una conversación real por voz: un huésped en la recepción, un cliente en la ventanilla. El personaje no se modela en la escena: el equipo de operaciones lo entrega en el comando de publicación, como el showcase:

/gen-proposal UNIDAD --publish --showcase <escena> --character <modelo> --persona <doc> --idle <clip> --talk <clip>

• --character: export de Character Creator 4 del personaje (.fbx, T-pose, sin animación): el mismo estándar que el presentador.
• --persona: Google Doc con líneas Nombre:, Persona: (quién es y qué quiere), Líneas: (opcional: lo que dice y los datos que da — teléfono, correo, domicilio — una por renglón; la persona los usa tal cual, nunca inventa otros) y Voz: (Puck, Charon, Fenrir, Orus masculinas; Aoede, Leda, Zephyr, Kore femeninas) o Género:. Persona: y Líneas: abarcan los renglones que siguen; nombre, voz y género ocupan uno solo. Cada personaje habla con una voz distinta de la guía.
• --idle / --talk: clips .fbx de solo movimiento sobre el esqueleto de Character Creator (exportados de Character Creator o iClone, o comprados en ActorCore): de pie en bucle, y mientras habla. Un clip de Mixamo se reorienta al esqueleto CC al publicar. Sin estos flags se usan los últimos clips importados.

Tu parte en la escena es el lugar: un empty (o cualquier objeto) llamado Character_Nombre donde va la persona, con el mismo Nombre que el documento de persona, mirando hacia donde está el cliente. El visor pone ahí el modelo entregado y oculta el marcador. Al acercarse (~2,5 m) aparece el aviso E — 💬 Nombre; con E, un clic o el gatillo de VR empieza la conversación y la guía calla; termina con E, otro clic, alejándose (> 4 m) o cuando la persona se despide, y la guía comenta cómo fue.

• Sin escena (--character sin --showcase), la persona aparece a tamaño real en la sala del cliente con el botón Practicar en tu sala (RA), con una pantalla Display_ generada delante.
• Con escena, en un visor con passthrough ese mismo botón coloca a la persona y las pantallas Display_* en la sala del cliente; la escena se gira para que la persona mire hacia Station_01.
• Recorridos (opcional): en lugar de quedarse en su lugar, la persona puede seguir un recorrido entre estaciones — saludar, caminar al archivo por la Navmesh, sentarse al escritorio, trabajar un rato, levantarse y repetir; conversar lo pausa. Se escribe en el archivo de configuración (path de [Character_Nombre], ver el capítulo 10 del sistema de propuestas). Una estación que solo usan los personajes es un Station_NN_Nombre más, que ningún ejercicio lista en su task_stations; si se sienta, el empty de esa estación mira hacia donde mira la persona sentada. Sus acciones son animaciones Act_Nombre de la escena (las mismas del Avatar) o importadas aparte.

Clipboard_Nombre — formularios que el cliente llena (malla, opcional)

Un portapapeles con un formulario que el cliente llena durante la práctica: el alta de un cliente, un reporte de incidente, la hoja de inspección de la planta. Modela el portapapeles como un plano con UV completo, con la forma del papel (vertical u horizontal), y nómbralo Clipboard_Registro. El material que le pongas es lo que se ve cuando nadie está en la escena; adentro, el visor dibuja el formulario con lo que se va escribiendo.

• El formulario es una página HTML que tú escribes: cualquier diseño, la hoja de la planta tal cual como tabla, estilos en línea, incluso un script que arme los renglones. Cada casilla que el cliente llena es un input, select o textarea con name. Guarda la página en las fuentes de la unidad en Drive (en una carpeta llamada forms, o junto a los documentos del cliente) y pon su nombre en la propiedad personalizada form del objeto (corte.html; también vale forms, y la propiedad puede estar en el objeto o en los datos de la malla). También sirve una dirección completa, o la página misma dentro de la propiedad. Ejemplos listos en docs/examples/clipboard-forms/.
• Sin página: una lista de campos en la propiedad fields, separados por ; (Nombre; Fecha; Observaciones...; un campo que termina en ... es de varias líneas) genera un formulario sencillo. Opcional: note con una frase sobre para qué sirve el formulario.
• Cómo se llena: en una computadora, un clic en el portapapeles abre la página en la misma propuesta; en visor o tableta, se abre la propuesta en el teléfono con ?clipboard al final de la dirección y ahí aparecen todas las páginas de la escena. Lo que se escribe aparece en el papel de todos los que están en la escena (una foto de la página; hojas de estilo e imágenes externas no salen en la foto, por eso estilos en línea).
• La guía de voz solo se entera de un formulario cuando es parte de una tarea (ver Las estaciones son las tareas): al enviarlo o al cerrarlo con todos los campos llenos. /audit-showcase reporta un Clipboard_ sin form ni fields, que no es una malla, o que no es un plano (clipboard_not_a_plane): un portapapeles modelado o una computadora entera con ese nombre no se pinta — el papel o la pantalla necesitan su propio plano.
• Dentro del recorrido, al tocar el portapapeles la cámara se acerca al objeto y la página aparece sola sobre él, sin marco; al cerrarla la cámara vuelve.

Show_Nombre — objetos que la guía señala uno por uno (objetos, opcional)

Para una estación con varios objetos que la guía explica de uno en uno — el EPP sobre una mesa, las herramientas de un banco —, nombra cada objeto Show_Nombre (Show_Casco, Show_Guantes_De_Nitrilo). Mientras la guía habla de un objeto, ese objeto brilla en naranja; al pasar al siguiente, el anterior se apaga.

• Cada Show_ pertenece a la estación (Station_ o Seat_) más cercana: basta con nombrar los objetos de la mesa, no hay que emparentarlos con nada.
• El nombre es lo que la guía dice en voz alta; escríbelo como se pronuncia, con guiones bajos entre palabras.
• Opcional: una propiedad personalizada note en el objeto con una frase sobre él (Protegen de químicos); la guía la desarrolla al describirlo.
• Si el objeto tiene varias piezas, emparéntalas bajo un empty con el nombre Show_: brilla todo lo que cuelga de él.
• El orden lo decide la guía al hablar; el brillo dura mientras lo describe y se apaga solo si nadie lo cambia en unos segundos.
• Un clic sobre el objeto lo ilumina y la guía lo describe (otra vez si hace falta), con su note si la tiene.
• El objeto se ilumina cuando la guía dice su nombre: por eso el nombre debe ser lo que se dice del objeto (Show_Guantes_De_Nitrilo, no Show_Obj17).
• El nombre se reconoce por palabras completas, en orden: Show_Tiza se ilumina con «la tiza» o «las tizas», no con «garantiza». Las palabras cortas (de, la, y) pueden sobrar o faltar («guantes carnaza» vale por Show_Guantes_De_Carnaza); un número se dice tal como está escrito en el nombre («20 metros» para Show_Cinta_Métrica_20_metros, así que escríbelo como lo dirá la guía). Si un nombre está contenido en otro (Show_Guantes y Show_Guantes_De_Carnaza), gana el más largo cuando se dicen todas sus palabras.
• Solo pueden iluminarse los objetos de la estación en la que está el cliente: un objeto del siguiente banco con una palabra en común no roba el brillo.

Navmesh — la superficie por donde se camina (malla, opcional)

Cuando el visitante va a una estación o a un punto interactivo con un clic, el personaje recorre un camino sobre la Navmesh de la escena: rodea mesas, barandales y rodillos en vez de atravesarlos.

Pon una malla llamada Navmesh (o Navmesh_Planta, cualquier nombre que empiece así) con la superficie caminable: pasillos, plataformas, rampas. El visor la oculta al cargar (no se dibuja, no proyecta sombra, no sirve de tope) y construye con ella una cuadrícula del piso. Solo los Collider_ bloquean celdas encima de ella: el resto de la escenografía no cuenta, así que pon un Collider_ en todo lo que el visitante deba rodear. Entre celdas nunca se sube ni se baja más de un escalón.

• Puede ser una sola malla o varias; basta con que estén a ras del piso real (± un escalón).
• Sin Navmesh, un clic lleva en línea recta.
• Ajustes en el panel y en el archivo de configuración, grupo nav: tamaño de celda, altura de escalón, ancho del visitante, velocidad del recorrido.

Collider_Nombre — topes invisibles para el visitante (mallas, opcional)

El visitante choca con las mallas de la escena (seis rayos horizontales, del tobillo a la cabeza). Donde la geometría deja huecos entre esos rayos — las barras de un barandal, una baranda, un cable, una vitrina muy fina — pon una caja o un plano sencillo con el nombre Collider_Nombre (Collider_Barandal_Norte) cubriendo la zona por donde no debe pasar. El visor lo oculta al cargar: nunca se dibuja, no proyecta sombra, no sirve de suelo ni se puede señalar; solo lo sienten los pasos del visitante.

• Déjalo visible en Blender con cualquier material; el visor lo esconde.
• Una caja por tramo basta; no hace falta ajustarla a la forma del objeto.
• /audit-showcase reporta un Collider_ que no sea una malla (collider_not_a_mesh).

Door_Nombre y Open_Nombre — puertas que se abren y se cruzan (malla o raíz, y una acción, opcional; v1.6)

Una puerta es el objeto Door_Nombre (Door_Almacen): la hoja como malla, o una raíz con la hoja debajo. Su acción de la escena Open_Nombre (Open_Almacen) la abre: el visor la reproduce hacia adelante al abrir y hacia atrás al cerrar, y se queda en su último fotograma.

• Un clic en la puerta la abre; otro la cierra. Cerrada, el visitante choca con ella y las rutas (clic en un marcador) no pasan por su vano; abierta, se cruza caminando.
• La Navmesh debe pasar por el vano: la puerta cerrada lo cierra sola.
• Una puerta sin acción Open_ no se abre: se queda como pared (el visor lo avisa en la consola).
• A otro ejercicio (PROP-60): con la propiedad personalizada exercise en la puerta (el código del ejercicio del mismo módulo, o su sufijo: PR), la puerta está cerrada con llave hasta que el alumno completa el ejercicio actual; entonces se abre y, al cruzarla, empieza ese ejercicio (con su tarjeta de inicio dentro de la escena). Mientras está cerrada con llave, un clic avisa qué falta.

Button_Nombre, Knob_Nombre y Joystick_Nombre — controles de una máquina (mallas, opcional)

Botones, perillas, palancas e indicadores que el cliente acciona directamente sobre el equipo: pulsa el botón de arranque y el transportador se mueve; gira la perilla de presión y la aguja del manómetro la sigue. No necesitan ancla ni avatar: se accionan donde esté el cliente, con un clic, con el gatillo del visor o con la mano.

• Nombra el control Button_Arranque o Knob_Presion (una malla, o un empty con las mallas del control debajo). Lo que hace está en la acción Play_Arranque / Play_Presion: ahí va, en keyframes, tanto el movimiento del control como el de lo que mueve — el botón que se hunde y el pistón que sube; la perilla que gira y la aguja que la sigue. Varios objetos en una acción: pistas NLA con el mismo nombre, igual que en Play_ de un hotspot. Para usar otra acción, pon su nombre en la propiedad personalizada plays.
• Button_ reproduce la acción una vez al pulsarlo. Con la propiedad mode: toggle (la acción se repite hasta pulsarlo otra vez; al apagarlo todo vuelve al reposo), hold (avanza mientras se mantiene pulsado y regresa al soltarlo) o latch (avanza hasta el final y se queda ahí hasta pulsarlo otra vez, que lo regresa: un paro de emergencia que se hunde y se jala; su acción termina con el botón adentro).
• Knob_ recorre la acción: el principio es la perilla al mínimo, el final al máximo. Se gira arrastrando con el ratón (o con la rueda), o en el visor sujetando el gatillo y subiendo o bajando la mano. La propiedad steps (5) la hace de posiciones fijas, y value (de 0 a 1) dice dónde está al cargar la escena: steps = 2 y value = 0.5 es un selector de tres posiciones que empieza al centro.
• Indicator_ es una luz de la máquina (una malla): se enciende en el color que diga el archivo de configuración ([indicators.Nombre]), según el estado de la máquina; apagada, se ve con su propio material. Si es una pantalla que muestra texto ([indicators.Nombre.text]), dale UV completa: la imagen llena la pantalla, con la parte de arriba de la pantalla arriba y su izquierda a la izquierda, como la ve quien la usa (una UV volteada muestra las letras al revés).
• La acción de un Knob_ debe ser una pose por valor, sin ciclos: a cada punto de la acción le corresponde una posición de la perilla y de lo que indica.
• Joystick_ tiene dos ejes y mueve dos acciones: Play_Nombre_X (izquierda → derecha) y Play_Nombre_Y (atrás → adelante); el centro de cada acción es la palanca al centro. Modela la palanca con el pivote en su base: el visor la inclina solo (propiedad tilt, grados; 20 por defecto). Por defecto cada eje recorre su acción como una perilla (mode = position); con mode = rate la acción avanza mientras la palanca está empujada y se queda donde está al soltar — la pluma de una grúa que sigue girando mientras se sostiene (propiedad speed: fracción de la acción por segundo a tope, 0.5 por defecto). Al soltar, la palanca vuelve al centro, salvo con sticky = 1. Se mueve arrastrando con el ratón, o en el visor sujetando el gatillo sobre ella y usando el stick del control; ese stick también gira una perilla sujeta.
• Varios controles en un tablero. Un tablero puede llevar varios Button_, Knob_ y Joystick_ juntos. Cada control lleva su propio nombre y su propia acción: dos controles con la misma acción se mueven juntos. Cada uno es un punto de la tarea de su estación, también una copia de Blender (Button_Paro y Button_Paro.001 son dos puntos con la misma etiqueta). Se acciona el control bajo el puntero (o bajo el rayo del control en VR), nunca el vecino; en VR cada mano sujeta su propio control. Lo que hace la máquina con varios controles a la vez (las dos palancas, un botón con la palanca, un selector) no va en Blender: va en el archivo de configuración ([functions.Nombre]), que nombra la acción Play_ de la máquina. Por eso la acción de cada control mueve solo el control y la mano del operador. Una acción de la máquina que mueve una palanca lleva la máquina en reposo a la mitad, igual que las acciones de la palanca; las demás, al inicio (o donde diga rest). Las acciones de varias funciones se suman, así que pueden compartir huesos, como las mangueras que siguen a la pluma y al brazo. Para que la máquina se desplace libremente (las orugas), su acción mueve solo la raíz del rig y la función lleva travel = true: la máquina va tan lejos como se la conduzca. Pon un Collider_ alrededor de la máquina: viaja con ella, la detiene contra paredes y personas, y el visitante choca con ella donde esté. Un cable entre dos partes (de la máquina a su fuente de alimentación) es un empty Cable_Nombre con las propiedades from y to (los nombres de las dos partes que une), radius (en metros, 0.012 por defecto) y color: el visor lo dibuja desde cada extremo hasta el suelo y por el suelo, y lo vuelve a dibujar si un extremo se mueve (la máquina se desplaza, el enchufe se saca).
• Restricciones de huesos. El visor resuelve en vivo las restricciones de un armature de máquina como Blender: Damped Track, Copy Location y Copy Transforms (entre huesos del mismo armature, espacio mundial), IK de una o dos huesos sin polo, Limit Rotation y Limit Location (espacio local). Los cilindros, las mangueras y la herramienta quedan en su lugar con varias acciones a la vez. Anima solo los huesos que se mueven de verdad; lo demás lo ponen las restricciones.
• Un mando en el cuerpo del visitante. Empareja el mando (sus Button_, Knob_, Joystick_ e Indicator_) a un hueso del Avatar: viaja con el visitante y se acciona igual. La carcasa puede ir con skin a ese mismo hueso. En tercera persona el visor muestra un primer plano del mando en una esquina, visto desde los ojos del operador; lo que encuadra es el padre común de los controles más las mallas con skin solo a él. En primera persona, al mirar hacia abajo, la vista se coloca sobre el mando para que quepa entero. Los nombres cortos de los controles (label en el archivo de configuración) flotan a su lado, en ese primer plano y en primera persona.
• Dos botones en una palanca. Cada botón es su propio Button_ con su propia acción, hijo de la palanca para que se incline con ella (en el Brokk, Button_Percutor es B1.LL y Button_B1LR es B1.LR, lado a lado en la cabeza de la palanca izquierda).
• /audit-showcase reporta un control sin su acción Play_ o que no es una malla.

Luces

Tu Skybox es la luz principal de la escena. El visor lo convierte en un mapa de entorno (IBL): de ahí sale toda la luz ambiental y todos los reflejos del metal. Es lo mismo que hace el "world" de Blender, y es la palanca más grande que tienes sobre cómo se ve la escena. Un cielo bien expuesto ilumina bien; un cielo plano u oscuro deja todo apagado.

El Sun decide hacia dónde caen las sombras. El visor toma su dirección y su color, no su intensidad: Blender exporta W/m² convertidos a lux y el visor los vuelve a reescalar, así que la intensidad no sobrevive el viaje de forma útil. El visor pone su propia intensidad, calibrada con la exposición. Orienta el Sun como quieras que caigan las sombras y no te preocupes por su "Strength".

Se usa el primer Sun (luz direccional) de la escena; un segundo sol no se enciende. Las lámparas point y spot sí: en el player, dentro de la escena a escala real, todas las que pongas iluminan con la intensidad que les diste (en la maqueta van apagadas, porque de tan cerca la quemarían). Para un interior son la luz que cuenta: ilumínalo como quieras que se vea.

Tiene que ser una lámpara de tipo Sun: una luz Point o Area llamada "Sun" no cuenta (AER entregó un point de 17,8 millones de candelas y el visor lo ignoró: sin dirección de sol, sin sombras autoradas). /audit-showcase lo reporta como sun_not_directional.

El piso no fija la escala de la maqueta. En la galería la escena se muestra como maqueta: el visor escala la extensión más grande de la escena (sin contar Skybox y Avatar) a 4 m. Un piso o explanada mucho más grande que el sujeto se convierte en la maqueta entera y el sujeto queda diminuto (el avión de AER medía 0,8 m sobre una explanada de 185 m). Recorta el piso a la zona caminable, o — si la escena necesita ese entorno, como unas vías que deben verse largas desde la cabina — nombra el sujeto Focus_Nombre y el piso deja de contar. /audit-showcase lo reporta como diorama_fit_dominated.

Hasta 2026-08-14 esta sección decía que todas las luces iluminaban la vista interior. No era cierto: el conversor nunca las exportaba. Ya se corrigió.

Las estaciones son las tareas (sin nada nuevo que nombrar)

La visita no es un paseo: es un ejercicio por tareas, y las tareas son tus Station_NN_Nombre (y después los Seat_) en su orden. No hay que agregar nada:

• La instrucción de cada tarea es task en la tabla [Station_NN_Nombre] del archivo de configuración de la escena (ver la guía del sistema, capítulo 10); sin ella, la propiedad note de la estación en Blender; sin nada, su nombre.
• Lo que hay que hacer ahí son los objetos interactivos más cercanos a esa estación — igual que los Show_: el Hotspot_, el Clipboard_, el Character_, la Screen_ o los controles que estén junto a ella.
• La tarea se da por hecha cuando el visitante llega a la estación y hace todo lo que hay ahí: acciona el hotspot, hace clic en cada objeto Show_, entrega la hoja o la cierra contestada (si la página marca campos required, todos ellos; si no, basta con haber cambiado algo; la hoja generada por fields pide todos sus campos y tiene botón Entregar; cerrarla sin tocar le gana un recordatorio de la guía; un Clipboard_ sin form ni fields no cuenta), termina la conversación, pasa la pantalla hasta su última imagen, acciona el control. Una estación sin nada que hacer se cumple al llegar.
• Varias tareas en un mismo lugar. Cuando varias tareas se hacen donde el visitante ya está (en el Brokk: encenderlo, sus orugas, su brazo y su martillo, todo desde el sitio del operador), pon sus Station_NN_Nombre en el mismo punto (a menos de 25 cm uno de otro). El visitante no camina entre ellas: al terminar una tarea, la siguiente de ese lugar empieza ahí mismo, con su lección y sus preguntas. Se ve un solo marcador por lugar, el de la tarea que toca. Las funciones y los estados de la máquina eligen su tarea con station en el archivo de configuración.

La guía pide una tarea a la vez, al llegar explica la estación y dice qué hacer ahí, confirma cada tarea cumplida, da una pista si el visitante se atasca y cierra el ejercicio con una retroalimentación breve. En pantalla aparece la lista con las tareas hechas tachadas; se pueden hacer en cualquier orden.

Después de cada tarea la guía hace dos preguntas sobre la estación (solo de lo que enseñó al llegar; la lección sale del archivo de configuración de la escena y del material) y califica las respuestas. Al final, el examen: todo el ejercicio otra vez, solo, en orden, sin marcadores ni lista; la guía calla hasta el cierre. Nada de esto se nombra en Blender.

Cómo usa el visor tu escena

• La cámara entra a la altura de ojos del avatar entregado, sobre el empty Station_ tal como lo colocaste (sin raycast, sin correcciones): Avatar_Eyes menos la base del avatar. Sin Avatar_Eyes usamos ~94 % de su altura medida; sin avatar, 1.7 m. Los Seat_ se respetan exactos.
• El cliente puede mirar (arrastrar), girar y caminar (flechas — se sigue el terreno: banquetas y escaleras funcionan, subidas mayores a ~3.5 m no), alternar una vista aérea (barra espaciadora) y saltar entre estaciones (marcadores numerados).
• Con Avatar, el cliente entra en tercera persona y puede alternar tercera persona / primera persona / modo dron. El avatar respeta las mismas reglas de suelo que la cámara.
• En VR, el visitante ve su propio cuerpo del cuello hacia abajo: el cuerpo sigue al visor (caminar físico incluido), gira cuando el visitante gira — no cuando solo mira — y alterna Idle/Walk según la velocidad real.
• Manos rastreadas (IK): con las manos libres (sin controles), las manos y dedos REALES del visitante mueven los brazos y dedos del avatar. Para que funcione, el rig debe conservar: (1) los nombres de huesos CC_Base_* exactos de Character Creator — sin renombrar ni re-targetear al exportar; (2) el clip T_Pose en el export; (3) escala en metros, animaciones in-place; (4) un solo armature bajo Avatar. Si el visitante baja las manos (fuera de las cámaras del visor), los brazos vuelven suavemente a la animación — es el comportamiento esperado, no un error.
• Cerca de un Hotspot_* aparece el aviso de interacción; el visor desliza el avatar al ancla antes de reproducir los clips.
• Un clic (o el gatillo de VR) sobre una pantalla Screen_ pasa a la siguiente imagen; cerca de un Character_, E (o un clic) abre una conversación por voz con ese personaje, que habla con su propia voz.
• Consecuencia de diseño: el suelo entre estaciones debe ser transitable y continuo; compón cada estación como una toma, pero recuerda que el cliente puede caminar fuera de ella.
• Próximamente: las mismas escenas se explorarán también con visores de realidad virtual (Quest). No requiere trabajo extra de tu parte — pero la escala real en metros y los presupuestos de rendimiento importan aún más.

Entrega y retroalimentación

Entrega el archivo igual que cualquier modelo de showcase (enlace de Drive al equipo de operaciones). El pipeline de publicación valida la escena automáticamente y reporta los problemas por nombre en la tarjeta de chat — p. ej. "Station_03 está 4.2 m sobre el piso — las estaciones van en el piso" o "la escena mide 17 m de ancho pero declara estaciones caminables — reescala a metros." Corrige y vuelve a entregar; republicar es barato y el modelo solo se reconvierte cuando el archivo realmente cambia.

Antes de importar nada, el equipo de operaciones puede pedir una revisión del archivo con /audit-showcase <enlace de Drive>: abre tu archivo sin convertirlo ni publicarlo y responde en el chat con lo que encontró — bibliotecas vinculadas que faltan, imágenes que Blender no pudo cargar, objetos ocultos que no llegarían a exportarse, nombres de clips fuera de convención, los presupuestos de la escena, y desde septiembre de 2026 también si el Sun es direccional, si el Skybox es emisivo y qué objeto fija la escala de la maqueta. Si algo no cuadra, lo sabrás en minutos y sin tocar la propuesta del cliente. La tarjeta muestra los primeros seis elementos afectados de cada hallazgo; el informe completo (todas las texturas con su tamaño y los materiales que las usan, objetos ocultos, estaciones contra su piso) está en el enlace al final de la tarjeta.

Dos casos se rechazan de inmediato, porque el cliente vería una escena vacía: un archivo sin geometría (lo que produce un archivo maestro cuyas bibliotecas vinculadas no se entregaron con él) y una textura sin píxeles (una imagen cuyo archivo Blender no pudo cargar). El mensaje nombra los objetos que sí llegaron, o los materiales afectados.

Lista de verificación antes de entregar

• 1 unidad = 1 metro; escalas aplicadas; la escena tiene tamaño real
• Al menos un empty Station_ (o Seat_), en el piso (asientos: a la altura de los ojos), dirección "adelante" verificada
• Los nombres de estación y hotspot son presentables — la presentadora de IA los pronuncia
• Domo Skybox presente (u omitido a propósito), con la imagen conectada a Emission
• Una lámpara de tipo Sun (no point/area) orientada como quieras las sombras
• El piso o explanada no supera ~1,5× el tamaño del sujeto, o el sujeto se llama Focus_Nombre — si no, el piso fija la escala de la maqueta
• Movimiento ambiental montado como acciones NLA Loop_*, con ciclo continuo
• Opcional: la demostración de la portada montada como acciones Demo_*; sin ellas, el avatar recorre las estaciones y sus hotspots
• Si incluyes Avatar: mallas de cabeza con prefijo Head_; Avatar_Eyes en el hueso de la cabeza (recomendado); Idle y Walk en NLA solo si la escena necesita unos propios (Walk en el sitio, sin desplazamiento de raíz)
• Hotspots: ancla donde van los pies, +Y hacia el equipo; el trío Hotspot_X / Play_X / Act_X comparte el nombre exacto
• Pantallas: Screen_X_01, _02… duplicadas en el mismo sitio, una imagen por cuadro (Emission), numeradas sin huecos
• Pantalla en vivo: Display_X, plano 16:9 con UV completo
• Personajes con los que se habla: un empty Character_X donde va la persona (el modelo, la persona y los clips llegan con --character, --persona, --idle, --talk)
• Objetos que se describen uno por uno en una estación: cada uno nombrado Show_Nombre, con note opcional
• Formularios que el cliente llena: planos Clipboard_Nombre con la página HTML en form (o una lista en fields)
• Topes invisibles donde los pasos atravesarían barandales o cables: cajas Collider_Nombre
• Controles de máquina: Button_X / Knob_X con su acción Play_X (el control y lo que mueve, en una sola acción); Joystick_X con Play_X_X / Play_X_Y
• Principled BSDF en todo; texturas procedurales horneadas; texturas ≤ 2K, ≤ ~24 imágenes, empacadas en el archivo
• Ninguna imagen rota: si Blender no encuentra el archivo de una textura, se exporta vacía y la entrega se rechaza
• ≤ 600 mil triángulos; ≤ 150 mallas tras unir; ≤ 25 materiales únicos
• Recorriste cada punto de vista en Blender (Numpad 0 con una cámara en el empty) — se ve compuesto, no accidental

---

9. Para desarrolladores

• El paquete y su construcción: docs/workers/player.md en wrk-mgr (build_player_package, la pantalla del módulo, la música, el lanzamiento desde el LMS).
• La publicación (/gen-player, el LMS en DEMO, con-mgr, la música): docs/player.md en flow-mgr.
• El código del player: workers/interactive_web/player_shell/ en wrk-mgr, independiente del de la propuesta (app_shell).
• Las pruebas de extremo a extremo: tools/evidence/station_walkthrough.py UNIDAD --player (con --lms USUARIO --lms-module CODIGO --exercise TU|TE|PR|EXAM), en el navegador de evidencias de Control1.

10. El archivo de configuración de la escena

Es el mismo archivo que el de la propuesta. Todo lo que sigue vale para el player; lo que solo usa el player está en 10.4 y 10.5.

Un solo archivo por unidad, en formato TOML, en las fuentes de la unidad en Drive, cuyo nombre contenga scene config o configuración de la escena (mayúsculas y acentos no importan). Se lee al publicar y en cada /gen-proposal CODIGO --showcase. Reúne tres cosas: los ajustes del ejercicio (los mismos del panel de ajustes), una tabla por objeto de la escena bajo su nombre exacto de Blender, y las instrucciones de la guía. El antiguo documento de "temas del recorrido" ya no existe.

Cómo se combina con el panel (Ctrl+Shift+K): el archivo es la base; lo que se guarda en el panel queda encima, por unidad. Un valor largo (una instrucción) se edita con el botón … en una ventana grande. Las tablas de objetos aparecen en el panel como el grupo Objetos de la escena y también se pueden corregir y guardar ahí.

[quiz]
perStation = 2
passMark = 0.7

[tasks]

[prompts.rubric]
text = "..."

[scene]
welcome = "Bienvenido a la línea de inspección."

[Station_01_Placa]
task = "Revisa la placa: estencilado, medidas y espesor"
topic = "Qué se verifica en la placa y por qué importa"
description = "La mesa de placas a la entrada del molino: la placa sobre los rodillos, el micrómetro de 0-1\", las cintas y el reporte F-TUAC-022 en su tablilla"
questions = [["¿Qué datos del estencilado verificas?", "colada, proveedor y grado"], ["¿Con qué mides el espesor?", "con el micrómetro"]]

[Hotspot_Micrometer]
action = "Mide el espesor de la placa con el micrómetro"
reading = "12.50 mm"

[Clipboard_Inspeccion]
instructions = "Captura la colada y el espesor medido"
[Clipboard_Inspeccion.expected]
Espesor = "12.50"

[Show_Balde_De_Pintura]
note = "Pintura de marcado para identificar la placa aprobada"

10.1 Ajustes

Una tabla por grupo del panel; las claves son las del panel, anidadas como tablas o con punto (card.radius = "14px"). Valor por defecto entre paréntesis.

[render] — Resolución de dibujo

[video] — Video de la presentadora (Kira)

[caption] — Subtítulos

[presenter] — Animaciones de la presentadora 3D (Camila)

[lighting] — Luces de la galería

[face] — Rostro de la presentadora 3D

[guide] — Guía dentro de la escena

[gaze] — Mirada del visitante (solo en el recorrido: el ejercicio por tareas nunca usa la mirada)

[tasks] — Ejercicio por tareas

[quiz] — Evaluación: preguntas y examen

[sound] — Sonido

[mic] — Micrófono mientras ella habla

[listen] — Micrófono: cuándo escucha

[show] — Brillo de los objetos que nombra

[markers] — Marcadores

[actpip] — Primer plano de la acción

[nav] — Navegación (caminos)

[characters] — Personajes: recorridos

Para los personajes con path (ver [Character_Nombre] en 10.2).

[lessons] — Lecciones por estación

Al publicar, el sistema escribe una lección por estación a partir del material de la propuesta y la configuración de la escena: título, objetivo, todos los puntos clave y pasos que el material da (sin límite), seguridad, las preguntas de la revisión con su respuesta, y un tablero de láminas (hasta slides): cada lámina tiene título, unas pocas etiquetas con las cifras y una infografía generada con el proveedor y modelo de imagen de [lessons]. Todas las infografías de la unidad reciben las mismas imágenes de referencia: las del material del cliente (las figuras de sus documentos y sus fotos), en su orden, hasta referenceImages; si el material no trae imágenes, ninguna se envía y la infografía se dibuja a partir de su descripción. La guía enseña la lección completa al llegar, lámina por lámina, nombrando cada una («Lámina 2: …»); al nombrarla, su infografía aparece sola en pantalla (sin marco, título ni controles), se queda showSeconds o hasta que nombra otra, y se desvanece; el botón Lección de la lista hace que la vuelva a enseñar entera desde el principio (sin marcarla, completarla ni revisarla de nuevo; elegir otra estación mientras tanto solo la calla). Sin infografías (dibujarlas está apagado por defecto: cada una se paga) no hay tablero y la lección no menciona láminas: la guía enseña las mismas partes, una por turno, cada una por su tema. Durante toda la lección el micrófono está cerrado: nada la interrumpe hasta que termina. Las preguntas de la revisión salen de la misma lección (salvo que la tabla de la estación traiga questions). La lección se vuelve a escribir solo cuando cambian el material, la configuración o la escena. Una infografía se dibuja solo cuando su lámina no tiene ninguna, o cuando el comando de publicación la nombra con --redraw: nunca por sí sola, ni porque cambie el texto de la lámina, el estilo, el proveedor o el modelo (cada imagen se paga).

[telemetry] — Telemetría

[prompts] — Instrucciones a la guía

Cada clave es una tabla con es y en (el texto de la instrucción en cada idioma); {n} es un número que la página rellena. rubric y protocolExtra llevan solo text.

[controls] — Tablero de mando: teclas y funciones

10.2 Objetos de la escena

Una tabla por objeto, con el nombre exacto del objeto en Blender ([Station_01_Placa], [Hotspot_Micrometer], ["Show_Balde_De_Pintura"]): así se emparejan. Las claves dependen del prefijo. Un nombre con acentos o espacios se escribe tal cual, con o sin comillas ([Show_Tapones_Para_Oídos], [Station_03_Mesa de herramientas]).

[Station_NN_Nombre / Seat_Nombre]

[Character_Nombre]

[Character_Alejandra]
path = [
  { act = "Saludar" },        # una animación, una vez
  { walk = "Archivo" },       # camina a esa estación por la Navmesh
  { act = "Buscar" },
  { walk = "Escritorio" },
  { sit = true },             # se sienta, mirando hacia donde mira el empty de la estación
  { work = [20, 60] },        # mantiene lo que hace (trabajar sentado o de pie) entre 20 y 60 s
  { stand = true },           # se levanta
]

• Los lugares son estaciones: walk nombra una estación por su nombre (Archivo es Station_03_Archivo; mayúsculas y acentos no importan). Una estación que solo usan los personajes es una estación más que ningún ejercicio lista en task_stations ([module..exercise.], en la documentación del player).
• act = "Nombre" busca la animación en este orden: la entregada para ese personaje, la Act_Nombre de la escena, y la importada para todos con scripts/character_clips.py import --act Nombre --url …. Sentarse, trabajar sentado y levantarse son animaciones de esos mismos nombres ([characters] sitDown / seated / standUp). Caminar: la entregada con el personaje, o la compartida (la de mujer si su Género es femenino).
• El recorrido empieza al entrar a la escena y vuelve a empezar en cada entrada; en la galería y en el ejercicio en realidad aumentada el personaje queda quieto con su animación de reposo.
• Conversar lo pausa: si camina, se detiene y se voltea hacia el visitante; si está sentado, habla desde la silla. Al terminar sigue desde el mismo paso. Acercarse y oprimir E nunca lo hace irse.
• Una estación donde está el visitante, o a la que va, está tomada: el personaje cuyo siguiente walk va ahí espera donde está hasta que el visitante se vaya. Lo que pasa al revés lo dice occupied de la estación (arriba).
• Sin Navmesh, camina en línea recta. Los personajes no se esquivan entre sí ni al visitante.

[Hotspot_Nombre]

[Clipboard_Nombre]

[Show_ / Screen_ / Button_ / Knob_ / Joystick_]

[scene]

Las tablas que solo usa el player de capacitación ([module.*], title en [scene]) y los avisos de /gen-player están en la documentación del player.

Sin tabla para un objeto, la página usa la propiedad note del objeto en Blender si existe, y si no, su nombre. Todo lo que hay en una tabla también llega a la guía como texto, así que puede contestar preguntas sobre ello.

Funciones de la máquina: [conditions] y [functions.Nombre]

En una máquina real, lo que hace la máquina sale de varios controles a la vez: las dos palancas hacia arriba avanzan las orugas; el botón de la palanca derecha sostenido con la palanca hacia adelante mueve el brazo; el regulador fija la potencia del martillo. Cada control mueve su propia acción Play_ (el control mismo, la mano del operador); lo que hace la máquina se describe aquí, una tabla por función.

[conditions]
listo = ["Button_S0 off", "Button_S1 on"]

[functions.Avanzar]
label = "Avanzar con las orugas"
when = ["listo", "Joystick_Torre.y > 0.2", "Joystick_Pluma.y > 0.2"]
plays = "Play_Orugas_Maquina"
follows = "Joystick_Torre.y"

[functions.Martillo_regulado]
label = "Martillar con potencia regulada"
when = ["listo", "Button_Percutor held", "Knob_R1 > 0"]
plays = "Play_Percutor_Maquina"
speed_from = "Knob_R1"

[functions.Avanzar_simultaneo]
label = "Avanzar con las dos orugas"
when = ["listo", "Knob_S5.step = 0", "Button_B1LR held", "Button_Alcance held"]
plays = ["Play_Oruga_Izq_Maquina", "Play_Oruga_Der_Maquina"]
drive = 1

Condiciones (en when y en [conditions]): el nombre de un grupo de [conditions], o un control con su prueba:

Comparaciones: >, <, >=, <=, =. not delante niega una condición de control. La función está activa mientras se cumplen todas. Los nombres de los controles van tal cual en Blender, sin espacios.

Cada función es un punto de la tarea de su estación: cuenta como hecha cuando se mantiene activa [controls] functionDoneS segundos. En una estación con funciones, los controles ya no son puntos sueltos ni avisan a la guía: la tarea es lo que hace la máquina. Las acciones de los controles deben mover solo el control (y la mano del operador); el movimiento de la máquina va en las acciones que nombran las funciones.

Las acciones de las funciones se suman. Al cargar la escena, el visor pone la máquina en la pose de reposo de cada acción (rest); cada función activa añade lo que su acción se aparta de esa pose. Así las dos palancas a la vez mueven la pluma y el brazo completos, aunque Blender exporte en cada acción todos los huesos del brazo y las mangueras se muevan en varias acciones. Si se reprodujeran enteras, cada una sostendría en reposo lo que mueve la otra y el visor las promediaría a la mitad. Lo mismo vale para los dos ejes de una palanca, que se suman desde el centro.

Estados de la máquina ([states.Nombre]): lo que la máquina recuerda, como la unidad de control encendida, el motor en marcha o el circuito de control establecido.

[states.encendido]
label = "Encender la unidad de control"
set = ["Button_S1 held"]
clear = ["Button_S0 on"]

[states.circuito]
label = "Establecer el circuito de control"
set = ["encendido", "Button_Alcance held"]
clear = ["not encendido"]
idle_s = 3

Un estado se enciende mientras se cumplen todas las condiciones de set y se apaga mientras se cumplen todas las de clear (si se cumplen las dos, se apaga). Con idle_s, se apaga solo cuando pasan esos segundos sin ninguna función activa: el circuito del Brokk se corta a los 3 s y el botón de la palanca lo establece de nuevo. Con hold_s, se enciende solo cuando sus condiciones de set llevan esos segundos cumpliéndose sin interrupción: el interruptor principal Q1 del Brokk, 3 s en la posición 0 antes de pasar a la otra fase. Con while, solo puede estar encendido mientras se cumplen todas esas condiciones: el motor, mientras la unidad está encendida y la máquina tiene corriente (clear exige todas sus condiciones a la vez, así que no podría apagarlo por cualquiera de las dos). Con last = true, un estado con label va en la lista después de las funciones: la desconexión es lo último. Con initial = true, empieza encendido. Una condición nombra un estado igual que un grupo de [conditions] (encendido, not circuito). Un estado con label es también un punto de la tarea: cuenta la primera vez que se enciende y va antes que las funciones en la lista, porque el arranque va primero. También acepta note y station.

Indicadores ([indicators.Nombre]): una luz del modelo, la malla Indicator_Nombre (u otra que diga node). Cada color (green, yellow, red, orange, blue, white) lleva la lista de condiciones que lo encienden; gana el primero que se cumple, y si ninguno se cumple la luz queda con su propio material.

[indicators.LED2]
green = ["circuito"]
yellow = ["encendido", "not circuito"]

Una pantalla muestra texto mientras está encendida: su tabla text asocia una condición (un estado, un grupo de [conditions] o una condición de un control, entre comillas) con lo que dice la pantalla en ese momento. Gana la primera que se cumple; si ninguna se cumple, la pantalla solo se ilumina. \n separa las líneas. El texto se dibuja como una pantalla con luz de fondo, con el color encendido de fondo y las letras oscuras. La malla necesita UV completa (la imagen llena la pantalla) con la parte de arriba de la pantalla arriba y su izquierda a la izquierda, como la ve quien la usa; con la UV volteada las letras salen al revés.

[indicators.Pantalla]
green = ["encendido"]

[indicators.Pantalla.text]
motor = "+23°C   20 bar\n102 h"
encendido = "BROKK\nStart Engine"

En lugar de un texto, una entrada de text puede ser una pantalla con la disposición de la de la máquina, como una tabla en línea:

[indicators.Pantalla.text]
motor = { lines = ["+23°C  20 Bar", "102 h"], left = "battery 4/4", right = "signal 4/4", mark = "lubrication" }
encendido = { logo = "BROKK", lines = ["START ENGINE", "(I)  (M)"] }

Símbolos: battery, signal, oil, lubrication, service. Todo se dibuja con la tinta oscura sobre el color encendido. La página dibuja la pantalla ella misma: no hace falta ninguna imagen.

Un indicador también acepta note (lo que la guía sabe de él) y label, su nombre corto ("LED2"), que se muestra a su lado como el de un control. Las luces de la máquina (sus faros de trabajo) también son indicadores: una malla Indicator_Luces que se enciende en white con el motor.

Primer plano del panel y etiquetas

Mientras el visitante maneja un panel (está en la estación de sus controles y ninguna tarjeta está abierta):

• En tercera persona aparece en la esquina inferior izquierda un primer plano del panel, visto desde los ojos del operador, con el lado lejano arriba, como en primera persona. La cámara de hombro no ve un mando colgado del cinturón, porque el cuerpo está delante. En ese recuadro no se dibuja a la persona, porque la cámara está entre sus ojos y el panel. Los controles llenan la mayor parte del recuadro: se encuadran por sus propias cajas, centrados, con margen para las etiquetas. Nada que quede entre la cámara y el panel lo tapa (una viga, por ejemplo). Mientras una animación Act_ se reproduce, su propio primer plano tiene prioridad. Con visor de realidad virtual no hay recuadro.
• En primera persona, al mirar hacia abajo un mando que el visitante lleva puesto (en el cinturón), la vista se coloca sobre el centro del mando y retrocede lo justo para que quepa entero en la parte libre de la pantalla. Así se ve entero aunque el cuerpo se balancee al estar quieto. Al levantar la vista, la cámara vuelve a los ojos.
• Etiquetas: cada control o indicador con label lleva su nombre flotando al lado, con una línea hasta él: en el primer plano en tercera persona y sobre la vista en primera persona. Cada etiqueta va del lado que da hacia fuera del panel si está libre y, si no, en el siguiente lado libre, sin tapar otros controles ni otras etiquetas. Sin un lado libre, toma el que menos estorba: una línea que cruza otra estorba más que tapar parte de un control, porque se lee como la etiqueta del otro. Dos etiquetas cuyas líneas aún se cruzan se cambian de sitio. Conserva su lado mientras siga libre, así que no salta cuando la vista se mueve un poco.
• Un mando que se lleva puesto es el panel de su estación aunque en ella haya también controles fijos en la escena (el interruptor principal de la máquina, un enchufe): esos se accionan donde están, y el primer plano, sus etiquetas y el encuadre en primera persona son los del mando.
• El panel es lo que sostiene todos sus controles e indicadores: su padre común más cercano en el modelo (en el Brokk, el hueso Control del mando) más las mallas con skin solo a ese padre (la carcasa del mando). Si su padre común es todo el avatar o toda la escena, el recuadro encuadra solo los controles.

10.3 Avisos al publicar

---

10.4 Solo en el player

/gen-player lee el archivo de con-mgr (DEMO); la primera vez lo toma de Drive y lo guarda allí.

[scene], además de welcome:

[module.CÓDIGO] y [module.CÓDIGO.exercise.CÓDIGO] (solo /gen-player)

Los módulos de la unidad en el LMS, que /gen-player crea en DEMO si no existen (flow-mgr docs/player.md; capítulo 3). Puede haber varios y van en el orden del archivo. El nombre de la tabla es el código del módulo: dos letras (OB) o el código de la unidad y dos letras (ALFOB). Cada módulo puede definir sus propios ejercicios; su orden en el archivo es la secuencia del LMS. Un módulo sin ejercicios recibe los tres estándar: TU «Tutorial», TE «Revisión Teórica» y PR «Práctica».

[module.OB]
name = "Operación del Brokk 170"

[module.OB.exercise.TU]
summary = "Aprende a moverte por la escena y a usar el control remoto."

[module.OB.exercise.DM]
name = "Demolición de muro"
simulation = true
task_stations = ["Pared", "Control remoto"]

Sin tablas [module.*], la unidad tiene un módulo con el nombre que un modelo escribe a partir del material. Su código es el de la unidad más las iniciales de las dos primeras palabras con significado (ALF + «Operación del Brokk» = ALFOB). Lo que el archivo no da (nombres, resúmenes) se escribe una vez y se conserva, porque el LMS compara esos textos en cada publicación. Si después se cambia en el archivo un nombre o resumen que DEMO ya tiene, el aviso es lms_demo_conflict; nunca se edita lo que ya existe. El icono del módulo se renderiza desde el archivo de Blender de la unidad, con su Icon_Camera si la escena la tiene (ver la especificación de la escena).

[tablet] (solo /gen-player)

Lo que hay en cada app de la tableta (capítulo 2.5b). Cada elemento es una tabla con nombre propio, para que la unidad pueda completar o cambiar uno que viene de la configuración global. sequence ordena cada lista; enabled = false oculta uno heredado. Documentos y videos: source es la etiqueta de un recurso de con-mgr (DEMO), de la unidad o de la biblioteca compartida (un documento debe ser PDF; un video, MP4 o WebM). Contactos: name, role, portrait (etiqueta de una imagen PNG o JPEG); guide = true es la guía del ejercicio; cualquier otro necesita instructions (quién es y cómo responde) y puede llevar voice (una voz de Gemini) o gender. live_avatar nombra su Gemini Live Avatar; avatar nombra su avatar de voz entre los presentadores de flow-mgr (sin él: el presentador propio de la unidad para la guía, el presentador incluido para los demás). Las instrucciones, la voz y el Live Avatar se quedan en flow-mgr: nunca llegan a la página.

[tablet.documents.manual]
source = "manual"
title = "Manual de uso"

[tablet.videos.arranque]
source = "video.brokk-arranque"
title = "Arranque"

[tablet.contacts.jefe]
name = "Carlos Ruiz"
role = "Jefe de planta"
voice = "Charon"
instructions = "Respondes sobre los turnos y la seguridad de la planta."

Configuración global y herencia. con-mgr guarda además una player-config global (biblioteca compartida). La de la unidad se aplica encima, con la regla de GW2: un valor de la unidad gana, las tablas se combinan y una lista reemplaza a la otra entera. Ahí vive el perfil del Mentor:

[tablet.contacts.mentor]
name = "Camila Rojas"
role = "Mentor"
live_avatar = "Kira"
guide = true
sequence = 10

Una unidad le cambia el nombre con solo [tablet.contacts.mentor] y name = "Laura".

10.5 Avisos de /gen-player

---

ENGLISH

1. What it is

The player is a unit's training as an app of its own, separate from the interactive proposal. It lives on DEMO: https://demo.trainbeyond.com/player/CODE/ (ALF, TAC…). The 3D scene, the stations, the lessons, the voice guide and the checks are the proposal's own pieces (chapters 4 to 8 and 10 are shared with it as they are); what changes is everything around the exercise:

• An LMS module with its exercises. The unit is a module of the training platform (LMS) with three exercises by default (Tutorial, Theory Review and Practice) and a module exam.
• The module screen is the first page: the whole scene as a living miniature, with one pill per exercise and one for the exam.
• The LMS opens the player with the trainee's identity, and every result goes back to the LMS.
• No sales presentation: no gallery of panels, no presenter, no budget.

The interactive proposal (panels, presenter, /gen-proposal) is documented on its own: Interactive proposal.

2. What the trainee sees and does

2.1 Getting in

The trainee signs in to the platform (LMS) and opens the module; the LMS launches the player with their identity. The LMS's loading screen comes first, with the module's and each exercise's name, while the scene downloads; then the module screen. Without the LMS the player also opens with the unit's access code (for testing). On DEMO, the Test Owner of each unit's organization signs in with the unit's access code as the password.

2.2 The module screen

• The living miniature. The whole scene as a miniature, centred, cut only in height so the inside shows (no round base), with the action going: when the Blender file carries Demo_ actions (the demo the designers prepare, such as the Brokk breaking down a wall), they play in a loop with the Loop_ actions; otherwise the avatar tours the stations in order and each one's interactive points, with their animations, while the Loop_ actions run.
• The pills. One per exercise and one for the exam, each close to its place in the miniature and tied to it by a short line, with its state: not started, in progress, passed with its score, or not passed. Practice unlocks once Theory Review is passed (unless the LMS opens it directly). The exam shows when the LMS allows an attempt.
• The badge (top left): the trainee, the module, how many exercises are passed, and the Back to the platform button.
• The music. A soft background track from con-mgr's library, which starts on the first click (browsers allow no sound before) and stops when the scene is entered.
• The start card. A click on a pill enters the exercise; its start card shows inside the exercise, in the scene (not on the module screen): the exercise's name, its mission (the tasks in order), the controls and "Click anywhere to begin", with that kind of exercise's start music. When the trainee left the exercise halfway, the card says where it goes on ("You continue where you left off: task 3 of 8") and offers Start over.

2.3 The exercises

The exercises, their names and summaries, and which ones the exam takes are set in the configuration file ([module.*], chapter 10.4); without them the module has the three standard ones.

2.4 Inside the scene

Inside the scene everything works as in the proposal. What follows is that same description (where it says "the client", read "the trainee"):

The visit is a task exercise: the stations, in their order, are the tasks. Each one's instruction is the station's note, and what there is to do there are the interactive objects beside it (the hotspot, the sheet, the person, the screen, the controls). The guide asks for one task at a time, on arrival teaches the station and says what to do, confirms each task done, hints when the client gets stuck and closes with feedback. The checklist shows on the right, done tasks struck through; they can be done in any order. (The tuning panel can switch back to the narrated tour, or count a task done on arrival alone.)

Lessons. Every station has a lesson written at publish from the client's material and the scene configuration, with its infographic. On arrival the guide teaches it in full, one part per turn; with infographics, each one appears as she names it. The checklist's Lesson button has the guide teach it again from the start, changing no task. The check questions come from that same lesson.

Start screen. On entering the exercise (and after a reset) a screen shows the welcome line, the mission (the tasks in order, with their station's number and name) and the controls, with its own music. The guide falls silent the moment it opens (even mid-sentence) and says nothing until it closes: a click anywhere on it, or by itself after three minutes (a setting). The checklist and the dialog stay hidden while it is open, so the screen shows alone.

Assessment. When each task is done, the guide asks two short questions about that station, drawn from what she just taught (the proposal's material and the scene configuration). When she finishes asking, a card appears in the middle of the screen with her words, a line to type the answer and an I don't know button; while the check is open the client cannot walk or work anything. They answer aloud (the microphone opens when the question ends) or by typing; she scores each answer from 0 to 100 and the checklist shows each question's score and the station's average ("100 · 0 → 50 %", green when it passes, red when not). A grade counts only after the client has spoken or typed; if the guide grades before that, the grade is discarded and she repeats the question. While the check is open nothing else reaches the guide. A question unanswered for three minutes scores 0 and the next one comes. After each answer she says what the correct one was and why: one sentence if right, two if wrong. The rubric (100 complete and correct · 80 one minor omission · 60 the main idea · 30 related but wrong · 0 wrong or no answer; judged only against the proposal's material) and every instruction the page gives the guide are in the tuning panel, group "Instructions to the guide", saved per unit. The card appears once the action has fully finished and she has finished asking. When a hotspot is worked, the guide says in a sentence what the client just did and confirms it is done. While the action plays, an inset shows up close the instrument or part the animation moves, so its reading can be read; if the point carries a note with the reading, she says it when done. With every task done and checked comes the exam: the client repeats the whole exercise alone, in the correct order, with no checklist, no station numbers and no help; the guide stays silent until the end. Reaching a station means walking up to it (or using its marker, outside the exam); the station where the exam begins counts only after walking away and coming back. It is passed by completing every task with at least 70% of them in order and with the station checks' average at or above that same pass mark (setting checksCount; off, the practical alone decides). The report shows both parts with their own result. At the end she closes with the exam result, the check results and brief feedback, and the exam report opens: passed or not, tasks in order, time, and each station's check score with their average (green passes, red fails); the success or failure music plays while the report is open. The report closes or restarts the exercise; the result's Report button reopens it. If the client leaves the scene with the report open and comes back in, the report shows again, with Close and Restart; reloading the page starts the exercise over. (Questions per station, the exam and the pass mark are settings in the panel.) The final report fills most of the screen, in three tabs: Summary (result, score and score per station), Study plan for the next attempt, which the page builds from the slides themselves (per missed question: the slide that teaches it, quoted, and what to do in the scene: replay that slide with the Lesson button and click the station's objects), and Questions and answers (every question with your answer, the correct one, the feedback and the lesson sentence that teaches it). The Download PDF button saves the same report as a PDF file; the box “Include the full session transcript in the PDF” (unticked by default) appends the whole session's dialog at the end of the PDF, with the lines that cover the study plan's topics highlighted and the topic named under them. When the report is closed the exercise data stays in the browser: in the configuration panel (Ctrl+Shift+K), “Report: saved data” opens the last report again, saves the data to a file and loads a report from a file, without repeating the exercise.

The microphone inside the scene has two states, open and closed, and the badge at the top right says which. It opens only when the guide is listening: for a few seconds after each thing she says, and for as long as the client keeps talking. While walking, with a sheet open or while she explains, it is closed, so the room's noise never reaches her. To speak to her at any other time, hold the M key or click the badge. A VR headset has no keyboard and no badge: hold A or X on either controller, and a small sign below the view says whether the mic is open ("Listening") or how to open it. While a check question waits for its answer, in the headset she listens between her turns without any button (in VR there is nowhere to type the answer).

With a delivered Avatar, the client tours the scene as a character (third person by default); in VR they see their own body from the neck down and, with hand tracking, their real hands drive the avatar's.

2.5 The report and the platform

At the end, the exercise's report (Summary, Study plan, Questions and answers, Download PDF) also shows what happened to the result in the LMS:

• "Saving the result to the platform…" while it is sent;
• "Result saved to the platform.", with View the report (the LMS's report) and Back to the platform;
• when the LMS does not answer in time, the player looks for the result in the trainee's progress before offering anything ("Checking on the platform whether the result was saved…", then "Your result now appears on the platform."); it never sends it twice by itself;
• when the LMS refuses it, the report says so, with the reason the LMS gives.

Each exercise sends its result under its own code; the exam sends the module exam's result. Back on the module screen, the pill shows the new score.

2.5b The tablet

Inside the scene, the Tablet (T) button (or the T key) opens the trainee's tablet, which looks and works like an iPad. At the bottom, a bar holds its three apps, Videos, Documentos and Llamadas, with the chosen one lit. The tablet opens on the app last chosen.

• Videos: large thumbnails (a frame of each video) with title and length. Each opens in a player with play/pause, a scrubber and the time.
• Documentos: large thumbnails (each PDF's first page) with title and page count. Each opens on its pages (‹ › to turn them).
• Llamadas ("Calls" in English; video or voice only, by contact): the contacts as large photos. Without a photo, a contact with a Gemini Live Avatar shows that avatar's picture (Ben, Ingrid, Jay, Kira, Paul, Sam or Vera, kept with the player and cut as its video is); else their voice avatar; else their initials. The Mentor is the player's mentor, not the proposal's presenter: her name comes from the global profile (Camila Rojas) and she introduces herself by it in the live session; live_avatar (Kira) is only Gemini's identifier for her picture and video. The player's only video is a tablet call's: the guide in the scene is voice only. Calling a contact with a live_avatar (the Mentor included) opens a video session of its own with their Gemini Live Avatar, which ends on hang-up; until the video arrives, the call shows their Live Avatar's photo. A contact without a live_avatar shows their voice avatar: a 3D presenter in close-up whose mouth moves with their voice. The Mentor is the exercise's guide, in a call of her own. Any other contact is their own live persona: they answer in their own voice and from the unit's material, in their role. The guide is silent for the length of the call.

When there are more thumbnails than fit, ‹ › turns the page. The home indicator or the back button returns from a video, document or call to its app. The configuration file's [tablet] table says what each app holds and in what order (chapter 10.4); the Mentor's profile comes from the global configuration. In a headset (controllers or hands) the tablet is a panel in front of the trainee: it opens with the small button at the bottom left of the view, and everything is pointed at and pinched (or triggered). With nothing on the tablet and no guide (the Practice without [tablet]), the button does not show.

2.6 Leaving, coming back and restarting

• Esc leaves the scene for the module screen; the progress is kept and the start card offers to go on where it stopped.
• Reset progress (bottom left of the module screen) clears in this browser the progress of every exercise of the module and of the exam, as Unity's module reset does (PROP-61). What the platform has recorded does not change. Inside an exercise the checklist no longer has a reset button.
• Start over (on an exercise's start card) and Restart the exercise (in the report) start that exercise again as a new attempt: the start card, the welcome and the first lesson come back.
• A station's review questions in progress are kept too: after leaving, a reload or a closed browser, the review comes back at the question it was on, with its card, and the trainee answers it there (PROP-55). A question already answered is not asked again.
• A finished exercise does not resume when opened again: it starts over.

3. How a player is published

3.1 The sources

• The unit's Blender file, in Google Drive: the scene, its stations, controls and animations (chapter 8).
• The scene configuration file (TOML, chapter 10). The first publish takes it from Drive; from then on the reference copy lives in the content manager (con-mgr, the DEMO instance), and later publishes read it there.
• The unit's training material (manuals, procedures), in Drive: the lessons and the questions come from it, and, when the file does not give them, the module's and the exercises' names and summaries.
• The music, from con-mgr's library.

3.2 The command

In Google Chat, /gen-player CODE. The publish:

1. builds the player's package: the scene converted from the Blender file, the lessons, the guide's voice recorded once with the live guide's own model (and reused by later publishes), the music, and the module's icon, rendered from the Blender file (with its Icon_Camera when the scene has one);
2. prepares the LMS on DEMO through Support Admin, only what is missing: the unit's organization, its Test Owner (with the unit's access code as the password), the module and its exercises; it never edits what exists;
3. publishes the player at https://demo.trainbeyond.com/player/CODE/.

3.3 What a publish returns

The player's address; how many lessons and recordings it has, and how many were recorded this time; the LMS module and whether it was created or already there; and the findings (chapters 10.3 and 10.5).

4. Naming conventions — quick reference

The viewer is not configured: it reads the object and action names in the Blender file. Anything that matches no convention is plain scenery. Names are compared trimmed and case-insensitively; the separator can be _ or ..

Custom properties (Object Properties → Custom Properties) the viewer reads:

Several objects in one action: NLA tracks with the same name on each object (Play_Start on the button and on the piston) export as one animation. That is how the button sinks and the machine answers, or the knob turns and the needle follows.

Bone constraints (machines): the viewer solves these constraints of the scene's armatures live, as Blender does: Damped Track; Copy Location and Copy Transforms between bones of the same armature, in world space; IK of one or two bones without a pole (with its bones' IK locks and limits); Limit Rotation and Limit Location in local space. So with several actions at once (the boom and the arm), the cylinders keep aiming at their mounts, the hoses follow their control points and the tool stays on its mount. Actions should move only the bones that are really animated (boom, arm, tool, slew): what the constraints follow, the viewer places. Other constraints stay as each action bakes them, and the conversion log names them (BLEND_BONE_CONSTRAINTS).

A panel on the visitor's body: a remote the operator wears (on the belt) is parented in Blender to a bone of the Avatar (Bone parent type). It travels with the visitor, shows in first person when looking down, and its controls work with the pointer, the controller ray in VR or their keys. First person looks out of the middle of the open part of the screen, left of the checklist and dialog column: what the operator faces, the remote when looking down, is not under that column.

In the player only, also:

5. Forms (Clipboard_)

The form is an HTML page the designer writes: any layout, the plant's sheet as a table, inline styles, even a script that builds the rows. Rules:

1. Every box the client fills in is an <input>, <select> or <textarea> with a name.
2. The file goes with the unit's Drive sources: in a forms folder, or beside the client's documents (from-client). It is found by its name (e.g. corte.html).
3. In Blender, the Clipboard_Inspection plane carries the custom property form = corte.html (forms works too; on the object or on its mesh data). Model it in the paper's shape (landscape or portrait).

Minimal example:

<!doctype html>
<html lang="en"><meta charset="utf-8">
<style>body{font:12px Arial;padding:10px} td,th{border:1px solid #333;padding:2px} input{width:100%;border:0}</style>
<body>
<h2>Inspection · Cutting line</h2>
<label>W.O. <input name="wo"></label> <label>Date <input name="date" type="date"></label>
<table>
  <tr><th>#</th><th>Length</th><th>Defects</th></tr>
  <tr><td>1</td><td><input name="row1_length"></td><td><input name="row1_defects"></td></tr>
  <tr><td>2</td><td><input name="row2_length"></td><td><input name="row2_defects"></td></tr>
</table>
</body></html>

How it is used: on a computer, a click on the clipboard opens the page inside the proposal; in a headset or on a tablet, a phone opens …/FCA/?clipboard and every form in the scene appears there. What is typed shows on the paper for everyone in the scene. Without a page, fields = Name; Date; Notes... generates a plain form (... = multi-line). Full examples: docs/examples/clipboard-forms/ in the wrk-mgr repository.

6. Machine controls (Button_, Knob_, Joystick_)

1. Name the control Button_Start or Knob_Pressure (a mesh, or an empty with the control's meshes under it).
2. Create the action Play_Start / Play_Pressure with keyframes of the control and of what it moves: the button sinking and the piston rising; the knob turning and the needle following.
3. Export.

A knob's action is one pose per value, no cycles. A hotspot is still the choice when the avatar should walk to the equipment and make a gesture.

A panel with several controls. One panel can carry several buttons, knobs and joysticks at once, of any kind. Each needs its own name and its own action (Button_Start + Play_Start, Button_Stop + Play_Stop, Joystick_Boom + Play_Boom_X / Play_Boom_Y): two controls on one action move together. Each control counts as one item of its station's task, Blender copies included (Button_Stop and Button_Stop.001 are two items). In VR each hand works its own control: the joystick in one, the hold button in the other.

What the machine does with several controls at once (both sticks to drive, the stick's button with the stick for the arm, a mode selector, an emergency stop) is described in the configuration file, in [conditions] and [functions.Name] (chapter 10.2). On a computer each control can have its keys (keys) to work two sticks at once.

7. The audit (/audit-showcase)

Checks the delivered file before importing it. The report arrives in chat as several messages: a summary, then findings by severity.

Each finding comes with what it is and how to fix it, in the language of --es.

8. Full scene specification

Audience: 3D design team

Deliverable: one interactive scene per proposal, shown inside the client's interactive proposal

Format: .blend (Blender 4.x or 5.x up to 5.2, preferred) or .fbx — deliver the source file, we handle all export and optimization

What's new in v1.1

• Revised budgets: more triangles (≤ 600k), but new hard limits on meshes and materials — those are what actually decide performance. See the table.
• Embodiment avatar (Avatar + Idle / Walk / Act_* clips): the client tours the scene as a character, in third or first person.
• Interactions (Hotspot_ + Play_ + Act_*): points where the client operates equipment — opening a valve, pushing a button.
• v1 scenes without an avatar or hotspots remain 100% valid; the new sections are optional (but highly recommended).
• Viewer support for the avatar and interactions is in development — deliver scenes now regardless; the pipeline validates the names from day one.

What you are building

The scene appears twice in the proposal, from the same file:

1. Diorama — a tabletop-scale model at the center of the proposal gallery, like an architect's scale model. This is what the client sees first.
2. Inside view — clicking the diorama puts the client inside the scene at full scale: standing at locations you define, seated at eye points you define (vehicle cab, control chair), or touring it as a character (Avatar) in third or first person. The AI presenter narrates while they explore.

Design for both scales. The scene must read as an attractive miniature from above AND hold up at eye level from every viewpoint you place. Detail what a standing person will look at; don't detail what nobody will ever be near.

Hard requirements

We compress everything (geometry and textures) after conversion — you do not need to optimize file size beyond the budgets above.

Naming conventions — how your scene talks to the viewer

The viewer reads object names and animation (action) names to know how to behave. Objects that don't match any convention below are ordinary scenery.

Station_NN_Name — standing viewpoints (empties)

A place a person can stand. Add one empty per location, positioned on the floor (we raise the camera to the avatar's measured eye height automatically, and a station that is not on its floor is reported by /audit-showcase instead of being silently moved). The empty's rotation sets the initial view direction (its +Y axis is "forward" — enable Display As: Arrows to see it).

• NN = two-digit tour order (01, 02, …). Clicking the diorama enters at the lowest number.
• Name = human-readable label, CamelCase or hyphenated. The AI presenter says this name out loud — write Station_02_ControlRoom, not Station_02_stn2final.
• Visitors can hop between stations inside the scene, so place them where the tour makes sense: entrance → key areas → payoff view.
• The empty is authoritative. The viewer stands the visitor exactly where you put it and corrects nothing, so it must be resting on the floor. /audit-showcase measures every Station_ against the real floor and tells you before import if it is not.
• Add more than one. A single station means there is nowhere to navigate: no jump markers appear and the visitor only ever sees one thing.

Seat_Name — seated viewpoints (empties)

A locked, seated view: cockpit, crane cab, control chair. Position the empty at the exact eye point of the seated person (not the floor). The visitor can look around from there but cannot move.

Skybox — the sky (mesh, optional)

A large inverted sphere or dome, emissive material, equirectangular sky texture, surrounding the scene. Hidden while the scene is a diorama; revealed when the client steps inside. If you skip it, the viewer supplies a plain default sky — a real one is always better.

The sky image is wired to Emission, not Base Color. The viewer bakes the dome into an environment map inside a scene with no lights: a dome with its texture on Base Color bakes black and the whole scene goes dark (AER shipped this way). /audit-showcase reports it as skybox_not_emissive.

Loop_Name — ambient animation (action names)

Any action whose name starts with Loop_ plays automatically, forever, once the client is inside: Loop_FlareStack, Loop_Conveyor, Loop_Traffic. Make the first and last keyframes match so the loop is seamless.

Demo_Name — the first page's demo (action names, optional)

A training's first page (the player's module screen) shows the whole training area as a miniature: every station, seat and hotspot with the subject. Its walls and roof are cut 2.2 m above the highest floor the trainee stands on. What moves there is up to you:

• With Demo_ actions. Every action whose name starts with Demo_ plays there, all together, with the Loop_ actions.
• They start at the same moment and start again when the longest ends; a shorter one holds its last frame until then.
• The name after Demo_ is free, and may repeat with Blender's suffix (Demo_Controls.001).
• If one of them moves the avatar, it shows where you placed it in the file; if none does, it is not shown.
• Without Demo_ actions. The avatar goes through the exercise, round after round, while the Loop_ actions keep running.
• It walks from station to station, in their order. At each one it goes to its hotspots and makes their gesture (Act_) while the equipment moves (Play_).
• Several stations one after the other on one spot are one stop.
• It walks on the Navmesh when there is one; otherwise straight, as in an exercise.
• At the end of the round it walks back to the first station and starts another.
• None of this happens inside an exercise. On entry everything goes back to its starting pose, and Demo_ actions never play there.

In ALF the demolition demo is Demo_: the operator at the remote (Demo_Operador, Demo_Controles), the Brokk hammering the wall (Demo_Brokk_v3) and the wall's 50 pieces falling (Demo_Pared_Trozo_033_0…). TAC has no Demo_: its first page shows the avatar touring its five stations, using the micrometer and writing.

Avatar — the client's character (armature, optional)

A character the client "embodies" once inside: they can see it in third person (over-the-shoulder camera), look through its eyes in first person, or release it and fly free (drone mode, the current behavior). If the scene has no Avatar, the viewer works exactly as before — drone mode only.

• The root armature is named Avatar and all its meshes live under it. Its position in the file doesn't matter — the viewer spawns it at the entry station — nor where its bones sit relative to its origin: the viewer centres it on its feet (the skeleton's root).
• Avatar clips (staged on NLA like everything else):
• Idle (optional) — standing loop.
• Walk (optional) — walking in place (no root motion), at a natural ~1.4 m/s cadence; the viewer syncs playback speed to actual movement so feet don't slide.
• If the Avatar carries no Idle or Walk, the viewer uses shared ones (a man's stance and walk, on the Character Creator skeleton). Clips the scene brings always win: include them when the scene needs its own, for example for a woman's avatar.
• Act_Name (optional) — one-shot actions for interactions (see hotspots). A generic Act_Operate serves as the fallback for any hotspot without a specific clip.
• Avatar_Eyes (empty, optional) — the exact eye point; defines the first-person camera *and the standing eye height at every Station_**. Parenting it to the head bone is preferred, but we also read it if it sits loose in the scene. If absent we use ~94% of the avatar's measured height.
• Meshes that must disappear in first person (face, hair, lashes, glasses) are named with the Head_ prefix (Head_Face, Head_Hair). With no Head_ meshes, the viewer hides the whole avatar in first person.
• Hidden at diorama scale, like the Skybox. Its triangles count against the budget (~20–40k is typical).

Hotspot_Name — interactions (empties) — the name triad

A point where the client does something: open a valve, push a button, inspect a panel. An interaction is defined by up to three pieces that share exactly the same name:

Viewer behavior: approaching (~2.5 m) surfaces the prompt; on trigger the avatar glides onto the anchor and Act_ + Play_ play together, then it returns to Idle. While the action plays, an inset shows up close what Play_ animates (the instrument, the valve): model the reading legibly and leave the animation on the value to be read. reading in the [Hotspot_Name] table of the configuration file (or a Blender note property) has the guide say the reading when done. That's why the anchor matters: place it exactly where the feet should be and the hand will land on the equipment. Without an avatar (or in drone mode), clicking the marker plays Play_ alone — hotspots work in every scene, avatar or not.

• Interaction clips: ≤ ~10 seconds.
• The name is shown on screen and the AI presenter speaks it — Hotspot_OpenValve, not Hotspot_hs01.

Focus_Name — the diorama's subject (object or empty, optional)

Tell the viewer what the diorama is showing. In the gallery the scene is a diorama: the viewer scales it so its largest extent measures about 4 m. When a scene needs far more surroundings than subject — FER's cab has windows front and back, so the rails and the floor must run a long way in both directions — the surroundings own that scale and the subject ends up tiny.

• Name the main object Focus_Name (Focus_Train). If the subject is several objects, parent them under an empty with that name: everything under it counts. Several Focus_* objects frame their union.
• The diorama is scaled to and centred on the Focus_, not the whole scene. The rest of the surroundings keeps its real size and, in the diorama only, is trimmed to a round base a little wider than the subject, like a model railway on its plinth.
• Inside the scene nothing is trimmed: the rails and the floor are all there, at full scale, as far as you modelled them.
• A Focus_ with no mesh under it frames nothing, and the viewer goes back to measuring the whole scene; /audit-showcase reports it as focus_frames_nothing.
• Without any Focus_ everything works as before: the scene's largest extent rules.

Icon_Camera — the module icon's view (camera, optional)

/gen-player renders the LMS module's icon from this file: a 1080 px square image, like the other modules' icons. Without a camera it frames the diorama's subject (Focus_, or the whole scene) from behind and above the first station, leaving out whatever stands between the camera and the subject (a railing, a cabin's panels). To choose the view yourself, add a camera named Icon_Camera: it is used as it is. The avatar, the Skybox (the sky is neutral, as in the diorama), Collider_ objects and the Navmesh never appear in the icon. The light is the viewer's: the file's Sun and a neutral sky that nothing but the subject blocks, so a subject inside a cabin stays lit.

Screen_Name_NN — screens with image sequences (meshes)

A monitor, tablet or kiosk that shows a series of images (the screens of a registration system, say). Model the screen as a plane carrying the first image and duplicate it in place once per image: Screen_Registration_01, Screen_Registration_02, … each copy with its own image in the material (wired to Emission, so it reads as a lit display under any lighting). The viewer shows only _01; a click, a tap or the VR trigger on the screen advances to the next image and wraps around after the last.

• Frames must match exactly in position and size (Shift+D without moving); /audit-showcase warns when one drifted.
• Number from _01 with no gaps. A frame without a number (Screen_Menu) is ordinary scenery; a screen with a single frame does nothing when clicked.
• Every image counts against the texture budget; export the captures at 2K or less.
• The voice guide knows which screen the client is looking at and which image it is on; describe each screen in the tour-topics document (under the screen's name) and the guide comments on it.

Display_Name — live display (mesh)

A monitor that shows a computer's screen live: the client's real software (their registration system, say) running while the client practises in front of the character. Model the monitor as a 16:9 plane with a full UV (the image fills the plane) and name it Display_Registration. Whatever material you give it is what shows while nobody is sharing.

• The sharing computer opens the proposal with ?display at the end of the address and presses Share this screen; from then on every Display_* in the scene shows that screen. Both machines must be on the same network.
• One plane per monitor; several Display_* planes show the same image.
• For a fixed image sequence use Screen_; Display_ is for live software.

Character_Name — people the client can talk to (empty or root)

A person in the scene the client practises a real voice conversation with: a guest at the reception desk, a customer at the counter. The character is not modelled in the scene: the operations team delivers it on the publish command, like the showcase:

/gen-proposal UNIT --publish --showcase <scene> --character <model> --persona <doc> --idle <clip> --talk <clip>

• --character: the Character Creator 4 export of the character (.fbx, T-pose, no animation): the same standard as the presenter.
• --persona: a Google Doc with Name:, Persona: (who they are, what they want), Lines: (optional: what they say and the details they give — phone, e-mail, address — one per line; the person uses them word for word, never invents others) and Voice: (male Puck, Charon, Fenrir, Orus; female Aoede, Leda, Zephyr, Kore) or Gender: lines. Persona: and Lines: span the lines that follow; name, voice and gender take one line each. Every character speaks with a voice different from the guide's.
• --idle / --talk: motion-only .fbx clips on the Character Creator skeleton (exported from Character Creator or iClone, or bought on ActorCore): standing loop, and while speaking. A Mixamo clip is retargeted onto the CC skeleton at publish. Without these flags the last imported clips are used.

Your part in the scene is the spot: an empty (or any object) named Character_Name where the person stands, with the same Name as the persona doc, facing where the client will be. The viewer puts the delivered model there and hides the marker. Within ~2.5 m the prompt E — 💬 Name appears; E, a click or the VR trigger starts the conversation and the guide stays quiet; it ends with E again, another click, walking away (> 4 m) or the person saying goodbye, and the guide comments on how it went.

• Without a scene (--character and no --showcase), the person appears life-size in the client's room through the Practise in your room (AR) button, with a generated Display_ screen in front of them.
• With a scene, on a passthrough headset that same button places the person and the Display_* planes in the client's room; the scene is turned so the person faces Station_01.
• Action paths (optional): instead of staying on its spot, the person can follow a path between stations — greet, walk to the filing room along the Navmesh, sit at the desk, work a while, get up and repeat; a conversation pauses it. It is written in the configuration file (path in [Character_Name], see chapter 10 of the proposal system guide). A station only characters use is one more Station_NN_Name that no exercise lists in its task_stations; where the person sits, that station's empty faces the way the seated person looks. Its actions are the scene's Act_Name animations (the same as the Avatar's) or imported separately.

Clipboard_Name — forms the client fills in (mesh, optional)

A clipboard with a form the client fills in during the practice: a new-customer registration, an incident report, the plant's own inspection sheet. Model the clipboard as a plane with full UV, in the paper's shape (portrait or landscape), and name it Clipboard_Registration. The material you give it is what shows when nobody is in the scene; inside, the viewer draws the form with what is being typed.

• The form is an HTML page you write: any layout, the plant's sheet as a table, inline styles, even a script that builds the rows. Every box the client fills in is an input, select or textarea with a name. Keep the page with the unit's sources in Drive (in a folder named forms, or beside the client's documents) and put its name in the object's form custom property (corte.html; forms works too, and the property may sit on the object or on its mesh data). A full address works too, and so does the page itself inside the property. Ready examples in docs/examples/clipboard-forms/.
• Without a page: a list of fields in the fields property, separated by ; (Name; Date; Notes...; a field ending in ... is multi-line) makes a plain form. Optional: note, one sentence on what the form is for.
• How it is filled in: on a computer, a click on the clipboard opens the page inside the proposal; in a headset or on a tablet, open the proposal on a phone with ?clipboard at the end of the address and every page in the scene appears there. What is typed shows on the paper for everyone in the scene (a picture of the page; external stylesheets and images stay out of the picture, hence inline styles).
• The voice guide only hears about a form when it is part of a task (see The stations are the tasks): on submit, or on close with every field filled in. /audit-showcase reports a Clipboard_ with neither form nor fields, one that is not a mesh, or one that is not a plane (clipboard_not_a_plane): a modelled clipboard or a whole computer with that name is not painted — the paper or the screen needs its own plane.
• Inside the showcase, touching the clipboard brings the camera close to the object and the page appears alone over it, with no frame; closing it returns the camera.

Show_Name — objects the guide points out one by one (objects, optional)

For a station with several objects the guide explains one at a time — PPE on a table, tools on a bench — name each object Show_Name (Show_Helmet, Show_Nitrile_Gloves). While the guide talks about an object it glows orange; moving on to the next one turns the previous one off.

• Each Show_ belongs to the nearest station (Station_ or Seat_): just name the objects on the table, nothing has to be parented.
• The name is what the guide says aloud; write it the way it is spoken, with underscores between words.
• Optional: a note custom property on the object with one sentence about it (Protects against chemicals); the guide expands it while describing it.
• If the object is several pieces, parent them under an empty named Show_: everything under it glows.
• The guide decides the order as it talks; the glow lasts while it describes the object and turns itself off after a few seconds if nothing changes it.
• A click on the object lights it and the guide describes it (again, if need be), with its note when it has one.
• The object lights up when the guide says its name: that is why the name must be what one says about the object (Show_Nitrile_Gloves, not Show_Obj17).
• The name is recognised as whole words, in order: Show_Chalk lights on "the chalk" or "chalks", not on a word that merely contains it. Little words (of, the, a) may be added or dropped ("leather gloves" counts for Show_Gloves_Of_Leather); a number is said as written in the name ("20 metres" for Show_Tape_Measure_20_metres, so write it the way the guide will say it). When one name is contained in another (Show_Gloves and Show_Leather_Gloves), the longer wins where all of its words are said.
• Only the objects at the station the client is standing at can light up: a tool on the next bench that shares a word with one here does not take the glow.

Navmesh — the surface to walk on (mesh, optional)

When the visitor goes to a station or an interactive point with a click, the character walks a path on the scene's Navmesh, around tables, railings and rollers instead of through them.

Add a mesh named Navmesh (or Navmesh_Plant, anything starting that way) with the walkable surface: aisles, platforms, ramps. The viewer hides it on load (never drawn, no shadow, not a stop) and builds a floor grid from it. Only Collider_ objects block cells above it: the rest of the scenery is not read, so give everything the visitor must walk around a Collider_. Between cells the path never climbs or drops more than a step.

• One mesh or several; they only need to sit level with the real floor (± a step).
• Without a Navmesh, a click goes in a straight line.
• Settings in the panel and in the configuration file, group nav: cell size, step height, the visitor's width, walking speed.

Collider_Name — invisible stops for the visitor (meshes, optional)

The visitor collides with the scene's meshes (six horizontal rays, ankle to head). Where the geometry leaves gaps between those rays — a guardrail's bars, a railing, a cable, a very thin showcase — place a simple box or plane named Collider_Name (Collider_North_Rail) over the zone that must not be crossed. The viewer hides it on load: it is never drawn, casts no shadow, is not a floor and cannot be pointed at; only the visitor's steps feel it.

• Leave it visible in Blender with any material; the viewer hides it.
• One box per stretch is enough; it need not follow the object's shape.
• /audit-showcase reports a Collider_ that is not a mesh (collider_not_a_mesh).

Door_Name and Open_Name — doors that open and are walked through (mesh or root, and an action, optional; v1.6)

A door is the object Door_Name (Door_Storeroom): the leaf as a mesh, or a root with the leaf under it. Its scene action Open_Name (Open_Storeroom) opens it: the viewer plays it forward to open and backward to close, and it holds its last frame.

• A click on the door opens it; another closes it. Shut, the visitor bumps into it and routes (a marker click) do not pass its doorway; open, it is walked through.
• The Navmesh must run through the doorway: the shut door closes it by itself.
• A door with no Open_ action does not open: it stays a wall (the viewer says so in the console).
• To another exercise (PROP-60): with the custom property exercise on the door (the code of an exercise of the same module, or its suffix: PR), the door is locked until the trainee completes the current exercise; it then opens and, walked through, starts that exercise (its start card inside the scene). While locked, a click says what is missing.

Button_Name, Knob_Name and Joystick_Name — controls on a machine (meshes, optional)

Buttons, knobs, levers and gauges the client operates right on the equipment: press the start button and the conveyor runs; turn the pressure knob and the gauge needle follows. They need no anchor and no avatar: the client works them from wherever they stand, with a click, the headset trigger or a hand.

• Name the control Button_Start or Knob_Pressure (a mesh, or an empty with the control's meshes under it). What it does lives in the action Play_Start / Play_Pressure: there, as keyframes, goes both the control's own motion and the motion of what it drives — the button sinking and the piston rising; the knob turning and the needle following. Several objects in one action: NLA tracks with the same name, exactly as for a hotspot's Play_. To use another action, put its name in the plays custom property.
• Button_ plays the action once when pressed. With the mode property: toggle (the action repeats until pressed again; switching off returns everything to rest), hold (runs forward while held and back when released) or latch (runs to the end and stays there until pressed again, which runs it back: an emergency stop pushed in and pulled out; its action ends with the button in).
• Knob_ scrubs the action: its start is the knob at minimum, its end at maximum. It turns by dragging with the mouse (or the wheel), or in the headset by holding the trigger and raising or lowering the hand. The steps property (5) gives it fixed positions, and value (0 to 1) says where it stands when the scene loads: steps = 2 and value = 0.5 is a three-way selector starting in the middle.
• Indicator_ is a light on the machine (a mesh): it glows in the colour the configuration file says ([indicators.Name]), from the machine's state; dark, it shows its own material. If it is a display that shows words ([indicators.Name.text]), give it a full UV: the image fills the display, with the top of the display at the top and its left at the left, as its user sees it (a mirrored UV shows the words backwards).
• A Knob_'s action must be one pose per value, no cycles: each point of the action is one position of the knob and of what it indicates.
• Joystick_ has two axes and drives two actions: Play_Name_X (left → right) and Play_Name_Y (back → forward); the middle of each action is the stick centred. Model the stick with its pivot at the base: the viewer tilts it by itself (tilt property, degrees; 20 by default). By default each axis scrubs its action like a knob (mode = position); with mode = rate the action runs while the stick is pushed and stays where it is when let go — a crane boom that keeps slewing while the stick is held (speed property: fraction of the action per second at full push, 0.5 by default). Letting go springs the stick back to centre, unless sticky = 1. It is moved by dragging with the mouse, or in the headset by holding the trigger on it and using the controller's thumbstick; that thumbstick also turns a held knob.
• Several controls on one panel. A panel can carry several Button_, Knob_ and Joystick_ together. Each control has its own name and its own action: two controls on one action move together. Each is one item of its station's task, Blender copies included (Button_Stop and Button_Stop.001 are two items with the same label). The control under the pointer (or under the controller's ray in VR) is worked, never its neighbour; in VR each hand holds its own control. What the machine does with several controls at once (both sticks, a button with the stick, a selector) is not in Blender: it goes in the configuration file ([functions.Name]), which names the machine's Play_ action. So each control's action moves only the control and the operator's hand. A machine action driven by a stick has the machine at rest in its middle, like the stick's own actions; the others at their start (or where rest says). The actions of several functions add up, so they may share bones, like hoses that follow both the boom and the arm. For the machine to travel freely (tracks), its action moves only the rig's root and the function has travel = true: the machine goes as far as it is driven. Put a Collider_ round the machine: it travels with it, stops it at walls and people, and the visitor bumps into the machine wherever it is. A cable between two parts (from the machine to its power source) is an empty Cable_Name with the properties from and to (the names of the two parts it joins), radius (metres, 0.012 by default) and color: the viewer draws it from each end down to the floor and along it, and draws it again when an end moves (the machine travels, the plug is pulled).
• Bone constraints. The viewer solves a machine armature's constraints live, as Blender does: Damped Track, Copy Location and Copy Transforms (between bones of the same armature, world space), IK of one or two bones without a pole, Limit Rotation and Limit Location (local space). Cylinders, hoses and the tool stay in place with several actions at once. Animate only the bones that really move; the constraints place the rest.
• A remote on the visitor's body. Parent the remote (its Button_, Knob_, Joystick_ and Indicator_) to a bone of the Avatar: it travels with the visitor and works the same. Its housing may be skinned to that same bone. In third person the viewer shows a close-up of the remote in a corner, seen from the operator's eyes; it frames the controls' common parent plus the meshes skinned to it alone. In first person, looking down, the view moves over the remote so all of it fits. The controls' short names (label in the configuration file) float beside them, in that close-up and in first person.
• Two buttons on one stick. Each button is its own Button_ with its own action, a child of the stick so it tilts with it (on the Brokk, Button_Percutor is B1.LL and Button_B1LR is B1.LR, side by side on the left stick's head).
• /audit-showcase reports a control without its Play_ action or one that is not a mesh.

Lights

Your Skybox is the scene's main light. The viewer bakes it into an environment map (IBL), and that is where all ambient light and every metal reflection comes from. It is the same thing Blender's world does, and it is the biggest lever you have over how the scene looks. A well-exposed sky lights the scene well; a flat or dark one leaves everything dull.

The Sun decides where shadows fall. The viewer takes its direction and colour, not its intensity: Blender exports W/m² converted to lux and the viewer rescales again, so intensity does not survive the trip usefully. The viewer sets its own strength, calibrated against exposure. Aim the Sun how you want the shadows and ignore its Strength value.

The first Sun (directional light) in the scene is the one used; a second sun is not switched on. Point and spot lamps are: in the player, inside the scene at full size, every one you place lights at the strength you gave it (in the miniature they are off, since that close they would burn it out). For an interior they are the light that counts: light it the way you want it to look.

It has to be a Sun-type lamp: a Point or Area light named "Sun" does not count (AER shipped a 17.8-million-candela point and the viewer ignored it — no sun direction, no authored shadows). /audit-showcase reports it as sun_not_directional.

The ground must not set the diorama scale. In the gallery the scene is shown as a diorama: the viewer scales the scene's largest extent (Skybox and Avatar excluded) to 4 m. A ground plane or apron much larger than the subject becomes the whole diorama and the subject turns tiny (AER's airliner rendered 0.8 m on a 185 m apron). Trim the ground to the walkable area, or — when the scene needs those surroundings, like rails that must look long from the cab — name the subject Focus_Name and the ground stops counting. /audit-showcase reports it as diorama_fit_dominated.

Until 2026-08-14 this section claimed every light lit the inside view. It did not: the converter never exported them. Fixed.

The stations are the tasks (nothing new to name)

The visit is not a stroll: it is a task exercise, and the tasks are your Station_NN_Name (then the Seat_) in their order. Nothing has to be added:

• Each task's instruction is task in the [Station_NN_Name] table of the scene configuration file (see the system guide, chapter 10); without it, the station's Blender note property; without either, its name.
• What there is to do there are the interactive objects nearest to that station — the same rule as Show_: the Hotspot_, the Clipboard_, the Character_, the Screen_ or the controls standing beside it.
• The task is done when the visitor reaches the station and does everything there: works the hotspot, clicks every Show_ object, hands in the sheet or closes it answered (every required field when the page marks any, else something changed on it; a fields sheet wants all its fields and has a Submit button; closing it untouched earns a reminder from the guide; a Clipboard_ with neither form nor fields does not count), ends the conversation, advances the screen to its last image, works the control. A station with nothing to do is done on arrival.
• Several tasks at one place. When several tasks are done where the visitor already stands (the Brokk: switching it on, its tracks, its arm and its hammer, all from the operator's spot), put their Station_NN_Name empties on the same spot (within 25 cm of each other). The visitor does not walk between them: when a task is done, the next one at that place starts right there, with its lesson and its questions. One marker shows per place, the due task's. The machine's functions and states choose their task with station in the configuration file.

The guide asks for one task at a time, on arrival teaches the station and says what to do there, confirms each task done, hints when the visitor gets stuck and closes the exercise with brief feedback. A checklist on screen shows the tasks, done ones struck through; they can be done in any order.

After each task the guide asks two questions about the station (only about what she taught on arrival; the lesson comes from the scene configuration file and the material) and grades the answers. At the end, the exam: the whole exercise again, alone, in order, with no markers and no checklist; the guide stays silent until the close. None of this is named in Blender.

How the viewer uses your scene

• The camera enters at the delivered avatar's own eye height over the Station_ empty exactly where you put it (no raycast, no self-healing): Avatar_Eyes minus the bottom of the rig's bounds. With no Avatar_Eyes we use ~94% of its measured height; with no avatar at all, 1.7 m. Seat_ points are honored exactly.
• The client can look (drag), turn and walk (arrow keys — the camera follows the terrain: curbs and stairs work, but the ground can only lift a visitor by about a knee, so a roof overhead is never walked onto), toggle a bird's-eye view (space bar), and hop between stations (numbered markers).
• With an Avatar, the client enters in third person and can switch third person / first person / drone mode. The avatar obeys the same ground rules as the camera.
• In VR, the visitor sees their own body from the neck down: the body follows the headset (physical steps included), turns when the visitor turns — not when they merely glance — and blends Idle/Walk from actual ground speed.
• Hand tracking (IK): with bare hands (no controllers), the visitor's REAL hands and fingers drive the avatar's arms and fingers. For this to work the rig must keep: (1) the exact Character Creator CC_Base_* bone names — no renaming or retargeting on export; (2) the T_Pose clip in the export; (3) metre scale, in-place animations; (4) a single armature under Avatar. When the visitor lowers their hands (out of the headset's cameras), the arms ease back to the animation — expected behaviour, not a bug.
• Near a Hotspot_* the interaction prompt appears; the viewer glides the avatar onto the anchor before playing the clips.
• A click (or the VR trigger) on a Screen_ advances it to the next image; near a Character_, E (or a click) opens a voice conversation with that character, who speaks with its own voice.
• Design consequence: the ground between stations should be walkable and continuous; compose each station as a shot, but remember the client can walk away from it.
• Coming soon: the same scenes will also be explorable in VR headsets (Quest). No extra work on your side — but real-world meter scale and the performance budgets matter even more.

Delivery and feedback

Deliver the file the same way as any showcase model (Drive link to the operations team). The publish pipeline validates the scene automatically and reports problems by name in the chat card — e.g. "Station_03 sits 4.2 m above the ground — stations belong on the floor" or "scene is 17 m wide but declares walkable stations — rescale to meters." Fix and re-deliver; re-publishing is cheap and the model is reconverted only when the file actually changes.

Before anything is imported, the operations team can ask for a check with /audit-showcase <drive link>: it opens your file without converting or publishing it and answers in chat with what it found — missing linked libraries, images Blender could not load, hidden objects that would never reach the export, clip names outside the conventions, the scene budgets, and since September 2026 also whether the Sun is directional, whether the Skybox is emissive, and which object sets the diorama scale. If something is off you hear about it in minutes, without touching the client's proposal. The card shows the first six affected items of each finding; the full report (every texture with its size and the materials using it, hidden objects, stations against their floor) is at the link at the end of the card.

Two cases are rejected outright, because the client would open an empty scene: a file with no geometry (what a master file whose linked libraries were not delivered with it produces) and a texture with no pixels (an image whose file Blender could not load). The message names the objects that did arrive, or the materials affected.

Pre-delivery checklist

• 1 unit = 1 meter; all scales applied; scene is real-world size
• At least one Station_ (or Seat_) empty, on the floor (seats: at eye point), forward direction checked
• Station and hotspot names are presentable — the AI presenter speaks them
• Skybox dome present (or consciously skipped), image wired to Emission
• One Sun-type lamp (not point/area) aimed the way you want the shadows
• Ground or apron no more than ~1.5× the subject's size, or the subject is named Focus_Name — otherwise the ground sets the diorama scale
• Ambient motion staged as Loop_* NLA actions, seamless
• Optional: the first page's demo staged as Demo_* actions; without them the avatar tours the stations and their hotspots
• If you include an Avatar: head meshes prefixed Head_; Avatar_Eyes on the head bone (recommended); Idle and Walk on NLA only if the scene needs its own (Walk in place, no root motion)
• Hotspots: anchor where the feet go, +Y toward the equipment; the Hotspot_X / Play_X / Act_X triad shares the exact name
• Screens: Screen_X_01, _02… duplicated in place, one image per frame (Emission), numbered with no gaps
• Live display: Display_X, a 16:9 plane with a full UV
• Characters to talk to: a Character_X empty where the person stands (the model, persona and clips arrive with --character, --persona, --idle, --talk)
• Objects described one by one at a station: each named Show_Name, optionally with a note
• Forms the client fills in: Clipboard_Name planes with the HTML page in form (or a list in fields)
• Invisible stops where steps would pass through railings or cables: Collider_Name boxes
• Machine controls: Button_X / Knob_X with their Play_X action (the control and what it moves, in one action); Joystick_X with Play_X_X / Play_X_Y
• Principled BSDF everywhere; procedural textures baked; textures ≤ 2K, ≤ ~24 images, packed into the file
• No broken images: if Blender cannot find a texture's file it exports empty and the delivery is rejected
• ≤ 600k triangles; ≤ 150 meshes after joining; ≤ 25 unique materials
• Walked every station/seat viewpoint in Blender (Numpad 0 on a camera at the empty) — it looks composed, not accidental

9. For developers

• The package and its build: docs/workers/player.md in wrk-mgr (build_player_package, the module screen, the music, the launch from the LMS).
• The publish (/gen-player, the LMS on DEMO, con-mgr, the music): docs/player.md in flow-mgr.
• The player's code: workers/interactive_web/player_shell/ in wrk-mgr, independent of the proposal's (app_shell).
• End-to-end tests: tools/evidence/station_walkthrough.py UNIT --player (with --lms USER --lms-module CODE --exercise TU|TE|PR|EXAM), on Control1's evidence browser.

10. The scene configuration file

It is the proposal's own file. Everything below applies to the player; what only the player uses is in 10.4 and 10.5.

One file per unit, in TOML, in the unit's Drive sources, whose name contains scene config or configuración de la escena (case and accents ignored). It is read at publish and on every /gen-proposal CODE --showcase. It holds three things: the exercise's settings (the same ones in the tuning panel), one table per scene object under its exact Blender name, and the guide's instructions. The former "scene topics" document no longer exists.

How it combines with the panel (Ctrl+Shift+K): the file is the baseline; whatever is saved in the panel sits on top, per unit. A long value (an instruction) is edited with the … button in a large box. The object tables appear in the panel as the Scene objects group and can be corrected and saved there too.

[quiz]
perStation = 2
passMark = 0.7

[tasks]

[prompts.rubric]
text = "..."

[scene]
welcome = "Bienvenido a la línea de inspección."

[Station_01_Placa]
task = "Revisa la placa: estencilado, medidas y espesor"
topic = "Qué se verifica en la placa y por qué importa"
description = "The plate table at the mill entrance: the plate on the rollers, the 0-1\" micrometer, the tapes and the F-TUAC-022 report on its clipboard"
questions = [["¿Qué datos del estencilado verificas?", "colada, proveedor y grado"], ["¿Con qué mides el espesor?", "con el micrómetro"]]

[Hotspot_Micrometer]
action = "Mide el espesor de la placa con el micrómetro"
reading = "12.50 mm"

[Clipboard_Inspeccion]
instructions = "Captura la colada y el espesor medido"
[Clipboard_Inspeccion.expected]
Espesor = "12.50"

[Show_Balde_De_Pintura]
note = "Pintura de marcado para identificar la placa aprobada"

10.1 Settings

One table per panel group; the keys are the panel's, nested as tables or dotted (card.radius = "14px"). Default in parentheses.

[render] — Render resolution

[video] — Presenter video (Kira)

[caption] — Captions

[presenter] — 3D presenter animations (Camila)

[lighting] — Gallery lighting

[face] — 3D presenter face

[guide] — Guide inside the scene

[gaze] — Visitor gaze (the tour only: the task exercise never uses gaze)

[tasks] — Task exercise

[quiz] — Assessment: checks and exam

[sound] — Sound

[mic] — Microphone while she speaks

[listen] — Microphone: when she listens

[show] — Glow of the objects she names

[markers] — Markers

[actpip] — Action close-up

[nav] — Navigation (paths)

[characters] — Characters: action paths

For characters with a path (see [Character_Name] in 10.2).

[lessons] — Station lessons

At publish the system writes one lesson per station from the proposal's material and the scene configuration: title, objective, every key point and step the material gives (no cap), safety, the check questions with their answers, and a board of slides (up to slides): each slide has a title, a few labels carrying the figures and an infographic generated with the image provider and model of [lessons]. Every infographic of the unit gets the same reference images: the client's material images (its documents' figures and its photos), in their order, up to referenceImages; when the material has no images none are sent and the infographic is drawn from its description. The guide teaches the whole lesson on arrival, slide by slide, naming each one ("Slide 2: …"); when she names one, its infographic appears alone on screen (no frame, title or controls), stays showSeconds or until she names another, and fades out; the checklist's Lesson button has her teach it all again from the start (it does not mark, complete or check it again; choosing another station meanwhile only quiets her). Without infographics (drawing them is off by default: each one is paid) there is no board and the lesson never mentions slides: the guide teaches the same parts, one per turn, each by its topic. The microphone is closed for the whole lesson: nothing interrupts it until it ends. The check questions come from that same lesson (unless the station's table carries questions). The lesson is rewritten only when the material, the configuration or the scene changes. An infographic is drawn only when its slide has none, or when the publish command names it with --redraw: never by itself, not because the slide's text, the style, the provider or the model changed (every image is paid for).

[telemetry] — Telemetry

[prompts] — Instructions to the guide

Each key is a table with es and en (the instruction in each language); {n} is a number the page fills in. rubric and protocolExtra carry text only.

[controls] — Control panel: keys and functions

10.2 Scene objects

One table per object, under the exact Blender object name ([Station_01_Placa], [Hotspot_Micrometer], ["Show_Balde_De_Pintura"]): that is how they match. The keys depend on the prefix. A name with accents or spaces is written as it is, with or without quotes ([Show_Tapones_Para_Oídos], [Station_03_Mesa de herramientas]).

[Station_NN_Name / Seat_Name]

[Character_Name]

[Character_Alejandra]
path = [
  { act = "Saludar" },        # an animation, once
  { walk = "Archivo" },       # walk to that station along the Navmesh
  { act = "Buscar" },
  { walk = "Escritorio" },
  { sit = true },             # sit, facing the way the station's empty faces
  { work = [20, 60] },        # hold what it is doing (seated work, or idle standing) 20 to 60 s
  { stand = true },           # get up
]

• Places are stations: walk names a station by its name (Archivo is Station_03_Archivo; case and accents do not matter). A station only characters use is an ordinary station no exercise lists in its task_stations ([module..exercise.], in the player's documentation).
• act = "Name" looks for the animation in this order: one delivered for that character, the scene's Act_Name, and the one imported for everyone with scripts/character_clips.py import --act Name --url …. Sitting down, seated work and standing up are animations by those names ([characters] sitDown / seated / standUp). Walking: one delivered with the character, or the shared one (the woman's when its Gender is female).
• The path starts when the visitor enters the scene and starts over on each entry; in the gallery and in the augmented-reality exercise the character stays still on its idle.
• A conversation pauses it: walking, it stops and turns to the visitor; seated, it talks from the chair. When the conversation ends it carries on from the same step. Walking up and pressing E never makes it leave.
• A station the visitor is at, or heading to, is taken: a character whose next walk goes there waits where it is until the visitor leaves. The other way round is the station's occupied (above).
• Without a Navmesh it walks straight. Characters do not steer around each other or the visitor.

[Hotspot_Name]

[Clipboard_Name]

[Show_ / Screen_ / Button_ / Knob_ / Joystick_]

[scene]

The tables only the training player uses ([module.*], title in [scene]) and the /gen-player findings are in the player's documentation.

Without a table for an object, the page uses the object's Blender note property if present, else its name. Everything in a table also reaches the guide as text, so she can answer questions about it.

Machine functions: [conditions] and [functions.Name]

On a real machine, what the machine does comes from several controls at once: both sticks up drives the tracks; the right stick's button held with the stick forward moves the arm; the regulator sets the hammer's power. Each control moves its own Play_ action (the control itself, the operator's hand); what the machine does is described here, one table per function.

[conditions]
ready = ["Button_S0 off", "Button_S1 on"]

[functions.Drive_forward]
label = "Drive forward on the tracks"
when = ["ready", "Joystick_Turret.y > 0.2", "Joystick_Boom.y > 0.2"]
plays = "Play_Tracks_Machine"
follows = "Joystick_Turret.y"

[functions.Regulated_hammer]
label = "Hammer at regulated power"
when = ["ready", "Button_Hammer held", "Knob_R1 > 0"]
plays = "Play_Hammer_Machine"
speed_from = "Knob_R1"

[functions.Drive_both_tracks]
label = "Drive forward on both tracks"
when = ["ready", "Knob_S5.step = 0", "Button_B1LR held", "Button_B2RL held"]
plays = ["Play_Track_Left_Machine", "Play_Track_Right_Machine"]
drive = 1

Conditions (in when and in [conditions]): the name of a [conditions] set, or a control with its test:

Comparisons: >, <, >=, <=, =. not in front negates a control condition. The function is active while all hold. Control names are written as in Blender, without spaces.

Each function is an item of its station's task: done once it stays active for [controls] functionDoneS seconds. At a station with functions, the controls are no longer items of their own nor news to the guide: the task is what the machine does. The controls' actions should move only the control (and the operator's hand); the machine's movement goes in the actions the functions name.

Function actions add up. As the scene loads, the viewer stands the machine at each action's rest pose (rest), and each active function adds how far its action moves away from that pose. That way both sticks at once move the boom and the arm fully, even though Blender exports every bone of the arm in each action and the hoses move in several actions. Played whole, each action would hold at rest what the other moves, and the viewer would average them to half. The same goes for a stick's two axes, which add up from the centre.

Machine states ([states.Name]): what the machine remembers, such as the control unit switched on, the motor running or the control circuit made.

[states.on]
label = "Switch the control unit on"
set = ["Button_S1 held"]
clear = ["Button_S0 on"]

[states.circuit]
label = "Make the control circuit"
set = ["on", "Button_Reach held"]
clear = ["not on"]
idle_s = 3

A state turns on while all its set conditions hold and off while all its clear conditions hold (when both hold, it turns off). With idle_s it turns off by itself after that many seconds with no function active: the Brokk's circuit drops after 3 s and the stick's button makes it again. With hold_s it turns on only once its set conditions have held that many seconds without a break: the Brokk's main switch Q1, 3 s at 0 before the other phase. With while it can only be on while all those conditions hold: the motor, while the unit is on and the machine has power (clear needs all its conditions at once, so it could not stop it on either one). With last = true, a state with a label is listed after the functions: disconnecting comes last. With initial = true it starts on. A condition names a state the way it names a [conditions] set (on, not circuit). A state with a label is also a task item: it counts the first time it turns on and comes before the functions in the list, because the start-up comes first. It also takes note and station.

Indicators ([indicators.Name]): a light on the model, the mesh Indicator_Name (or another that node names). Each colour (green, yellow, red, orange, blue, white) lists the conditions that light it; the first that holds wins, and when none holds the light keeps its own material.

[indicators.LED2]
green = ["circuit"]
yellow = ["on", "not circuit"]

A display shows words while it is lit: its text table pairs a condition (a state, a [conditions] set, or a control's condition, quoted) with what the display says at that moment. The first that holds wins; when none holds, the display only glows. \n separates the lines. The words are drawn as a backlit screen, the lit colour behind and the letters dark. The mesh needs a full UV (the image fills the display) with the top of the display at the top and its left at the left, as its user sees it; a mirrored UV shows the words backwards.

[indicators.Display]
green = ["on"]

[indicators.Display.text]
motor = "+23°C   20 bar\n102 h"
on = "BROKK\nStart Engine"

Instead of words, a text entry may be a screen laid out like the machine's own, as an inline table:

[indicators.Display.text]
motor = { lines = ["+23°C  20 Bar", "102 h"], left = "battery 4/4", right = "signal 4/4", mark = "lubrication" }
on = { logo = "BROKK", lines = ["START ENGINE", "(I)  (M)"] }

Symbols: battery, signal, oil, lubrication, service. Everything is drawn in the dark ink on the lit colour. The page draws the screen itself: no image is needed.

An indicator also takes note (what the guide knows about it) and label, its short name ("LED2"), shown beside it as a control's is. The machine's own lights (its work lamps) are indicators too: an Indicator_Lights mesh lit white with the motor.

The panel's close-up and labels

While the visitor works a panel (they are at its controls' station and no card is open):

• In third person a close-up of the panel appears in the bottom left corner, seen from the operator's eyes with the far edge up, as first person sees it. The shoulder camera cannot see a remote hanging from the belt, because the body is in front of it. The person is not drawn in that inset, because its camera sits between their eyes and the panel. The controls fill most of the inset: they are framed by their own boxes, centred, with room for the labels. Nothing between the camera and the panel hides it (a beam, say). While an Act_ animation plays, its own close-up comes first. In a VR headset there is no inset.
• In first person, looking down at a remote the visitor wears (on the belt), the view moves over the remote's middle and backs off just enough for all of it to fit the open part of the screen. It stays whole while the body sways standing still. Looking up again, the camera is back at the eyes.
• Labels: each control or indicator with a label has its name floating beside it, with a line to it: in the third-person close-up and over the first-person view. A label goes on the side facing away from the panel when that side is free, else the next free side, clear of other controls and labels. With no free side it takes the one that costs least: a line crossing another costs more than covering part of a control, because it reads as the other's label. Two labels whose lines still cross swap places. It keeps its side while that stays free, so it does not jump as the view sways.
• A remote the visitor wears is its station's panel even when the station also has controls fixed in the scene (the machine's main switch, a plug): those are worked where they stand, and the close-up, its labels and the first-person framing are the remote's.
• The panel is what holds all its controls and indicators: their nearest common parent in the model (on the Brokk, the remote's Control bone) plus the meshes skinned to that parent alone (the remote's housing). When their common parent is the whole avatar or the whole scene, the inset frames the controls alone.

10.3 Findings at publish

10.4 Player only

/gen-player reads the file from con-mgr (DEMO); the first time it takes it from Drive and stores it there.

[scene], besides welcome:

[module.CODE] and [module.CODE.exercise.CODE] (/gen-player only)

The unit's LMS modules, which /gen-player creates in DEMO when they do not exist (flow-mgr docs/player.md; chapter 3). There may be several, in the file's order. The table's name is the module's code: two letters (OB) or the unit code and two letters (ALFOB). Each module may define its own exercises; their order in the file is the LMS sequence. A module without exercises gets the three standard ones: TU "Tutorial", TE "Revisión Teórica" and PR "Práctica".

[module.OB]
name = "Operación del Brokk 170"

[module.OB.exercise.TU]
summary = "Aprende a moverte por la escena y a usar el control remoto."

[module.OB.exercise.DM]
name = "Demolición de muro"
simulation = true
task_stations = ["Pared", "Control remoto"]

Without [module.*] tables, the unit has one module, named by a model from the material. Its code is the unit's plus the initials of the first two meaningful words (ALF + "Operación del Brokk" = ALFOB). What the file does not give (names, summaries) is written once and kept, because the LMS compares those texts on every publish. A name or summary changed in the file after DEMO already holds it gives lms_demo_conflict; nothing that exists is ever edited. The module's icon is rendered from the unit's Blender file, with its Icon_Camera when the scene has one (see the scene spec).

[tablet] (/gen-player only)

What each of the tablet's apps holds (chapter 2.5b). Each member is a named table, so a unit can complete or change one the global configuration gives. sequence orders each list; enabled = false hides an inherited one. Documents and videos: source is a con-mgr (DEMO) resource's label, the unit's own or the shared library's (a document must be a PDF; a video an MP4 or WebM). Contacts: name, role, portrait (a PNG or JPEG image's label); guide = true is the exercise's guide; any other needs instructions (who they are and how they answer) and may carry voice (a Gemini voice) or gender. live_avatar names their Gemini Live Avatar; avatar names their voice avatar among flow-mgr's presenters (without it: the unit's own presenter for the guide, the bundled presenter for anyone else). The instructions, voice and Live Avatar stay in flow-mgr: they never reach the page.

[tablet.documents.manual]
source = "manual"
title = "Manual de uso"

[tablet.videos.arranque]
source = "video.brokk-arranque"
title = "Arranque"

[tablet.contacts.jefe]
name = "Carlos Ruiz"
role = "Jefe de planta"
voice = "Charon"
instructions = "Respondes sobre los turnos y la seguridad de la planta."

Global configuration and inheritance. con-mgr also keeps a global player-config (shared library). The unit's is laid over it by GW2's rule: a unit's value wins, tables merge, and an array replaces the other whole. The Mentor's profile lives there:

[tablet.contacts.mentor]
name = "Camila Rojas"
role = "Mentor"
live_avatar = "Kira"
guide = true
sequence = 10

A unit renames her with just [tablet.contacts.mentor] and name = "Laura".

10.5 /gen-player findings