È necessario il disegno fronte-retro per l'ottimizzazione dei rendering?

Question

Ho visto l'articolo occasionale suggerire di ordinare i vostri vertici dal più vicino al più lontano dalla fotocamera quando li inviano a OpenGL (per qualsiasi delle varianti OpenGL). La ragione suggerita da questo è che OpenGL non elaborerà/renderà completamente un vertice se è dietro un altro vertice già renderizzato.

Poiché ordinare i vertici in base alla profondità è un componente costoso di qualsiasi progetto, poiché in genere questo ordine cambia frequentemente, quanto è comune o necessario tale progetto?

precedenza avevo pensato che sarebbe OpenGL "look" a tutti i vertici presentate ed elaborare un proprio buffer di profondità su di loro, indipendentemente dal loro ordine, prima di rendendo l'intero lotto. Ma se in effetti un vertice viene reso sullo schermo prima di un altro, allora posso vedere come l'ordinamento potrebbe avvantaggiare le prestazioni.

È necessario il disegno fronte-retro per l'ottimizzazione dei rendering?

Answer 1

Una volta rasterizzata una primitiva, il suo valore z può essere utilizzato per eseguire una "early z kill", che salta lo shader di frammenti. Questa è la ragione principale per eseguire il back-to-back. Suggerimento: quando si dispone di poligoni trasparenti (con texture alfa), è necessario eseguire il rendering back-to-front.

Le specifiche OpenGL definiscono una macchina a stati e non specifica in quale ordine il rendering avviene effettivamente, ma solo che i risultati devono essere corretti (entro certe tolleranze).

Edit per chiarezza: Quello che sto cercando di dire di cui sopra è che l'hardware può fare quello che vuole, a patto che i primitivi appaiono a sono stati elaborati al fine

Tuttavia, la maggior parte GPU sono processori di streaming e i loro driver OpenGL non creano geometrie "in sequenza", tranne forse per motivi di prestazioni (dimensioni minime di DMA, ecc.). Se si alimenta il poligono A seguito dal poligono B, vengono inseriti nella pipeline uno dopo l'altro e vengono elaborati indipendentemente (per la maggior parte) l'uno dall'altro. Se c'è un numero sufficiente di poligoni tra A e B, allora c'è una buona probabilità che A completi prima di B, e se B fosse dietro A, i suoi frammenti saranno scartati via "early z kill".

Modifica per chiarezza: quello che sto cercando di dire sopra è che dato che hw non esegue il "batch up" della geometria, non può eseguire automaticamente l'ordinamento fronte-retro.

Answer 2

Qui confondete alcuni concetti. Non è necessario riordinare i vertici (*). Ma dovresti disegnare oggetti che sono opachi dalla parte anteriore a quella posteriore. Ciò abilita quello che viene chiamato "early z rejection" sulla GPU. Se la GPU sa che un pixel non sarà ombreggiato dal test z, non deve eseguire lo shader, eseguire fazzoletti di trama, ecc. Questo vale per gli oggetti nelle chiamate draw, anche se non per i singoli oggetti.

Un semplice esempio: hai un personaggio giocatore e uno sfondo di cielo. Se si disegna per primo il giocatore, la GPU non dovrà mai eseguire le ricerche di trama per i pixel in cui si trova il giocatore. Se lo fai al contrario, prima disegna tutto il cielo e poi coprilo.

La geometria trasparente deve tornare in primo piano.

(*) = i vertici possono essere riordinati per prestazioni migliori. Ma fare presto z è molto più importante e fatto per oggetto.