TrainBeyond — Propuesta Interactiva / Interactive Proposal

---

ESPAÑOL

1. Qué es

La propuesta interactiva es la propuesta comercial de TrainBeyond convertida en una experiencia: una página web privada por cliente donde una presentadora virtual con voz recorre la propuesta sección por sección, responde preguntas en vivo, y donde el cliente entra a una escena 3D de su propia planta u operación para ver, de pie y a escala real, lo que el entrenamiento le va a dar. La misma página funciona en computadora, teléfono, visor de realidad virtual (Meta Quest) y, con passthrough, en realidad aumentada dentro de la sala del cliente.

Todo sale de tres cosas:

El resultado es una URL estable por unidad (código de 3 letras, p. ej. FCA) protegida por un código de acceso que se le da al cliente. Republicar sobrescribe esa misma URL.

2. Qué ve y hace el cliente

2.1 Entrar

El cliente abre el enlace y escribe su código de acceso (dura 60 días; el navegador lo recuerda 7 días). Dentro, la galería muestra los paneles de la propuesta en un anillo alrededor de una maqueta de la escena, y la presentadora empieza a hablar.

2.2 La presentación y la guía de voz

• La presentadora recorre las secciones; el cliente puede pausar y hacer preguntas en voz alta (botón de micrófono). Responde con lo que sabe de la propuesta y de los materiales de la unidad.
• Dentro de la escena, la misma voz cambia de papel: deja de vender y se vuelve instructora: explica cada estación al llegar, señala objetos, invita a probar las interacciones.
• ?browse al final de la dirección abre la propuesta sin presentación, con la guía disponible para preguntas.

2.3 Dentro de la escena

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.4 Direcciones especiales

2.5 Realidad aumentada

En un visor con passthrough, Ver en tu sala (RA) coloca la maqueta sobre una mesa real. Con un personaje entregado (--character), el botón Practicar en tu sala (RA) pone a esa persona a tamaño real en la sala del cliente, con una pantalla delante, para practicar una conversación.

3. Cómo se produce una propuesta

3.1 Fuentes en Google Drive

Cada unidad tiene su carpeta bajo la raíz de ventas (Sales Drive). Lo que hay ahí alimenta el texto, la guía y la escena:

3.2 Los comandos

Se escriben en Google Chat, en el espacio de Flow Manager. CODIGO es el código de la unidad: 3 caracteres alfanuméricos.

Paso 1 — generar el borrador

/gen-proposal FCA --es
/gen-proposal FCA --es --high

Genera con IA un borrador y lo guarda como Google Doc "FCA Proposal" en la carpeta de ventas de la unidad. --es fija el idioma de la propuesta (el predeterminado es inglés); --high pide un borrador más completo. Volver a correr este paso regenera el Doc y borra las ediciones.

Paso 2 — editar el Doc

Lo que quede en el Doc es lo que se publica. Dentro de una sección se pueden poner líneas especiales:

<<panel-image: https://drive.google.com/file/d/1AbC.../view | Vista de la línea de corte>>
<<examples: https://drive.google.com/file/d/1Vid1.../view | https://drive.google.com/file/d/1Vid2.../view>>
<<examples-exclude: https://drive.google.com/file/d/1Vid3.../view>>
<<examples: none>>

• <<panel-image: URL | Leyenda>>: una imagen de diseño en ese panel (archivo de Drive visible por enlace; una por sección).
• <<examples: …>>: deja solo esos videos de ejemplo, en ese orden; examples-exclude oculta los listados; examples: none quita la galería.
• Un salto de página real (Ctrl+Enter) controla la paginación impresa.

Paso 3 — publicar

/gen-proposal FCA --es --publish
/gen-proposal FCA --es --publish --interactive

Publica el Doc tal cual (sin IA). --interactive publica además la experiencia 3D con la presentadora en vivo. Repite --es para que la narración y la guía hablen en el idioma correcto. La respuesta en el chat trae la URL y el código de acceso para el cliente.

