OpenGL: implementazione matrice di trasformazione stack

Question

In un OpenGL più recente non esiste uno stack di matrice. Sto lavorando su un semplice motore di visualizzazione e ho intenzione di implementare lo stack di trasformazione.

Qual è una strategia comune qui? Dovrei costruire uno stack push/pop e usarlo con un albero che rappresenta il mio modello? Suppongo che questo sia l'approccio "vecchio", che è stato deprecato nelle versioni OpenGL più recenti. Forse allora non è la soluzione migliore (è stato rimosso per qualche ragione, a me sconosciuto)

Answer 1

(è stato rimosso per qualche motivo)

è stato rimosso, perché nelle moderne applicazioni 3D il l'intera funzionalità di manipolazione della matrice OpenGL era altamente ridondante. Ogni moderna applicazione 3D ha bisogno di gestire le matrici comunque, e poiché OpenGL non è una vera libreria matematica matriciale, useresti comunque qualcosa come Eigen o GSL o qualcosa come homebrewn.

Uno stack è ancora una struttura molto valida.

Answer 2

Non sono molto esperto in questo in particolare, ma ho fatto un bel po 'di sviluppo di grafica e giochi. Ho più di un'idea che una risposta. A mio parere, la roba glPushMatrix e glPopMatrix è deprecata perché molti sviluppatori volevano il pieno controllo delle trasformazioni piuttosto che OpenGL, avendo cura di questo per loro. Quindi la mia idea è che non sono deprecati perché uno stack matrix non è la strada da percorrere, ma piuttosto perché gli sviluppatori GL dovrebbero prendersi cura delle matrici stesse, o usare un'altra libreria per farlo per loro.

In altre parole, uno stack matrix è ancora probabilmente la strada da percorrere, devi solo farlo da solo, utilizzare funzionalità obsolete o utilizzare una libreria esterna.

Answer 3

La funzionalità di pipeline fisse è stata ritirata perché, in sostanza, è stata riparata.

Per supportare nuovi trucchi e in genere richieste nuove funzioni OpenGL, è apparso chiaro che supportare continuamente le funzionalità richieste significherebbe aumentare le dimensioni dell'API OpenGL e renderlo progressivamente sempre più ingombrante.

Nel frattempo, l'hardware stava diventando sempre più sofisticato e potente, e non era completamente sfruttato da OpenGL. Quindi la pipeline programmabile è stata concepita.

Con OpenGL3 il gruppo Kronos ha "deprecato" la funzionalità di pipeline fissa. Ciò ha causato un enorme scalpore perché c'era tanto codice e così tanto talento investito nella ben nota pipeline fissa, quindi hanno parzialmente fatto marcia indietro sulla loro decisione, introducendo i profili "core" e "compatibilità". Il profilo principale comprende il nuovo modello di pipeline programmabile e il profilo di compatibilità include il nucleo e la maggior parte/tutte le funzionalità fisse, consentendo alle applicazioni di utilizzare entrambi i modelli.

Ora siamo aperti a OpenGL 4.2 e il profilo di compatibilità è ancora lì e non mostra alcun segno di scomparsa.

In breve, il motivo della deprecazione non è perché il vecchio modello non era adatto per i programmatori di applicazioni; piuttosto, è stato un onere più pesante per gli implementatori . Il modello attuale è abbastanza solido e molte applicazioni/sviluppatori che utilizzano la funzionalità programmabile si ritrovano a reintegrare le parti fondamentali della funzionalità fissa (glBegin, glEnd, stack matrix, chiamate di trasformazione, ecc.).

Quindi, andare avanti, implementare i propri stack matrix.Ma se ti viene un'idea migliore, per favore condividi con noi :)

Answer 4

Non sono sicuro che sia utile, ma ho implementato due cose per questo. La prima è una semplice classe matrix stack con tutti i metodi usuali e la seconda è una struttura RAII basata su stack che mi permette di far oscillare le matrici con le parentesi, cioè sulla costruzione memorizza un riferimento allo stack matrix e alla distruzione ripristina la matrice impilare al suo stato precedente. Così si può scrivere:

MatrixStack stack; 

stack.push(rotate...) 
stack.push(translate...) 

{ 
    MatrixScope(stack); 

    stack.push(rotate...)  
} 

... back to previous stack state. 

E per aggiungere a questo, è solo per convenienza con certi tipi di trasformazioni. Generalmente per i modelli composti da una struttura ad albero di maglie, tutte trasformate l'una rispetto all'altra, combinerò le matrici dal nodo radice prima di fare qualsiasi cosa con il modello. Quindi ogni mesh ha una trasformazione locale e una trasformazione globale, mentre la trasformazione globale è la vera trasformazione per quella mesh rispetto al nodo radice. Quindi non c'è bisogno di usare una pila di matrici lì.

È un po 'diverso se si desidera animare una parte della mesh indipendentemente dal resto, quindi è anche per questo che memorizzo la trasformazione locale anziché buttarla via.