Cosa dovrebbe essere contenuto in un grafico della scena di gioco?

Mi aiuterebbe a chiarire, per favore, cosa dovrebbe essere esattamente contenuto in un grafico della scena di gioco? Vedi il seguente elenco, per favore:

• Attori di gioco? (ovviamente sì, tutti gli oggetti che cambiano stato dovrebbero essere la parte principale del grafico della scena)
• Semplici oggetti di gioco statici? (Voglio dire espelle i luoghi sullo sfondo che non si animano, né si scontrano)
• Trigger di gioco ?
• Luci di gioco ?
• Videocamere di gioco ?
• Proiettili di armi ?
• Esplosioni di giochi ed effetti speciali?

I tipi di oggetto considerati sopra. Ora alla copertura del grafico della scena:

• Un grafico di scena dovrebbe contenere l' intera mappa del livello di gioco dall'inizio del livello o dovrebbe contenere solo la parte visibile della mappa? Se il secondo è vero, significherebbe che il grafico della scena verrà continuamente aggiornato, aggiungendo / rimuovendo gli oggetti di gioco, mentre il giocatore si muove. Tuttavia, contenere solo i visibili della mappa sarebbe ovviamente molto più veloce da attraversare e aggiornare.

Penso che una buona lettura di ciò che stanno facendo le altre tecnologie per i grafici delle scene produrrebbe molti vantaggi per te.

Sfondo
Ad esempio, guarda la descrizione di Ogre3D. È un motore grafico basato sul grafico di scena che è open source. Suggerirei di guardare i tutorial e vedere come vengono utilizzati i nodi scena (Nota: non ti sto dicendo di imparare ad usare Ogre, piuttosto quali funzioni sono presenti nei nodi scena e nei gestori scene di Ogre)

Documentazione SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

Documentazione di SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Qualcos'altro che vale la pena guardare è il seguente link:
http://sgl.sourceforge.net/#features

Si tratta di una soluzione per grafici di scene basata su OpenGL e la pagina delle caratteristiche lì mostra tutti i nodi che può contenere.

I tuoi nodi suggeriti
Sono dell'opinione che un grafico di scena debba essere il più astratto possibile dalla logica di gioco in modo da non avere problemi di dipendenza. Per ciascuno dei tuoi punti elenco direi quanto segue:

Attori di gioco
probabilmente direi di no. Simile a Ogre, avrei una classe Entity di base (che conterrebbe la logica specifica dell'oggetto) e un SceneNode di base con un puntatore membro Entity per ottenere le informazioni appropriate per il rendering dell'oggetto (Posizione, Orientamento, ecc.)

EDIT: Non sto dicendo di non includere i tuoi attori di gioco nel grafico della scena qui (altrimenti non verrebbe visualizzato nulla: P) Sto dicendo di avere un nodo scena con un riferimento alla classe degli attori di gioco logici, quindi hai continuava ad allentare il rendering e l'aggiornamento degli oggetti di gioco.

Semplici oggetti di gioco statici
Sì

Trigger di gioco?
No, mi sembra una logica specifica del gioco.

Luci di gioco?
sì

Videocamere di gioco?
sì

Proiettili di armi?
Non sono del tutto sicuro di questo, ma probabilmente direi di sì, ma probabilmente vorrai tutti i proiettili da bambini in un nodo scena padre "BulletCollection", solo così puoi memorizzare nella cache quella posizione e non dovrai attraversare il grafico della scena molto da rimuovere e aggiungere proiettili per il rendering.

Esplosioni di giochi ed effetti speciali?
Non sono sicuro, lascerò che qualcun altro risponda.

Copertura del grafico della scena
Se hai un livello relativamente piccolo, dovresti essere in grado di memorizzare l'intero livello in un grafico della scena e quindi ottimizzare la visibilità usando un Octree (di solito per gli ambienti esterni) o un albero BSP (di solito per gli ambienti interni).

Se hai un livello molto più grande e non vuoi eseguire alcun caricamento di livello, è qui che entrerebbe in gioco lo streaming, ma questo è un altro problema. Comincerei con un piccolo livello e vedrei in modo incrementale quanto puoi farlo senza influire negativamente sulle prestazioni.

Conclusione
Per me un grafico di scena è per la parte Render di un loop di gioco. Non dovresti accoppiare il rendering e gli aggiornamenti logici troppo strettamente insieme, altrimenti ti imbatterai in fastidiosi problemi di dipendenza.

La mia inclinazione è quella di suggerire di inserire meno cose in un grafico di scena. Vedi in particolare questo articolo di Tom Forsyth: " Scene Graphs - Just Say No ".

Il punto cruciale dell'articolo di Forsyth è che non dovresti cercare di stipare un mucchio di cose non correlate in una grande struttura di dati master. Questo è molto simile alle idee che ho toccato in questa risposta per quanto riguarda derivare tutto nel gioco GameObjecte poi metterlo tutto in un grande elenco eterogeneo (vale a dire, è male).

Relativamente pochi oggetti al mondo mostrano davvero una forte relazione genitore-figlio come si addice a una struttura ad albero. L'esempio canonico di una tazza di caffè su un tavolo è di solito usato qui - certo, potresti considerarlo come un "figlio" del tavolo ... almeno fino a quando non viene eliminato. Quindi è davvero ancora un figlio del tavolo? Ciò significa che il tuo 'albero' può finire in modo piuttosto superficiale e in qualche modo degenerato in un elenco.

Quindi suggerirei di utilizzare più strutture dati per più cose, poiché ha più senso per quelle cose. La geometria statica e le luci, ad esempio, sembrano una cosa ragionevole da inserire nel grafico di una scena. Anche se gli oggetti rappresentati non hanno relazioni genitore-figlio naturali, il fatto che siano statici significa che puoi dare loro relazioni genitore-figlio strutturali sapendo che non cambiano mai.

Attori di gioco ... Non ne sono così sicuro. Qualunque cosa che tende a muoversi, infatti, significa che di solito è necessario tenerli vicino alla radice del grafico o ripensarli costantemente (che è un lavoro ingrato e non super efficiente).

Proiettili, trigger, effetti speciali e altri oggetti transitori che conserverei altrove. Nulla che renda o abbia una rappresentazione visiva (un trigger è in genere un volume di delimitazione invisibile, un proiettile è di solito solo un cast-ray cast) dovrebbe essere in un grafico di rendering. Dovresti cercare di separare i livelli di rendering e logica .

Per quello che vale, non ho mai usato un grafico di scena simile ad un albero in nessuno dei renderer che ho creato per uso non accademico (ovviamente ho già creato grafici di scene simili ad alberi prima, ed è così che sono arrivato alle conclusioni che ho ora sto provando a farti concordare).

Uso metodi di partizionamento spaziale appropriati allo stile di gioco (quad-tree, octree, BSP, eccetera) per raggruppare / abbattere le entità logiche nel gioco che dovrebbero essere (a) elaborate questo frame e (b) renderizzate questa cornice. Finisco quindi per alimentare l'insieme di oggetti dall'elenco (b) in un sistema che mappa gli oggetti logici per renderizzare le descrizioni e ordina tali descrizioni in bucket in base alle proprietà (ad esempio, tutto ciò che utilizza la trasparenza verrà inserito nel bucket per "roba" dovrebbe essere reso back-to-front). Quindi eseguo il rendering di ogni bucket in ordine e per ogni bucket eseguo il rendering di ogni descrizione in ordine. Immagino che potresti chiamarlo "albero", ma non mostra lo stato tipico / trasforma i metodi di propagazione che fanno i tradizionali grafici di scena orientati agli alberi. YYMV,