La escena 3D

/audit-showcase https://drive.google.com/file/d/1AbC.../view --project FCA --es
/gen-proposal FCA --es --showcase https://drive.google.com/file/d/1AbC.../view
/gen-proposal FCA --es --publish --interactive --showcase https://drive.google.com/file/d/1AbC.../view

1. Auditar primero (/audit-showcase): abre el archivo entregado, lo revisa y reporta en el chat. Es de solo lectura: no convierte ni publica nada. Pasa el mismo --project que la unidad.
2. --showcase con el enlace al .blend, .fbx o .glb (o a una carpeta con uno): convierte el archivo, lo aloja y lo pone como maqueta y vista interior. Sin --publish republica la propuesta existente con la escena nueva; con --publish --interactive publica todo junto.
3. Volver a entregar el mismo archivo sin cambios no reconvierte nada.

Avatar presentador

/gen-proposal FCA --es --avatar https://drive.google.com/drive/folders/1Fem.../

Carpeta de Drive con el export FBX de Character Creator 4. El nombre de la carpeta debe contener female o male: eso elige la voz. Sin --publish republica la propuesta existente con el avatar nuevo.

Personaje para practicar una conversación

/gen-proposal FCA --es --publish --interactive \
  --character https://drive.google.com/file/d/1Alej.../view \
  --persona https://docs.google.com/document/d/1Pers.../edit \
  --idle https://drive.google.com/file/d/1Idle.../view \
  --talk https://drive.google.com/file/d/1Talk.../view

• --character: export de Character Creator 4 (.fbx, T-pose, sin animación; huesos CC_Base_*; un personaje de Mixamo se rechaza).
• --persona: Google Doc con líneas Nombre:, Persona:, Líneas:, Voz: (o Género:). Persona: y Líneas: abren secciones de varias líneas; Líneas: son los datos y frases que la persona dice palabra por palabra.
• --idle / --talk: clips .fbx de solo movimiento sobre el esqueleto de Character Creator (de Character Creator, iClone o ActorCore); un clip de Mixamo se reorienta al publicar. Son opcionales: sin ellos se usan los últimos clips importados.
• Con escena, el objeto Character_Alejandra marca dónde está; sin escena, la persona aparece en la sala del cliente (RA).

Ejemplo de Doc de persona:

Nombre: Alejandra
Género: Femenino
Persona: Recepcionista del hotel, 8 años en el puesto, amable pero firme con el protocolo.
Líneas:
Buenos días, bienvenido al Hotel Foliatti, ¿tiene reservación?
El check-in es a partir de las 15:00.

Otros

/gen-proposal --help
/audit-showcase --help
/flow status --project FCA

3.3 Qué devuelve una publicación

En el chat: fuentes usadas, trabajos de imagen, la URL de la propuesta interactiva y el código de acceso. Cada unidad tiene una sola URL; republicar la reemplaza en el momento, sin interrumpir a quien la tenga abierta.

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.

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 la carpeta forms de las fuentes de la unidad en Drive (p. ej. corte.html).
3. En Blender, el plano Clipboard_Inspeccion lleva la propiedad form = corte.html. 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_)

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.

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.

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.
• Clips del avatar (en NLA como todo lo demás):
• Idle (obligatorio) — parado, en bucle.
• Walk (obligatorio) — 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.
• 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. 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.

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; si describes cada pantalla en el documento de temas del recorrido (bajo el nombre de la pantalla), 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.

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, y pon su nombre en la propiedad personalizada form del objeto (corte.html). 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 no interviene en los formularios (por ahora). /audit-showcase reporta un Clipboard_ sin form ni fields, o que no es una malla.

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.

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) o hold (avanza mientras se mantiene pulsado y regresa al soltarlo).
• 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.
• 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.
• /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. Las demás luces (point/spot, un segundo sol) viajan en el archivo pero el visor no las enciende — aproxima su aporte con el cielo. Usa pocas (≤ 4 recomendado).

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

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
• Si incluyes Avatar: Idle y Walk en NLA (Walk en el sitio, sin desplazamiento de raíz); mallas de cabeza con prefijo Head_; Avatar_Eyes en el hueso de la cabeza (recomendado)
• 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)
• 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; luces ≤ 4
• Recorriste cada punto de vista en Blender (Numpad 0 con una cámara en el empty) — se ve compuesto, no accidental

