Linee guida per l'ottimizzazione delle prestazioni WebGL minimizzando shading / cambiamenti di stato

Question

Sto cercando di avere un'idea della praticità di WebGL per il rendering di grandi scene di interni, composto da 100K di triangoli. Questi triangoli sono distribuiti su molti oggetti, e ci sono molti materiali nella scena. D'altra parte, non ci sono parti in movimento. E i materiali tendono ad essere abbastanza semplice, per lo più sulla base di mappe di texture. C'è un sacco di texture map condivisione .. per esempio tutte le sedie in scena condivideranno una mappa comune. Ci sono anche alcune multitexturing -. Fino a tre texture sovrapposte in un materiale

Ho fatto un po 'di sperimentazione e la lettura, e raccolgo che i materiali di commutazione di frequente durante un passaggio di rendering sarà rallentare le cose. Ad esempio, una scena con 200K triangoli avrà significative differenze di prestazioni, a seconda che ci sono 10 o 1000 oggetti, assumendo che ogni volta che viene visualizzato un oggetto un nuovo materiale è impostato.

Così sembra che se le prestazioni è importante la scena deve essere ordinato per i materiali in modo da ridurre al minimo la commutazione materiale. Quello che sto cercando è linee guida su come pensare al sovraccarico di vari cambiamenti di stato, e dove posso ottenere il più grande bang per il dollaro. Ad esempio,

• quali sono i costi di prestazioni relative di, diciamo, gl.useProgram(), gl.uniformMatrix4fv(), gl.drawElements()
• dovrei provare a scrivere ubershaders per ridurre al minimo la commutazione dello shader?
• Dovrei provare a geometria aggregata per ridurre al minimo il numero di chiamate gl.drawElements()

mi rendo conto che chilometraggio può variare a seconda del browser, sistema operativo e hardware grafico. E sto anche non in cerca di misure eroiche. Solo alcune linee guida da parte di persone che hanno già avuto qualche esperienza nel fare scene in rapido. Io aggiungo che, mentre ho avuto qualche esperienza con-gasdotto fisso di programmazione OpenGL in passato, io sono piuttosto nuovo per il 2.0 modo WebGL / OpenGL ES di fare le cose.

Answer 1

Hai letto lotto, lotto, lotto ? Certo, si concentra su directX, ma il ragionamento si applica in misura minore per aprire / WebGL anche: Ogni chiamata API ha overhead significativo sulla CPU. Il consiglio è di utilizzare tutte le opzioni del API alle texture di condivisione, l'uso di istanze (se disponibile), scrivere shader complessi per evitare molte chiamate draw. Quindi, se è possibile disegnare tutta la casa come una singola rete in una singola chiamata, che sarebbe meglio di 1000 chiamate per ogni camera. Scrivendo ubershaders è consigliato, ma soprattutto perché può consentire di rimuovere disegnare le chiamate, non perché la commutazione dello stato GPU è costoso.

Questo presuppone recente hardware. Per i chip piattaforme di fascia bassa (iPad?) O Intel GMA, i colli di bottiglia sarà altrove (come in elaborazione dei vertici del software).