c++ - unity - ubiart framework descargar
Motores de juego: ¿Qué son los gráficos de escena? (5)
Empecé a leer el material en Wikipedia, pero todavía siento que realmente no entiendo cómo funciona un gráfico de escena y cómo puede proporcionar beneficios para un juego.
- ¿Qué es un gráfico de escena en el contexto de desarrollo de motor de juego?
- ¿Por qué querría implementar uno para mi motor de juego 2D?
- ¿El uso de un gráfico de escena es una alternativa a un sistema de entidad clásico con un administrador de entidades lineal?
¿Qué es un gráfico de escena en el contexto de desarrollo de motor de juego?
Bueno, es un código que ordena activamente los objetos de tu juego en el espacio del juego de una manera que hace que sea fácil encontrar rápidamente qué objetos están alrededor de un punto en el espacio del juego.
De esta manera, es fácil:
- encuentre rápidamente qué objetos se encuentran en la vista de la cámara (y envíelos solo a las tarjetas gráficas, haciendo que la representación sea muy rápida)
- encuentre rápidamente objetos cerca del jugador (y aplique controles de colisión solo a aquellos)
Y otras cosas. Se trata de permitir una búsqueda rápida en el espacio. Se llama "partición espacial". 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 en 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 para probar la colisión entre todos los objetos en la pantalla. Sin embargo, puede ser realmente muy lento, por lo que la mayoría de las veces configura un gráfico de escena (o partición de espacio de cualquier tipo) para saber al menos qué hay alrededor de todos los objetos en movimiento y colisiones de prueba solo en esos objetos.
Entonces, eso depende. La mayoría de las veces es necesario por motivos de rendimiento. Pero la implementación de su partición de espacio es totalmente relativa a la forma en que está estructurado su espacio de juego.
¿El uso de un gráfico de escena es una alternativa a un sistema de entidad clásico con un administrador de entidades lineal?
No.
De cualquier forma que administres la vida de los objetos de tu entidad de juego, la partición de espacio / gráfico de escena 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 habrá 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 árbol cuádruple, 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 algunas informaciones relacionadas con el espacio.
Tenga en cuenta una cosa:
En algunos casos, incluso necesita diferentes sistemas de particiones espaciales separadas para diferentes propósitos. A menudo, un "gráfico de escena" se trata de la representación, por lo que se optimiza de una manera que depende del punto de vista del jugador y su propósito es permitir la recopilación rápida de una lista de objetos para procesar para enviar a la tarjeta gráfica. No es realmente adecuado para realizar búsquedas de objetos alrededor de otro objeto y eso dificulta su uso para la detección precisa de colisiones, como cuando se utiliza un motor físico. Para ayudar, es posible que tenga un sistema de partición espacial diferente solo para fines físicos.
Para dar un ejemplo, quiero hacer un juego de "infierno de balas", donde hay muchas bolas que la nave espacial del jugador tiene que esquivar de una manera muy precisa. Para lograr el rendimiento suficiente de renderizado y detección de colisiones, necesito saber:
- cuando aparecen viñetas en el espacio de la pantalla
- cuando las balas salen del espacio de la pantalla
- cuando el jugador entra en colisión con balas
- cuando el jugador entra en colisión con monstruos
Así que recursivamente corté la pantalla que es 2D en 4 partes, eso me da un quadtree. El quadtree se actualiza cada vez que un juego marca, 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 árbol para saber cuál está en qué parte de la pantalla.
Lograr 1. es fácil, solo ingrese la viñeta 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 viñetas que están cerca del borde, así que solo tengo que verificar que se están moviendo para saber si puedo dejar de renderizarlas y controlar la colisión también. (Puede ser un poco más complejo, pero entiendes 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 en todos los objetos. (ES UN poco más complejo, pero entiendes la idea).
De esa forma puedo asegurarme de que mi juego funcione sin problemas incluso con miles de balas moviéndose constantemente.
En otros tipos de estructura espacial, se requieren otros tipos de división de espacio. Normalmente, los juegos de kart / auto tendrán un gráfico de escena de "túnel" porque visualmente el jugador solo verá cosas a lo largo del camino, por lo que solo tienes que verificar dónde está en el camino para recuperar todos los objetos visibles en el "túnel" .
En la práctica, los objetos de escena en los videojuegos rara vez se organizan en un gráfico que se "camina" como un árbol cuando se representa la escena. Un sistema de gráficos generalmente espera una gran cantidad de elementos para representar, y esta gran matriz se camina de forma lineal.
Los juegos que requieren relaciones de crianza geométricas, como aquellos con personas que sostienen pistolas o tanques con torretas, definen y hacen cumplir esas relaciones según sea necesario fuera del sistema de gráficos. Estas relaciones tienden a ser de una sola profundidad, por lo que casi nunca existe la necesidad de una estructura de árbol arbitrariamente profunda.
Parece que hay bastantes filosofías diferentes en la web sobre las respuestas de un scenegraph. La gente tiende a poner muchas cosas diferentes como la geometría, las cámaras, las fuentes de luz, los desencadenantes del juego, etc.
En general, describiría un scenegraph como una descripción de una escena y está compuesto de una o varias estructuras de datos que contienen las entidades presentes en la escena. Estas estructuras de datos pueden ser de cualquier tipo (matriz, árbol, patrón compuesto , etc.) y pueden describir cualquier propiedad de las entidades o cualquier relación entre las entidades en la escena. Estas entidades pueden ser cualquier cosa, desde objetos dibujables sólidos hasta mallas de colisión, cámaras y fuentes de luz. La única restricción real que vi hasta ahora es que la gente recomienda mantener componentes específicos del juego (como los desencadenantes del juego) para evitar problemas de dependencia más adelante. Tales cosas tendrían que ser abstraídas para, por ejemplo, "LogicEntity", "InvisibleEntity" o simplemente "Entity".
Aquí hay algunos usos comunes de y estructuras de datos en un scenegraph.
Relaciones padre / hijo
La forma en que 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 niño sería relativa a la de su padre. Esto le permitirá hacer que la cámara siga al jugador o tener una fuente de luz siguiendo un objeto de 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 pueden almacenarse 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 pueden tener una geometría demasiado compleja para probar las 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 space-partitioning del space-partitioning como se indica en otras respuestas. Esto le permitiría realizar consultas rápidas en la escena, como recortar cualquier objeto que no se encuentre en el triturado de visualización o filtrar de manera eficiente los objetos que necesitan verificación de colisión. También puede permitir el código del cliente (en caso de que esté escribiendo un motor) para realizar consultas personalizadas para cualquier propósito. De esta forma, el código del cliente no tiene que mantener sus propias estructuras de división de espacio.
Espero haberles dado a ustedes, y a otros lectores, algunas ideas de cómo pueden usar un scenegraph y lo que podrían poner en él. Estoy seguro de que hay muchas otras formas de usar un scenegraph pero estas son las cosas que se me ocurrieron.
Un gráfico de escena es una forma de organizar todos los objetos en el entorno. Por lo general, se tiene cuidado en organizar los datos para una representación eficiente. El gráfico, o el árbol si lo desea, puede mostrar la propiedad de los sub objetos. Por ejemplo, en el nivel más alto puede haber un objeto de la ciudad, debajo de él hay muchos objetos de construcción, debajo de los cuales pueden haber paredes, muebles ...
Sin embargo, en su mayor parte, estos solo se usan para escenas en 3D. Sugeriría que no vaya con algo complicado para una escena 2D.
¿Qué es un gráfico de escena? Un gráfico de escena contiene toda la geometría de una escena en particular. Son útiles para representar traducciones, rotaciones y escalas (junto con otras transformaciones afines ) de objetos relativos entre sí.
Por ejemplo, considere un tanque (el tipo con pistas y una pistola). Su escena puede tener varios tanques, pero cada uno se orienta y se coloca de manera diferente, cada uno con su torreta rotada a diferentes azimut y con una elevación de arma diferente. En lugar de descubrir exactamente cómo debe colocarse la pistola para cada tanque, puede acumular transformaciones afines a medida que recorre el gráfico de la escena para posicionarlo correctamente. Hace que el cálculo de tales cosas sea mucho más fácil.
Gráficos de escena 2D: el uso de un gráfico de escena para 2D puede ser útil si su contenido es lo suficientemente complejo y si sus objetos tienen una serie de componentes secundarios que no están rígidamente fijados al cuerpo más grande. De lo contrario, como otros han mencionado, es probable que sea excesivo. La complejidad de las transformaciones afines en 2D es bastante menor que en el caso 3D.
Administrador de entidad lineal: no tengo claro exactamente qué quiere decir con un administrador de entidad lineal , pero si se refiere a solo hacer un seguimiento de dónde se ubican las cosas en su escena, los gráficos de escena pueden facilitar las cosas si hay un alto grado de dependencia espacial entre los diversos objetos o sub-objetos en su escena.