El estado de simulación no es el objeto renderizado

1104. Identidad de la lección

Módulo

3.6 — Rendering 3D

Lección

3.6 L1 — El estado de simulación no es el objeto renderizado

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1

Tiempo estimado

30–45 minutos, incluida la práctica guiada

1105. Objetivo de aprendizaje

Al terminar esta lección, puedes clasificar las responsabilidades del estado de simulación, los transform, las vistas, la apariencia de los materiales y los sistemas de actualización dentro de un render path 3D. También puedes expresar esa clasificación mediante un mapa de responsabilidades que indique propietario, entrada, salida y motivo en cada enlace relevante.

1106. Por qué importa

Un objeto 3D en pantalla es una manifestación del estado, no el estado en sí. Cuando se mezclan estas responsabilidades, una corrección visual puede alterar silenciosamente las reglas del juego, o dos sistemas pueden competir por el mismo transform o material. Definir con claridad quién controla cada valor ofrece una base estable para dirigir a la IA y revisar su código. También facilita la localización de fallos visuales: puedes preguntar si el problema está en el estado autoritativo, en el transform, en la vista o el material, o en un sistema que escribe un valor sin ser su propietario.

1107. Conocimientos previos

Debes poder distinguir el estado del juego de su presentación y leer la estructura básica de una escena 3D. El módulo anterior introdujo la disciplina de asignar responsabilidades: un cambio solicitado debe tener un diff acotado y un propietario identificado. Esta lección aplica esa disciplina al recorrido desde los datos de simulación hasta los píxeles renderizados.

1108. Concepto central

El objeto renderizado es una vista del estado de simulación. No es el registro autoritativo de lo que el juego considera verdadero.

Usa la siguiente separación:

• Estado de simulación: Hechos autoritativos que utilizan las reglas del juego, como la posición lógica, la velocidad, la salud o el modo actual de un actor.
• Transform: Representación espacial que coloca un objeto en la escena. Puede derivarse del estado de simulación e incluir interpolación, rotación, escala u offsets de presentación.
• Vista: Objeto de escena y componentes visuales que presentan el estado al jugador, como un mesh, una animación, partículas, luces y elementos similares.
• Responsabilidad del material: Control de la apariencia de una superficie, como el color, la textura, la rugosidad o la respuesta emisiva. Un material puede comunicar un estado sin controlar ese estado.
• Sistema propietario de la actualización: Único sistema declarado como responsable de decidir cuándo y cómo cambia un valor.

La distinción clave es la autoridad. Si una regla de juego pregunta «¿dónde está el actor?», debe consultar la representación de simulación o la representación de colisión definida por la simulación. No debe inspeccionar la posición de un mesh solo porque sea visible. La vista puede llevar retraso, interpolar, vibrar, animarse, cambiar parámetros del material u ocultarse temporalmente sin modificar la verdad subyacente del juego.

1109. Modelo mental

Usa la cadena de la verdad a los píxeles:

estado de simulación
          │ deriva o sincroniza
          ▼
       transform
          │ se presenta mediante
          ▼
       vista + material
          │ los dibuja
          ▼
   renderer / pantalla

En forma lineal: el estado de simulación proporciona una entrada al sistema propietario del transform; el resultado lo consumen la vista y la presentación del material; por último, el renderer dibuja esa presentación en pantalla.

Asigna las responsabilidades por separado:

Puedes entregar un mapa de responsabilidades como tabla o como lista ordenada. Si utilizas una lista, incluye en cada entrada los encabezados clasificación, propietario, entrada, salida y motivo. Los flujos de datos también pueden escribirse de forma lineal, por ejemplo: posición de simulación → sincronizador espacial → transform de escena.

Al depurar, revisa la cadena de izquierda a derecha. No empieces modificando el mesh por ser la parte más visible. Determina primero qué enlace contiene el valor incorrecto y qué sistema tiene permiso para escribirlo.

1110. Ejemplo concreto

Imagina un dron cuyo estado de simulación contiene:

logicalPosition = (4, 0, 8)
velocity = (0, 0, -2)
active = true

Un sistema de presentación copia la posición lógica al transform del dron en cada fotograma de renderizado. También añade un pequeño offset vertical de flotación e interpola entre posiciones recientes para suavizar el movimiento. Un sistema de vista usa active para seleccionar un material emisivo para el indicador del dron. Por tanto, el mesh puede dibujarse en una posición ligeramente distinta de logicalPosition, y el material puede comunicar actividad sin controlar el valor active.

