OpenGL - Perché lo stack matrix è stato rimosso e cosa stanno usando le persone adesso?

Question

Sto leggendo la quinta edizione di OpenGL Superbible e discutono sull'uso di pile tramite la loro stessa classe. Questo è tutto eccezionale, ma menzionano che gli stack di matrici sono stati deprecati. Perché erano deprecati e cosa usano le persone invece di loro?

Answer 1

Matrix Stack (e il resto delle funzioni matrix) sono stati dichiarati obsoleti solo nel profilo principale. Nel profilo di compatibilità dovresti comunque essere in grado di usarli.

Dal mio punto di vista è stato rimosso perché la maggior parte dei motori/quadri hanno il codice personalizzato per la matematica e shader stile uniforme per l'invio di matrici a shader.

Anche se per programmi/tutorial semplici è molto scomodo da utilizzare e cercare qualcos'altro.

Io suggerisco di usare:

• glm (http://glm.g-truc.net/)
• molto semplice matematica lib (vsml)

Answer 2

Beh, la prima e la principale ragione, per me, è che con l'aumento di shader programmabili (essendo obbligatori dopo la terza versione di opengl), tutte le variabili come GL_PROJECTION e GL_MODELVIEW trasferite automaticamente agli shader vengono eliminate dagli shader, quindi l'utente deve definire la propria matrice per usalo nello shader. Dato che devi inviare manualmente la matrice usando le funzioni Uniform, non hai più bisogno di variabili fisse.

Answer 3

Perché erano deprecato

Perché nessuno effettivamente utilizzato in programmi OpenGL del mondo reale. Prendiamo ad esempio una simulazione fisica: avresti comunque tutti gli oggetti posizionati nel sistema fisico come una matrice 4 × 4. Quindi lo useresti semplicemente. Lo stesso vale per i sistemi di determinazione e animazione degli oggetti visibili. Tutti quelli che hanno bisogno di implementare la Matrix Matematica comunque, quindi avere questo in OpenGL è piuttosto ridondante, poiché la maggior parte delle volte le matrici già esistenti sono state semplicemente immesse in glLoadMatrix.

e che cosa usano le persone al posto di loro?

quello che hanno usato prima: I loro sistemi di animazione, simulatori di fisica, grafici di scena, ecc

Answer 4

La ragione (s) sono politica, non tecnica, e risalgono ai primi anni del 2000.

OpenGL 3 è stata la prima versione disponibile a rompere la compatibilità con le versioni precedenti. I progettisti hanno voluto creare un'API per gli utenti esperti, i programmatori di giochi e i codificatori di visualizzazione di fascia alta che sapevano tutto sugli shader e hanno scritto il proprio codice matrix. L'intento era che l'API di OpenGL 3 dovesse corrispondere all'hardware reale abbastanza da vicino. (Anche in OpenGL 1/2, lo stack matrix veniva solitamente implementato dal lato CPU, non dalla GPU.)

Da un punto di vista del programmatore di giochi di gioco, era meglio. E hey, se devi sviluppare un nuovo motore di gioco ogni due anni, qual è il grosso problema di buttare via il vecchio codice?

Il risultato di questo processo di progettazione è il profilo core OpenGL 3/4.

Dopo l'annuncio della "nuova generazione" OpenGL, tutti i programmatori meno esperti di università e aziende si sono resi conto che sarebbero stati fregati. Queste sono le persone (come me) che insegnano la grafica 3D o scrivono programmi di utilità per la ricerca o la progettazione. Non abbiamo bisogno di un'illuminazione più avanzata rispetto a quella a luce diffusa diffusa. Spesso dobbiamo mescolare il codice da diverse fonti insieme, e questo è facile se tutti usano esattamente la stessa matrice, illuminazione e convenzioni di texturing - come quelle fornite da OpenGL 2.

Inoltre, ho sentito ma non posso verificare, le grandi aziende CAD/CAM si sono rese conto che anche loro sarebbero stati fregati. Eliminare due milioni di righe di codice da dieci anni di sviluppo non è un'opzione quando si paga (e si paga bene: confronta i prezzi per i clienti Quadro vs GeForce, o FireGL vs Radeon).

Quindi sia NVIDIA che ATI hanno annunciato che avrebbero supportato la vecchia API per tutto il tempo che potevano.

Il risultato di questa pressione sono i profili di compatibilità. E l'OpenGL ARB ora sembra aver capito che mentre loro vorrebbero che tutti passassero al profilo principale non succederà: leggi le specifiche dell'estensione per gli shader di tessellation in OpenGL 4 e menziona che GL_PATCHES funzionerà con glBegin.