---

9. Para desarrolladores

Documentación de referencia en los repositorios: wrk-mgr/docs/proposal-scene-spec.md (esta especificación), wrk-mgr/docs/workers/interactive-proposal.md (el shell y su contrato en tiempo de ejecución), flow-mgr/docs/proposals.md y flow-mgr/docs/live-relay.md (publicación, auditoría, voz, formularios). Los cambios al shell se despliegan como worker Modal interactive_web y se publican a cada unidad al republicarla.

---

ENGLISH

1. What it is

The interactive proposal is TrainBeyond's sales proposal turned into an experience: a private web page per client where a voiced virtual presenter walks through the proposal section by section and answers questions live, and where the client steps into a 3D scene of their own plant or operation to see, standing at real scale, what the training will give them. The same page works on a computer, a phone, a VR headset (Meta Quest) and, with passthrough, in augmented reality inside the client's own room.

Everything comes from three things:

The result is one stable URL per unit (a 3-letter code such as FCA) protected by an access code given to the client. Republishing overwrites that same URL.

2. What the client sees and does

2.1 Getting in

The client opens the link and types the access code (valid 60 days; the browser remembers it for 7). Inside, the gallery shows the proposal's panels in a ring around a diorama of the scene, and the presenter starts talking.

2.2 The presentation and the voice guide

• The presenter walks the sections; the client can pause and ask questions aloud (microphone button). She answers from the proposal and the unit's materials.
• Inside the scene the same voice changes role: she stops selling and becomes an instructor: explains each station on arrival, points out objects, invites the client to try the interactions.
• ?browse at the end of the address opens the proposal without the presentation, with the guide available for questions.

2.3 Inside the scene

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.4 Special addresses

2.5 Augmented reality

On a headset with passthrough, View in your room (AR) places the diorama on a real table. With a delivered character (--character), Practise in your room (AR) puts that person life-size in the client's room, with a screen in front, to practise a conversation.

3. How a proposal is produced

3.1 Sources in Google Drive

Each unit has its folder under the sales root (Sales Drive). What is in there feeds the text, the guide and the scene:

3.2 The commands

Typed in Google Chat, in the Flow Manager space. CODE is the unit code: 3 alphanumeric characters.

Step 1 — generate the draft

/gen-proposal FCA
/gen-proposal FCA --es --high

Generates a draft with AI and saves it as the Google Doc "FCA Proposal" in the unit's sales folder. --es fixes the proposal language as Spanish (default is English); --high asks for a more thorough draft. Running this step again regenerates the Doc and discards the edits.

Step 2 — edit the Doc

Whatever stays in the Doc is what ships. Inside a section you can add special lines:

<<panel-image: https://drive.google.com/file/d/1AbC.../view | Cutting line overview>>
<<examples: https://drive.google.com/file/d/1Vid1.../view | https://drive.google.com/file/d/1Vid2.../view>>
<<examples-exclude: https://drive.google.com/file/d/1Vid3.../view>>
<<examples: none>>

• <<panel-image: URL | Caption>>: a design image on that panel (a link-viewable Drive file; one per section).
• <<examples: …>>: keeps only those example videos, in that order; examples-exclude hides the listed ones; examples: none removes the gallery.
• A real page break (Ctrl+Enter) controls printed pagination.

Step 3 — publish

/gen-proposal FCA --publish
/gen-proposal FCA --es --publish --interactive

Publishes the Doc verbatim (no AI). --interactive also publishes the 3D experience with the live presenter. Repeat --es so the narration and the guide speak the right language. The chat reply carries the URL and the access code for the client.

The 3D scene

