rquitetura @OO para renderização em jogos baseados em shader

Eu continuo enfrentando esse problema ao criar mecanismos de jogos em que minhas classes querem ter a seguinte aparência:

interface Entity {
  draw();
}

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

Isso é apenas pseudo-código para mostrar aproximadamente como o desenho acontece. Cada subclasse de entidade implementa seu próprio desenho. O mundo percorre todas as entidades em nenhuma ordem específica e pede que elas se desenhem uma a um

Mas com gráficos baseados em shader, isso tende a ser terrivelmente ineficiente ou até inviável. Cada tipo de entidade provavelmente terá seu próprio programa de sombreador. Para minimizar as alterações do programa, todas as entidades de cada tipo específico precisam ser desenhadasjunto. Tipos simples de entidades, como partículas, também podem agregar seus desenhos de outras maneiras, como compartilhar uma grande matriz de vértices. E fica muito complicado com a mistura, e é assim que alguns tipos de entidade precisam ser renderizados em determinados momentos em relação a outros, ou mesmo várias vezes para diferentes passe

O que eu normalmente termino é algum tipo de renderizador singleton para cada classe de entidade que mantém uma lista de todas as instâncias e as desenha todas de uma vez. Isso não é tão ruim, pois separa o desenho da lógica do jogo. Mas o renderizador precisa descobrir qual subconjunto de entidades desenhar e precisa acessar várias partes diferentes do pipeline de gráficos. É aqui que o meu modelo de objeto tende a ficar confuso, com muito código duplicado, acoplamento rígido e outras coisas ruin

Então, minha pergunta é: o que é uma boa arquitetura para esse tipo de desenho de jogo eficiente, versátil e modula

questionAnswers(2)

yourAnswerToTheQuestion