Grande @davcri! Sempre carico per qualcosa di nuovo! … E mi costringi a fornire una delle mie opinioni fastidiose 😃
Io sono un vecchietto e quindi ho visto un po’ di fasi e trend, e anche, “come insegnare/imparare la computer graphics?” e’ un panel fisso a praticamente ogni conferenza del settore, soprattutto nell’era della scomparsa degli engine custom e l’affermazione di Unity/Unreal etc.
Il mio consiglio quindi alla luce di tutto questo e’: NON partirei da un tutorial su OpenGL, in quanto NON partirei da OpenGL, in quanto NON partirei dal rendering in real-time!
E’ molto popolare partire da quello, perche’ onestsmente, disegnare mille mila triangoli in 16ms e’ figo e ci si sente subito un po’ Carmack, almeno io penso sia un po’ cosi’… Pero’ secondo me e’ molto piu’ proficuo partire da quel rendering fatto tutto in CPU in cui ci vogliono secondi/minuti/ore per creare un solo frame, magari da quei tutorial che hanno gia’ in prima pagina gli integrali e la rendering equation [spoiler: non serve sapere bene nessuno dei due per partire]… Sembra una stupidaggine, elenco quindi quelli che secondo me sono i vantaggi:
- Imparate le basi comuni, quindi camera model ecc, ci si concentra su un modo di fare rendering molto chiaro che aiuta a tenere sempre in focus il core di quello che si sta facendo, che poi verra’ espanso con metodologie strane/complesse in real-time, ma si avranno le cose importanti piu’ probabilmente piu’ chiare
- Aiuta chi vuole essere magari solo “user” di engine, in quanto molto presto ci si comincia ad occupare di caratteristiche di materiali, shading models ecc. che poi vengono usati da tanti engine standard, o sui macro-concetti tipo i tipi di luci e i loro effetti, ombre ecc
- Aiuta anche chi vuole diventare “dev” di engine perche’ secondo me si diventa piu’ in fretta capaci di scorrere il codice di un renderer e non perdersi nei dettagli di es. questa o quella API ma si cerca sempre “i concetti fondamentali”, quindi dove e come sta avvenendo lo shading rispetto alla luci, i materiali ecc
- Piu’ in generale, con l’aumento di efficienza dell’HW e l’arrivo su molte piattoforme di API o HW specifico per accelerare “ray intersection”, il confine tra cosa e’ tecnica real-time e cosa e’ off-line si sta assottigliando
Ci sono pero’ anche dei vantaggi pratici
- Non si devono gestire da subito codebase che sono al 70% gestione dell’API e relativi stati e 30% logica - questo e’ vero soprattutto all’inizio in quanto l’overhead sul codice dell’API cresce fortunatamente meno velocemente alla logica delle pass, o degli shader
- Iniziare scrivendo tutto su CPU rende piu’ facile il debugging, che e’ quello di un programma normale, e non bisogna spendere tempo ad imparare nuovi tool per fare debugging di quanto avviene su GPU
Certo, ci sono robe del rendering off-line che si possono saltare, tipo come fare il rendering delle caustiche di liquidi, quando si arriva (ma anche prima) li’ ci si puo’ fermare e cominciare a guardare il rendering in real-time, e quindi OpenGL/DX11/Metal. A quel punto, si potra’ provare a ricondurre i nuovi concetti a tecniche equivalenti off-line, e capire piu’ facilmente tutti gli hack che si fanno in real-time (che sono hack, non soluzioni eleganti, adottati in quanto “tanto questo in nessun gioco si notera’” e/o per venire incontro ad una macchina molto limitata e scorbutica chiamata GPU [termine brevettato da NVIDIA nostri overlord]).
Ma quindi da dove si parte? Secondo me al momento la risorsa migliore e’ scratchpixel: https://www.scratchapixel.com/
Non sono sicuro abbia codice compilabile, forse si’, ma ha ottimo pseudocodice. Si possono fare i vari tutorial (skippando o meno la math) ma skippando la parte su rasterization, e fare quella alla fine. C’e’ anche il classico raytracing in one weekend che dovrebbe avere codice compilabile. Una volta fatti quelli si puo’ partire coi tutorial in real-time, learnopengl.com se non ricordo male e’ ben fatto.
Ecco, vi ho rovinato tutti i piani, forse, ma dovevo salvarvi!!!
