Gráfico de cena ou não gráfico de cena?

Eu tenho lutado com a decisão de implementar ou não um gráfico de cena no meu jogo. Tenho alguns casos de uso que exigem essa ferramenta, mas não consegui passar por alguns detalhes da implementação.

Alguns antecedentes: estou escrevendo um jogo do tipo shooter espacial direcionado à plataforma móvel (Android, principalmente) e meu código é quase inteiramente em C ++. Não estou usando nenhum middleware; os mecanismos de renderização e física em particular são minhas próprias criações. Meu mecanismo de física atualiza a localização de objetos com base em forças e impulsos. Ainda não tenho um sistema de animação, mas posso visitá-lo em algum momento (o que pode ou não ter algo a ver com essa discussão).

Primeiro, descreverei um bom caso de uso. Eu gostaria de ter um chefe que é composto de várias partes distintas, cada uma das quais pode ser danificada / destruída independentemente. Por exemplo, eu posso ter um chefe que tem um braço que pode receber danos independentemente do resto da entidade do chefe. Quando o braço é destruído, um efeito de partícula de fogo localizado no ombro dos chefes pode indicar que o braço está destruído.

Como é, decidi tentar resolver esses problemas com restrições no meu mecanismo de física para manter esses objetos compostos juntos. Uma dessas restrições fornece 0 grau de liberdade e é essencialmente uma matriz de transformação. Esta é realmente uma tentativa de contornar um problema que finalmente me afastou dos gráficos de cena, descritos a seguir.

A principal razão pela qual me afastei do uso de um gráfico de cena é porque não consegui encontrar uma maneira eficiente de manter objetos aninhados (objetos que herdam uma transformação de seus pais) no mundo da física e na cena de renderização. O mundo da física precisa que os objetos estejam no espaço do mundo (ou pelo menos no mesmo espaço), enquanto a cena de renderização precisa de objetos no espaço dos pais. O rastreamento de locais nos dois espaços pode ajudar (e ser inevitável), mas levanta suas próprias preocupações, a menor delas relacionada ao desempenho.

No entanto, dados casos de uso como o descrito acima, acho que poder 'trabalhar' no espaço pai se tornará muito importante, e tentar forçar meu mecanismo de física a manter esses relacionamentos através do uso de restrições se tornará problemático.

Dado o caso de uso e a situação descrita acima, devo usar uma estrutura de gráfico para passar transformações de um objeto para outro? Nesse caso, como meu mecanismo de física deve calcular novos locais e realizar testes de interseção para objetos em diferentes espaços?

Você já tentou um gráfico hierárquico e mediu o desempenho?

Você investigou mecanismos de física simples para ver como eles lidam com o problema, mesmo um mecanismo 2D que tenha ligação entre objetos ajudaria a guiá-lo em uma direção comprovada.

Eu não tentaria executar sua física em vários espaços, a complexidade seria assustadora. Execute a física no espaço mundial e adicione funcionalidade para criar transformações de sua hierarquia para mover objetos do espaço local para o espaço mundial e vice-versa. Suas restrições, por necessidade, devem estar no espaço local em relação ao objeto pai.

Como observação lateral, mesmo uma matriz pura de objetos é um "gráfico de cena", apenas um gráfico muito simples. Não tenha medo de organizar os dados de maneira a resolver problemas e, especialmente, não decida que o desempenho dessa organização de dados é um fator sem sequer ter medido esse desempenho.