Qual è una buona soluzione per la struttura dei dati di un gestore di scene in XNA?

Sto giocando con XNA per un progetto di gioco personale, ho avuto una precedente esposizione a OpenGL e ho lavorato un po 'con Ogre, quindi sto cercando di ottenere gli stessi concetti lavorando su XNA.

In particolare sto cercando di aggiungere a XNA un gestore di scene per gestire trasformazioni gerarchiche, abbattimento di frustum (forse anche occlusione) e smistamento di oggetti trasparenti.

Il mio piano era quello di costruire un direttore di scena ad albero per gestire trasformazioni e illuminazione gerarchiche, e quindi utilizzare un Octree per l'abbattimento di frustum e l'ordinamento degli oggetti. Il problema è come eseguire l'ordinamento della geometria per supportare correttamente i lucidi. So che l'ordinamento è molto costoso se fatto su una base per poligono, così costoso che non è nemmeno gestito da Ogre. Ma le immagini fisse di Ogre sembrano giuste.

Qualche idea su come farlo e quali strutture di dati usare e le loro capacità? So che le persone intorno stanno usando:

• octrees
• Kd-trees (qualcuno nel forum GameDev ha detto che questi sono molto meglio di Octrees)
• BSP (che dovrebbe gestire l'ordinamento per poligono ma che è molto costoso)
• BVH (ma solo per l'abbattimento di frustum e occlusione)

Grazie

Tunnuz

Gli ottre (o anche solo i quadrifogli) e gli alberi Kd sono entrambi buoni schemi di partizionamento spaziale per scopi generici e se la tua pipeline di costruzione e / o motore li sta generando, scoprirai che sono utili in tutti i modi per ottimizzare le query iterazioni /. Funzionano suddividendo un volume fisso in modo gerarchico, il che rende le query come il raycasting nello spazio degli oggetti molto economiche per le quali cercare (ottimo per i controlli delle collisioni).

Le gerarchie di volumi limitanti funzionano in modo leggermente diverso (aggregano i volumi degli oggetti nella struttura anziché gli spazi di suddivisione) e sono un modo semplice per tagliare le cose non necessarie dall'iterazione. Ma poiché BVH non pone alcuna restrizione sul modo in cui due nodi di pari livello sono collegati, non è un ottimo schema per capire l'ordine di rendering o per interrogazioni di collisioni arbitrarie.

I sistemi BSP sono utili quando si suddivide il mondo in base a singoli poligoni, ma per oggetti più grandi un approccio basato sul volume ha più senso.

Soprattutto, vale la pena notare che nessuno di questi sistemi è perfetto per determinare l'ordine di rendering per la trasparenza, anche l'approccio BSP. Sarà sempre possibile costruire una geometria che rompe il tuo algoritmo, a meno che tu non sia in grado di suddividere i poligoni al volo. Ciò che probabilmente stai cercando è una soluzione "best effort", in cui la geometria può essere ordinata correttamente nella maggior parte dei casi; e il team artistico può suddividere i modelli per tutti i casi che non funzionano (perché il modello / i poligoni sono anormalmente grandi, lunghi o autointersecanti). I modelli / nodi più piccoli sono sempre molto più facili da ordinare "correttamente", ma si paga in termini di iterazione.

Kd-trees e Oct / quad-tree sono entrambe buone soluzioni per scopi generici, per le quali è possibile scrivere un'implementazione adatta alla piattaforma, ma alla fine dovrai bilanciare la profondità / complessità del tuo albero di partizionamento spaziale con il costo di iterandolo e le spese generali per modello (ad es. disegnare il costo della chiamata). Se stai prendendo di mira XNA, ti consiglierei di mantenerlo semplice e di alto livello, e se ci sono problemi di ordinamento con alcuni dei contenuti, allora considera fortemente di cambiare il contenuto prima di provare a migliorare il tuo motore fino a quando non può farcela; i rendimenti diminuiscono molto rapidamente dopo l'implementazione dell'ordinamento di rendering più semplice.

McCranky ha coperto in modo sorprendente tutte le strutture di dati che hai citato, tuttavia vedo che non hai considerato R-Trees. Il corpus di conoscenze su queste strutture è enorme e sono molto adatte per le query spaziali spaziali (la maggior parte del lavoro è stato svolto da teorici e professionisti del database) negli ultimi 30 anni. Di recente Sebastian Sylvain di Rare ha tenuto un corso sul GDC sul motivo per cui lavorano anche per i giochi (specialmente su console con processori in ordine). Puoi saperne di più dal suo pdf: http://www.gdcvault.com/play/1012452/R-Trees-Adapting-out-of

Un'implementazione ingenua e semplice è piuttosto semplice e la struttura di base offre molto spazio per il miglioramento (migliore gestione dell'euristica di divisione, ottimizzazione delle opportunità, ricerca parallela, ecc.).

La risposta dipende fortemente dalla quantità di modelli che si prevede di utilizzare. Non ho davvero lavorato con questo tipo di cose per XNA, ma se usi AABB per i test e non hai troppi modelli potresti essere abbastanza bravo con un test di forza bruta. Forse anche buttarlo su un filo. Non sono sicuro di come / se ci sono ottimizzazioni SSE / VMX che possono essere utilizzate per C #, ma se riesci a ottenere linearmente gli AABB in memoria (in modo da non perdere cache-cache per la CPU), dovresti essere in grado per superare un numero elevato di test in pochissimo tempo.