Motores de juego: ¿Qué son los gráficos de escena?

¿ Qué es un gráfico de escenas en el juego ¿contexto de desarrollo del motor?

Bueno, es un código que ordena activamente los objetos de juego en el espacio de juego de una manera que facilita rápidamente encontrar qué objetos están alrededor de un punto en el espacio de juego.

De esa manera, es fácil :

1. encuentre rápidamente qué objetos están en la vista de la cámara (y envíelos solo a las tarjetas gráficas, lo que hace que el renderizado sea muy rápido)
2. encuentra rápidamente objetos cercanos a el jugador (y aplicar controles de colisión solo a aquellos)

Y otras cosas. Se trata de permitir una búsqueda rápida en el espacio. Se llama "particionamiento del espacio". Se trata de dividir y conquistar.

¿Por qué querría implementar uno para ¿mi motor de juego 2D?

Eso depende del tipo de juego, más precisamente de la estructura de tu espacio de juego.

Por ejemplo, un juego como Zelda no podría necesitar tales técnicas si es lo suficientemente rápido como para probar la colisión entre todos los objetos de la pantalla. Sin embargo, puede ser muy, muy lento, por lo que la mayoría de las veces al menos configura un gráfico de escenas (o partición de espacio de cualquier tipo) para al menos saber qué hay alrededor de todos los objetos en movimiento y probar colisiones solo en esos objetos.

Entonces, eso depende. La mayoría de las veces se requiere por razones de rendimiento. Pero la implementación de su partición de espacio es totalmente relativa a la forma en que su espacio de juego está estructurado.

Hace el uso de un soporte de gráfico de escena como alternativa a una entidad clásica ¿sistema con un gestor de entidades lineal?

No.

Sea cual sea la forma en que administres la vida de los objetos de tus entidades de juego, el space-partition/scene-graph solo está ahí para permitirte buscar rápidamente objetos en el espacio, ni más ni menos. La mayoría de las veces será un objeto que tendrá algunas ranuras de objetos, correspondientes a diferentes partes del espacio de juego y en esas ranuras serán objetos que están en esas partes. Puede ser plano (como un divisor de pantalla 2D en 2 o 4), o puede ser un árbol (como árbol binario o quadtree, o cualquier otro tipo de árbol) o cualquier otra estructura de clasificación que limite el número de operaciones que tiene que ejecutar para obtener información relacionada con el espacio.

Nota una cosa :

En algunos casos, incluso necesita diferentes sistemas de partición de espacio separados para diferentes propósitos. A menudo, un "gráfico de escena" se trata de renderizar, por lo que se optimiza de una manera que depende del punto de view y su propósito es permitir la recopilación rápida de una lista de objetos para renderizar y enviar a la tarjeta gráfica. No es realmente adecuado para realizar búsquedas de objetos alrededor de otro objeto y eso hace que sea difícil de usar para la detección de colisión precisa, como cuando se utiliza un motor físico. Así que para ayudar, es posible que tenga un sistema de partición de espacio diferente solo para fines físicos.

Para dar un ejemplo, quiero hacer un juego" bullet hell", donde hay un montón de bolas que la nave espacial del jugador tiene que esquivar de una manera muy precisa. Para lograr suficiente rendimiento de renderizado y detección de colisiones necesito saber :

1. cuando aparecen viñetas en el espacio de la pantalla
2. cuando las viñetas salen del espacio de la pantalla
3. cuando el jugador entra en colisión con balas
4. cuando el jugador entra en colisión con monstruos

Así que corté recursivamente la pantalla que es 2D en 4 partes, eso me da un quadtree. El quadtree se actualiza cada tick juego, porque todo se mueve constantemente, así que tengo que hacer un seguimiento de la posición de cada objeto (nave espacial, bala, monstruo) en el quadtree para saber cuál es en qué parte de la pantalla.

Lograr 1. es fácil, solo tienes que introducir la bala en el sistema.

Para lograr 2. Mantuve una lista de hojas en el quadtree (secciones cuadradas de la pantalla) que están en el borde de la pantalla. Esas hojas contienen los identificadores / punteros de las balas que están cerca de la frontera, así que solo tengo que comprobar que son moviéndome para saber si puedo dejar de representarlos y manejar la colisión también. (Puede ser un poco más complejo, pero se entiende la idea.)

Para lograr 3 y 4. Necesito recuperar los objetos que están cerca de la nave espacial del jugador. Así que primero obtengo la hoja donde está la nave espacial del jugador y obtengo todos los objetos en ella. De esa manera solo probaré la colisión con la nave espacial del jugador en los objetos que están a su alrededor, no todos los objetos. (ES un poco más complejo, pero se obtiene la idea.)

