¿Qué debe contener un gráfico de escena del juego?

¿Me ayudarías a aclarar, por favor, qué es exactamente lo que debe contener un gráfico de escena de juego? Vea la siguiente lista, por favor:

• Actores del juego? (obviamente, sí, todos los objetos que cambian de estado deberían ser la parte principal del gráfico de escena)
• Ojbects juego estático simple? (Quiero decir, expulsa lugares en el fondo que no se animan, ni chocan)
• ¿Disparadores de juego ?
• Juego de luces?
• Cámaras de juego ?
• Balas de armas ?
• Explosiones de juegos y efectos especiales?

Los tipos de objeto considerados anteriormente. Ahora a la cobertura del gráfico de escena:

• ¿Debería un gráfico de escena contener todo el mapa del nivel del juego desde el inicio del nivel, o debería contener solo la parte visible del mapa? Si lo segundo es cierto, significaría que el gráfico de la escena se actualizaría continuamente, agregando / eliminando objetos del juego, a medida que el jugador se mueve. Sin embargo, contener solo las áreas visibles del mapa obviamente sería mucho más rápido de recorrer y actualizar.

Creo que leer un poco sobre lo que están haciendo otras tecnologías de gráficos de escenas le brindaría muchos beneficios.

Antecedentes
Por ejemplo, mire la descripción de Ogre3D. Es un motor gráfico basado en gráficos de escena que es de código abierto. Sugeriría mirar los tutoriales y ver cómo se usan los nodos de escena (Nota: no le estoy diciendo que aprenda a usar Ogre, sino qué características están presentes en los nodos de escena y los administradores de escena de Ogre)

Documentación de SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

Documentación de SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Algo más que vale la pena mirar es el siguiente enlace:
http://sgl.sourceforge.net/#features

Es una solución de gráfico de escena basada en OpenGL y la página de características allí muestra todos los nodos que puede contener.

Tus nodos sugeridos
Soy de la opinión de que un gráfico de escena debe estar lo más abstraído posible de la lógica del juego para que no tengas ningún problema de dependencia. Para cada una de sus viñetas, diría lo siguiente:

Actores del juego
Probablemente diría que no. Similar a Ogre, tendría una clase de entidad base (que contendría la lógica específica del objeto) y un SceneNode base con un puntero de miembro de entidad para obtener la información adecuada para representar el objeto (posición, orientación, etc.)

EDITAR: no estoy diciendo que no incluyas a tus actores del juego en el gráfico de la escena aquí (de lo contrario, nada aparecerá: P) Estoy diciendo que tengas un nodo de escena con una referencia a la clase de actor lógico del juego, así que has Todavía se soltó el acoplamiento de la representación y actualización de los objetos del juego.

Juego estático simple ojbects
Sí

¿Disparadores de juego?
No, esto me parece una lógica específica del juego.

Juego de luces?
si

Cámaras de juego?
si

Balas de armas?
No estoy completamente seguro de esto, pero probablemente diría que sí, pero probablemente querría todas las viñetas como hijos en un nodo de escena padre "BulletCollection", solo para que pueda almacenar esa posición en caché y no tenga que atravesar el gráfico de escena mucho para eliminar y agregar viñetas para renderizar.

Explosiones de juegos y efectos especiales?
No estoy seguro, dejaré que alguien más responda eso.

Cobertura del gráfico de escena
Si tiene un nivel relativamente pequeño, debería poder almacenar todo el nivel en un gráfico de escena y luego optimizar la visibilidad utilizando un Octree (generalmente para ambientes exteriores) o un árbol BSP (generalmente para ambientes interiores).

Si tiene un nivel mucho más grande y no desea cargar ningún nivel, aquí es donde entraría en juego la transmisión, pero ese es otro problema por completo. Comenzaría con un nivel pequeño y vería gradualmente cuán grande puede hacerlo sin afectar negativamente el rendimiento.

Conclusión
Para mí, un gráfico de escena es para la porción Render de un bucle de juego. No debe acoplar su renderizado y sus actualizaciones lógicas demasiado juntas, de lo contrario, se encontrará con problemas de dependencia molestos.

Mi inclinación es sugerir poner menos cosas en un gráfico de escena. Vea en particular este artículo de Tom Forsyth: " Gráficos de escenas: solo diga que no ".

El quid del artículo de Forsyth es que no deberías tratar de agrupar un montón de cosas no relacionadas en una gran estructura de datos maestros. Esto es muy similar a las ideas que mencioné en esta respuesta con respecto a derivar todo en el juego GameObjecty luego ponerlo todo en una gran lista heterogénea (es decir, eso es malo).

Relativamente pocos objetos en el mundo realmente exhiben una fuerte relación padre-hijo como corresponde a la estructura de un árbol. El ejemplo canónico de una taza de café en una mesa generalmente se usa aquí; claro, se podría considerar que es un "niño" de la mesa ... al menos hasta que se caiga. Entonces, ¿realmente sigue siendo un hijo de la mesa? Esto significa que su 'árbol' puede terminar siendo bastante superficial y degenerar en una lista de todos modos.

Por lo tanto, sugeriría que use múltiples estructuras de datos para varias cosas, ya que tiene más sentido para esas cosas. La geometría estática y las luces, por ejemplo, parecen algo razonable para introducir en un gráfico de escena. Incluso si los objetos representados no tienen relaciones padre-hijo naturales, el hecho de que sean estáticos significa que puede darles relaciones estructurales padre-hijo sabiendo que nunca cambian.

Actores del juego ... No estoy tan seguro. Cualquier cosa que tiende a moverse, de hecho, significa que generalmente necesita mantenerlos cerca de la raíz del gráfico o volver a criarlos constantemente (lo cual es una tarea y no es súper eficiente).

Viñetas, disparadores, efectos especiales y otros objetos transitorios que almacenaría en otro lugar. Nada que represente o tenga una representación visual (un desencadenante suele ser un volumen delimitador invisible, una viñeta suele ser solo una proyección de rayos) debe estar en un gráfico de representación. Debe luchar por la separación de las capas de renderizado y lógica .

Por lo que vale, nunca he usado un gráfico de escena con forma de árbol en ninguno de los renderizadores que he construido para uso no académico (obviamente, he construido gráficos de escena con forma de árbol antes, y así es como llegué a las conclusiones que obtuve. ahora estoy intentando que estés de acuerdo).

Utilizo métodos de partición espacial que son apropiados para el estilo del juego (quad-tree, octree, BSP, etc.) para agrupar / eliminar las entidades lógicas en el juego que deberían (a) procesarse este marco y (b) representarse este cuadro. Luego termino alimentando el conjunto de objetos de la lista (b) en un sistema que mapea objetos lógicos para representar descripciones y clasifica esas descripciones en cubos basados ​​en propiedades (por ejemplo, cualquier cosa que use transparencia será empujada al cubo para "cosas" debería mostrarse de atrás hacia adelante). Luego renderizo cada cubo en orden, y para cada cubo renderizo cada descripción en orden. Supongo que se podría llamar a esto un "árbol", pero no muestra el estado típico / transforma los métodos de propagación que hacen los gráficos de escenas tradicionales orientados a árboles.