arquitectura OO para la prestación de los juegos basados ​​shader

Question

sigo golpeando este problema en la construcción de motores de juego donde mis clases quieren tener este aspecto:

interface Entity { 
    draw(); 
} 

class World { 
    draw() { 
    for (e in entities) 
     e.draw(); 
    } 
} 

eso es sólo pseudo-código que muestran qué ocurre el dibujo. Cada subclase de entidad implementa su propio dibujo. El mundo recorre todas las entidades sin ningún orden en particular y les dice que se dibujen uno por uno.

Pero con gráficos basados ​​en sombreado, esto tiende a ser terriblemente ineficiente o incluso inviable. Cada tipo de entidad probablemente tendrá su propio programa de sombreado. Para minimizar los cambios de programa, todas las entidades de cada tipo particular deben dibujarse juntas . Los tipos simples de entidades, como las partículas, también pueden querer agregar su dibujo de otras maneras, como compartir una gran matriz de vértices. Y se pone realmente peludo con la mezcla y tal, cuando algunos tipos de entidad necesitan renderizarse en ciertos momentos en relación con otros, o incluso en múltiples ocasiones para pases diferentes.

Lo que normalmente termino con algún tipo de renderizador individual para cada clase de entidad que mantiene una lista de todas las instancias y las dibuja todas a la vez. Eso no es tan malo ya que separa el dibujo de la lógica del juego. Pero el procesador necesita averiguar qué subconjunto de entidades dibujar y necesita acceder a múltiples partes diferentes de la canalización de gráficos. Aquí es donde mi modelo de objetos tiende a desordenarse, con muchos códigos duplicados, acoplamiento cerrado y otras cosas malas.

Así que mi pregunta es: ¿cuál es una buena arquitectura para este tipo de juego que es eficiente, versátil y modular?

Answer 1

No es una pregunta fácil de contestar, ya que hay muchas formas de resolver el problema. Una buena idea es investigar algunos motores de Juego/Rendering y ver cómo se maneja esto allí. Un buen punto de partida sería Ogre, ya que está bien documentado y es de código abierto.

Hasta donde yo sé, separa los datos de vértice de los componentes del material (sombreadores) a través de los scripts de material incorporados. El renderizador mismo sabe qué malla se va a dibujar en qué orden y con qué sombreado (y sus pases).

Sé que esta respuesta es un poco vaga, pero espero darte una pista útil.

Answer 2

Utilice un enfoque en dos etapas: Primer bucle a través de todas las entidades, pero en lugar de dibujar, que se inserten referencias en una (la) lista de lotes de dibujo. Luego, clasifique la lista por estado OpenGL y uso del sombreador; después de clasificar insertar objetos del cambiador de estado en cada transición de estado.

Finalmente, recorra la lista ejecutando la rutina de dibujo de cada objeto al que se hace referencia en la lista.