De esa manera puedo asegurarme de que mi juego funcione sin problemas incluso con miles de balas en constante movimiento.

En otros tipos de estructura de espacio, se requieren otros tipos de partición de espacio. Por lo general, los juegos de kart/auto tendrán un gráfico de escena de "túnel" porque visualmente el jugador verá solo cosas a lo largo de la carretera, por lo que solo tiene que verificar dónde está en la carretera para recuperar todos los objetos visibles alrededor en el "túnel".

Un gráfico de escenas es una forma de organizar todos los objetos en el entorno. Por lo general, se tiene cuidado de organizar los datos para una representación eficiente. El gráfico, o árbol si lo desea, puede mostrar la propiedad de los subobjetos. Por ejemplo, en el nivel más alto puede haber un objeto de la ciudad, debajo de ella sería muchos objetos de construcción, debajo de los que pueden ser paredes, muebles...

En su mayor parte, sin embargo, solo se usan para escenas 3D. Yo sugeriría no ir con algo que complicado para un 2D escena.

Parece que hay bastantes filosofías diferentes en la web en cuanto a cuáles son las responsabilidades de un scenegraph. La gente tiende a poner en un montón de cosas diferentes como la geometría, la cámara, las fuentes de luz, disparadores de juegos, etc.

En general, describiría un scenegraph como una descripción de una escena y se compone de una sola o múltiples estructuras de datos que contienen las entidades presentes en la escena. Estas estructuras de datos pueden ser de cualquier tipo (array, tree, Composite pattern, etc) y puede describir cualquier propiedad de las entidades o cualquier relación entre las entidades en la escena. Estas entidades pueden ser cualquier cosa, desde objetos de diseño sólidos hasta mallas de colisión, cámaras y fuentes de luz. La única restricción real que he visto hasta ahora es que la gente recomienda mantener los componentes específicos del juego (como los disparadores del juego) para evitar problemas de dependencia más adelante. Tales cosas tendrían que ser abstraídas, digamos, "LogicEntity", "InvisibleEntity" o simplemente "Entidad".

Aquí están algunos usos comunes de y dataestructures en un scenegraph.

Relaciones Padre/Hijo

La forma en que se puede usar un scenegraph en un juego o motor es describir las relaciones padre/hijo entre cualquier cosa que tenga una posición, ya sea un objeto sólido, una cámara o cualquier otra cosa. Tal relación significaría que la posición, escala y orientación de cualquier hijo sería relativa a la de su padre. Esto le permitiría hacer que la cámara siga la jugador o para que una fuente de luz siga un objeto linterna. También te permitiría hacer cosas como el sistema solar en el que puedes describir la posición de los planetas en relación con el sol y la posición de las lunas en relación con su planeta si eso es lo que estás haciendo.

También las cosas específicas de algún sistema en su juego/motor se pueden almacenar en el scenegraph. Por ejemplo, como parte de un motor de física, puede haber definido mallas de colisión simples para objetos sólidos que también pueden tener geometría compleja para probar colisiones. Podrías poner estas mallas de colisión (estoy seguro de que tienen otro nombre pero lo olvidé: P) en tu scenegraph y hacer que sigan los objetos que modelan.

Partición de espacio

Otra posible estructura de datos en un scenegraph es alguna forma de partición del espacio como se indica en otras respuestas. Esto le permitiría realizar consultas rápidas en la escena, como recortar cualquier objeto que no esté en el tronco de visualización o filtrar de manera eficiente objetos que necesitan comprobación de colisión. También puede permitir que el código del cliente (en caso de que esté escribiendo un motor) realice consultas personalizadas para cualquier propósito. De esta manera, el código del cliente no tiene que mantener sus propias estructuras de partición de espacio.

Espero haberte dado a ti, y a otros lectores, algunas ideas de cómo puedes usar un scenegraph y lo que podrías poner en él. Estoy seguro de que hay muchas otras formas de usar un scenegraph, pero estas son las cosas que se me ocurrieron.

En la práctica, los objetos de escena en videojuegos rara vez se organizan en un gráfico que se "camina" como un árbol cuando se renderiza la escena. Un sistema de gráficos típicamente espera una gran matriz de cosas para renderizar, y esta gran matriz se camina linealmente.

Los juegos que requieren relaciones de crianza geométricas, como aquellos con personas que sostienen armas o tanques con torretas, definen y refuerzan esas relaciones según sea necesario fuera del sistema gráfico. Estas relaciones tienden a ser solo uno-profundo, por lo que casi nunca hay necesidad de una estructura de árbol arbitrariamente profunda.