A decisão sobre que tipo de gerenciamento de cena usar depende muito do tipo de lógica que você está tentando executar. Considere os diferentes consumidores da sua cena:
Consumidor de renderização
O renderizador provavelmente só quer saber o que está atualmente visível para o usuário em um determinado momento. Ele quer uma hierarquia delimitadora de volume para seleção rápida ( artigo da BVH),
para que possa descobrir que uma cadeira dentro de um barco não precisa ser puxada porque os limites do barco estão fora do ponto de vista da vista. Isso pode ser incorporado em uma octree .
Ele também pode querer ter uma idéia de que a cadeira está de costas para dentro do barco e que o barco está rolando para cima e para baixo em algumas ondas quando finalmente aparece. Dessa forma, para encontrar as coordenadas finais do mundo dos vértices da cadeira, ele pode concatenar as transformações da cadeira e do barco e terminar com isso (isso também facilita o seu trabalho como programador).
Ainda outra maneira de encarar esse problema é que o renderizador provavelmente está executando um bom cartão e, no final das contas, quer apenas uma pilha de triângulos classificados para minimizar a textura, o sombreamento, o material, a iluminação e transformar as mudanças de estado. Este último provavelmente o ajudará mais do que um BVH, em termos de desempenho.
Consumidor de lógica de jogo
A lógica do jogo provavelmente só quer uma lista simples de coisas que possam se comunicar por meio de um sistema de mensagens; portanto, um vetor std :: provavelmente é bom.
O jogo também pode querer uma maneira de rastrear quem está mais próximo do quê, então algum tipo de informação do [vizinho mais próximo] [3] pode ser útil nesse caso. Isso também pode ser fornecido por uma BVH, mas ter que subir e descer o gráfico pode ser irritante.
O jogo pode até querer saber que, quando se move A, o item B de A também deve se mover ... nesse caso, voltamos a uma espécie de hierarquia de transformação.
Consumidor de Física
A física do seu jogo pode querer ter uma [representação especial] [4] de espaços internos para uma detecção de colisão muito rápida. Como alternativa, ele pode usar algum tipo de octree ou [hash espacial] [5] para encontrar com eficiência coisas que podem colidir.
Nenhuma estrutura de dados físicos acima realmente se parece com um "gráfico de cena" no sentido Java3D.
Consumidor de áudio
Um mecanismo de áudio deseja apenas geometria, talvez um conjunto potencialmente visível (audível) ou algum tipo de hierarquia de volume delimitadora para calcular a atenuação e a propagação do som. Novamente, não é realmente um tipo normal de gráfico de cena, embora possa muito bem ser um gráfico de geometria em sua cena.
Em última análise ...
... realmente depende apenas das necessidades exatas da sua aplicação. Sugiro usar uma lista simples para começar e ver onde seus problemas surgem. Você pode até tentar uma lista simples com uma hierarquia de transformação, porque esse talvez seja o tipo de gráfico de cenário útil por outros motivos que não a eficiência.
Boa sorte!