Esas diferencias pueden ser válidas. Una regla de colisión debe usar la posición de simulación o la representación de colisión definida por la simulación, no el offset de flotación del mesh. Si una cinemática oculta el dron, aplica una inclinación visual o cambia su material, esas acciones no deberían reescribir la posición lógica ni el estado activo. En cambio, si el juego mueve el dron pero el sistema propietario del transform no lo sincroniza, la simulación puede ser correcta mientras la vista está desactualizada.

Usa el síntoma para elegir la primera revisión acotada:

• El juego informa una ubicación incorrecta: revisa el estado de simulación y su propietario.
• El estado es correcto, pero el objeto de escena está desplazado: revisa la sincronización del transform y los posibles escritores competidores.
• El transform es correcto, pero el objeto se ve mal: revisa las entradas de la vista, el material y el renderer.
• El objeto cambia dos veces durante un fotograma: revisa la responsabilidad de actualización y los escritores competidores.

1111. Error común

El error habitual consiste en tratar el objeto visible de la escena como si fuera el objeto del juego. Esto lleva a sistemas de reglas no relacionados a leer o escribir directamente el transform o el material de un mesh. También puede convertir en escritor a cualquier sistema que necesite un ajuste visual. El resultado quizá parezca correcto durante un fotograma, pero vuelve imposible seguir la autoridad de los datos.

Un transform o un material no es autoritativo solo porque exponga una propiedad cómoda como position o color. Pregunta qué significa el valor, qué sistema lo controla, si deriva de un valor más autoritativo y si pertenece a las reglas del juego o únicamente presenta su resultado.

1112. Práctica guiada

Una plataforma móvil tiene una posición de simulación, una velocidad y un estado active. Un sincronizador espacial coloca su nodo de escena. Un sistema de presentación cambia el material del indicador cuando la plataforma está activa. Un sistema de cámara sigue la plataforma con suavizado. Durante la depuración, la plataforma aparece un metro por detrás de la ubicación esperada.

Clasifica cada elemento. Para cada uno, indica clasificación, propietario, entrada, salida y motivo.

1. La velocidad de la plataforma determina su siguiente posición lógica.
2. El nodo de escena recibe una posición del sincronizador espacial.
3. El material del indicador cambia de color cuando la plataforma está activa.
4. La cámara usa un objetivo suavizado basado en la posición de la plataforma.
5. Un script de depuración escribe directamente en el nodo de escena en cada fotograma.

Punto de intento

Completa las cinco entradas antes de consultar la respuesta modelo. Tu primer mapa puede ser una tabla o una lista ordenada. Marca como ambiguo cualquier propietario que no puedas determinar e indica qué evidencia resolvería la ambigüedad.

1113. Caso de transferencia

Un marcador de navegación tiene el destino lógico correcto, pero su icono visible salta brevemente al destino anterior después de actualizar la ruta. Un sistema de rutas controla el destino lógico, un sincronizador del marcador escribe el transform del icono y una animación de transición también escribe ese transform durante dos fotogramas.

Crea un mapa de responsabilidades con tres entradas: sistema de rutas, sincronizador del marcador y animación de transición. Identifica al escritor competidor y nombra la primera revisión acotada que realizarías. No uses la respuesta anterior como prueba: debes razonar este caso a partir de sus propios propietarios y flujos de datos. No se incluye una respuesta modelo aquí.

1114. Validación y evaluación

1115. Puntos clave

• El estado de simulación registra lo que el juego considera verdadero; el objeto renderizado presenta esa verdad.
• Un transform es una representación espacial y puede incluir cambios específicos de presentación.
• Los materiales comunican apariencia o estado, pero no controlan automáticamente el estado que muestran.
• Las vistas pueden animar, interpolar, ocultar o decorar un objeto sin cambiar la verdad de simulación.
• Todo valor escribible necesita un propietario declarado y un flujo de datos trazable.
• La primera revisión debe estar acotada por el síntoma y el mapa de responsabilidades.

1116. Siguiente lección

Continúa con 3.6 L2 — Rastrear un fotograma 3D. La siguiente lección aplica este modelo de responsabilidades al seguimiento del trabajo ordenado de un fotograma 3D completo.