/audit-showcase https://drive.google.com/file/d/1AbC.../view --project FCA
/gen-proposal FCA --showcase https://drive.google.com/file/d/1AbC.../view
/gen-proposal FCA --es --publish --interactive --showcase https://drive.google.com/file/d/1AbC.../view

1. Audit first (/audit-showcase): opens the delivered file, inspects it and reports in chat. Read-only: nothing is converted or published. Pass the unit as --project.
2. --showcase with the link to the .blend, .fbx or .glb (or a folder holding one): converts the file, hosts it and makes it the diorama and the inside view. Without --publish it republishes the existing proposal with the new scene; with --publish --interactive it publishes everything together.
3. Delivering the same unchanged file again converts nothing.

Presenter avatar

/gen-proposal FCA --avatar https://drive.google.com/drive/folders/1Fem.../

A Drive folder with the Character Creator 4 FBX export. The folder name must contain female or male: that picks the voice. Without --publish it republishes the existing proposal with the new avatar.

A character to practise a conversation with

/gen-proposal FCA --publish --interactive \
  --character https://drive.google.com/file/d/1Alej.../view \
  --persona https://docs.google.com/document/d/1Pers.../edit \
  --idle https://drive.google.com/file/d/1Idle.../view \
  --talk https://drive.google.com/file/d/1Talk.../view

• --character: a Character Creator 4 export (.fbx, T-pose, no animation; CC_Base_* bones; a Mixamo character is refused).
• --persona: a Google Doc with Name:, Persona:, Lines:, Voice: (or Gender:) lines. Persona: and Lines: open multi-line sections; Lines: are the facts and sentences the person says word for word.
• --idle / --talk: motion-only .fbx clips on the Character Creator skeleton (from Character Creator, iClone or ActorCore); a Mixamo clip is retargeted at publish. Optional: without them the last imported clips are used.
• With a scene, the Character_Alejandra object marks where they stand; without one the person appears in the client's room (AR).

Example persona Doc:

Name: Alejandra
Gender: Female
Persona: Hotel receptionist, 8 years in the job, friendly but firm on protocol.
Lines:
Good morning, welcome to Hotel Foliatti, do you have a reservation?
Check-in starts at 3 pm.

Other

/gen-proposal --help
/audit-showcase --help
/flow status --project FCA

3.3 What a publish returns

In chat: the sources used, image jobs, the interactive proposal URL and the access code. Each unit has one URL; republishing replaces it in place, without interrupting anyone who has it open.

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.

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 in the forms folder of the unit's Drive sources (e.g. corte.html).
3. In Blender, the Clipboard_Inspection plane carries the property form = corte.html. 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_)

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.

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.

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.
• Avatar clips (staged on NLA like everything else):
• Idle (required) — standing loop.
• Walk (required) — 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.
• 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. 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.

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.

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, and put its name in the object's form custom property (corte.html). 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 takes no part in forms (for now). /audit-showcase reports a Clipboard_ with neither form nor fields, or one that is not a mesh.

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.

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) or hold (runs forward while held and back when released).
• 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.
• 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.
• /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. Other lights (point/spot, a second sun) travel in the file but the viewer does not switch them on — their contribution is approximated by the sky. Use a handful at most (≤ 4 recommended).

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.

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
• If you include an Avatar: Idle and Walk on NLA (Walk in place, no root motion); head meshes prefixed Head_; Avatar_Eyes on the head bone (recommended)
• 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)
• 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; lights ≤ 4
• Walked every station/seat viewpoint in Blender (Numpad 0 on a camera at the empty) — it looks composed, not accidental

9. For developers

Reference documentation in the repositories: wrk-mgr/docs/proposal-scene-spec.md (this specification), wrk-mgr/docs/workers/interactive-proposal.md (the shell and its runtime contract), flow-mgr/docs/proposals.md and flow-mgr/docs/live-relay.md (publishing, audit, voice, forms). Shell changes deploy as the interactive_web Modal worker and reach each unit when it is republished.