Gráfico de cena em segmento separado


12

Eu desenvolvo meu próprio mecanismo de jogo por diversão (mas não por lucro). Eu tenho renderização em um segmento e meu gráfico de cena é atualizado (velocidade, etc.) em outro. Quando é hora de renderizar, o thread de renderização adiciona os nós visíveis a um novo buffer linear e os percorre.

Mais detalhadamente, meu gráfico de cena é com buffer triplo. Cada nó no meu gráfico de cena possui três cópias de suas matrizes de transformação relativa e absoluta (4x4). A qualquer momento, uma cópia é gravada pelo encadeamento do gráfico de cena, uma cópia é lida pelo renderizador e existe uma terceira para que o leitor ou escritor possa passar para a próxima sem esperar pela outra. Isso evita gravar em algo enquanto está sendo renderizado e renderizar um gráfico de cena semi-atualizado. De alguma forma, também tenho uma quarta cópia de cada matriz para o usuário trabalhar, de modo a não entrar em conflito com o thread de atualização. Isso parece ter um bom desempenho, evitando ter que sincronizar o tempo todo.

No entanto, isso é uma bagunça.

Estes são meus principais objetivos para o sistema:

  • A renderização e a atualização do gráfico de cena ficam em segmentos separados.
  • Minimize o quanto esses encadeamentos devem esperar um pelo outro.
  • Não renderize uma cena que tenha sido parcialmente atualizada pelo thread de atualização. Isso é particularmente perceptível se a câmera estiver se movendo rapidamente e, às vezes, é renderizada antes ou depois de uma atualização.
  • Uso de memória reduzido. Eu tenho muitas matrizes por nó. Também estou pensando em mudar para vetores para posição / rotação / escala devido ao aumento da deriva de ponto flutuante com matrizes.
  • Capacidade de lidar com dezenas de milhares de nós. O sistema atual faz isso razoavelmente bem.

Também espero incorporar o Bullet (o mecanismo de física) e as redes no futuro, nenhum dos quais pensei muito.

Quais são algumas abordagens para obter um melhor gráfico de cena?

Respostas:


4

Você leu a tese de Johannes Spohr sobre "Pace" e seu renderizador? Ele descreve o chamado "mecanismo de envio" * renderizador paralelo e pode fornecer algumas idéias.

Aqui é a página de resumo (em alemão), e aqui é um link direto para o PDF que está em Inglês.

( *: este link também vai para o artigo em que ouvi falar sobre a tese.)

EDIT: Eu só tinha lido isso anteriormente, e só olhei para ele novamente ... e percebi que realmente brilha sobre os detalhes do gráfico da cena. Acho que não percebi o quão ortogonal era o design dele. Desculpe se não é particularmente útil.


1
Um pedaço deste artigo ainda se destacou para mim: "Idealmente, o aplicativo nem saberia que existe um gráfico de cena; ele deve estar ciente de apenas um componente de visualização que precisa informar sobre alterações no modelo de dados". Isso inspirou em mim uma nova maneira de pensar sobre isso: não preciso triplicar a cena inteira, apenas o que é visível através da câmera atual. Posso mover a seleção do segmento de renderização para o segmento de gráfico de cena (quando encontra uma câmera) e, a qualquer momento, um desses três buffers pode ser gravado por ele e outro lido pelo renderizador.
EricP 23/09

1
Você também pode conferir o artigo "Design do mecanismo centrado na câmera para renderização multithread" no Game Engine Gems 1 e o relacionado "Renderização paralela prática com DirectX 9 e DirectX 10" - microsoft.com/downloads/en/…
Neverender

1
Parece que o Game Engine Gems 1 está disponível gratuitamente on-line: books.google.com/…
EricP
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.