Sono stato alle prese con una decisione riguardo all'implementazione o meno di un grafico di scena nel mio gioco. Ho alcuni casi d'uso che richiedono tale strumento, ma non sono stato in grado di ottenere alcuni dettagli di implementazione.
Alcuni retroscena: sto scrivendo un gioco di tipo sparatutto spaziale indirizzato alla piattaforma mobile (Android, principalmente) e il mio codice è quasi interamente in C ++. Non sto usando alcun middleware; i motori di rendering e fisica in particolare sono le mie creazioni. Il mio motore fisico aggiorna le posizioni degli oggetti in base a forze e impulsi. Non ho ancora un sistema di animazione, ma potrei visitarlo ad un certo punto (che potrebbe non avere nulla a che fare con questa discussione).
Innanzitutto, descriverò un buon caso d'uso. Vorrei avere un capo composto da più parti discrete, ognuna delle quali può essere danneggiata / distrutta in modo indipendente. Ad esempio, potrei avere un boss che ha un braccio che può subire danni indipendentemente dal resto dell'entità boss. Quando il braccio viene distrutto, un effetto particella di fuoco situato sulla spalla dei boss potrebbe indicare che il braccio è ora distrutto.
Così com'è, ho deciso di provare a risolvere tali problemi con vincoli nel mio motore fisico per tenere insieme tali oggetti composti. Uno di questi vincoli fornisce 0 gradi di libertà ed è essenzialmente una matrice di trasformazione. Questo è davvero un tentativo di eludere un problema che alla fine mi ha escluso dai grafici delle scene, descritti di seguito.
Il motivo principale per cui mi sono allontanato dall'uso di un grafico di scena è perché non sono riuscito a trovare un modo efficiente per mantenere gli oggetti nidificati (oggetti che ereditano una trasformazione dai loro genitori) sia nel mondo della fisica che nella scena del rendering. Il mondo della fisica ha bisogno che gli oggetti si trovino nello spazio mondiale (o almeno nello stesso spazio) mentre la scena di rendering ha bisogno di oggetti nello spazio genitore. Tracciare le posizioni in entrambi gli spazi potrebbe aiutare (ed essere inevitabile), ma solleva le sue preoccupazioni, non da ultimo in relazione alle prestazioni.
Tuttavia, dati i casi d'uso come quello sopra descritto, penso che riuscire a "lavorare" nello spazio genitore diventerà molto importante, e provare a forzare il mio motore fisico a mantenere queste relazioni attraverso l'uso di vincoli diventerà problematico.
Dato il caso d'uso e la situazione sopra descritti, dovrei usare una struttura grafica per passare le trasformazioni da un oggetto a un altro? In tal caso, come dovrebbe il mio motore fisico calcolare nuove posizioni ed eseguire test di intersezione per oggetti in spazi diversi?