Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Game Development
  2. 3D Rendering
Gamedevelopment

La fine della Pipeline di Rendering a Funzione Fissa (e come andare avanti)

by
Length:MediumLanguages:

Italian (Italiano) translation by Chip (you can also view the original English article)

(n.d.a. non traduco il termine "f.f.p." perché usato praticamente anche in italiano) Le fixed function pipeline non hanno più lavoro sulle nostre schede video. Ecco quello che dovete sapere su di loro e come effettuare il passaggio di allontanamento, se ancora non l'avete fatto.

il principio: La nascita dell'Hardware Grafico

C'era una volta, in cui lo sviluppo dei giochi (o la programmazione di tutto ciò che aveva a che fare con la grafica in tempo reale) era limitato alla scrittura di una piccola matrice di intensità di colore (il frame buffer) da inviare all'hardware, potevate farci tutto quello che volevate. Potevate disegnare l'immagine una, dieci o cento volte. Potevate passare sul frame buffer di nuovo a fare un po di FX. Insomma, qualunque cosa il vostro processore era in grado di fare, lo potevate fare per l'immagine che veniva inviata al monitor. Questo ha permesso di fare un veramente cose eccezionali e creative, ma la gente non l'ha (o raramente) usata in quella misura. ma perché?

La risposta è: perché era lento. Una immagine 640 × 480px (una risoluzione comune a quel tempo) contiene 307.200 pixel. Le CPU erano così lente, allora, che non si poteva davvero fare molto nel breve tempo a disposizione per disegnare quel fotogramma. Dopo tutto, se si desiderava mantenere il disegno a 30FPS, avevate solo circa 30ms per aggiornare la logica di gioco e il rendering allo schermo, e si dovevate considerare anche il sovraccarico di intercomunicazione con l'hardware. Non era molto.

Poi arrivarono le GPU fantastiche con pipeline di rendering. Voi, gli sviluppatori, vi prendete cura di aggiornare la logica del gioco e di inviare le tue texture ed i triangoli alla GPU che svolge il lavoro pesante macinandoli. Erano a funzione fissa di rendering pipeline (FFP): il che significava che non si potevano configurare le funzioni che eseguiva. Gli si poteva dire "fai la nebbia grigio scuro" o "non farmi l'illuminazione!" e si poteva configurare un sacco di altri parametri, ma le funzioni rimanevano se stesse.

L'hardware è stato cablato e strettamente specializzato in modo che eseguisse determinate operazioni standard sui dati. Essendo realizzato in questo modo cablato, era molto più veloce che farlo fare al vostro processore. Ma un problema era che si pagavano molto per quella velocità: si pagavano in termini di flessibilità. Ma se volevate disegnare qualcosa di complesso, la CPU semplicemente non era abbastanza veloce, e presentare i vostri vertici alla GPU era l'unica scelta.

Questo è più o meno come funzionava la a pipeline a funzione fissa. L'immagine non è da intendersi come una rappresentazione accurata, ma è per darvi un indizio di come venga eseguito il tutto.

L'esigenza di un maggiore realismo

Il mondo della grafica sta cambiando rapidamente. Proprio come tutte le persone creative e di talento, gli sviluppatori di giochi amano le sfide, e una delle sfide per loro era (e rimarrà), da lungo tempo, rendere sempre più belle e realistiche le immagini.

La pipeline a funzione fissa forniva alcune caratteristiche, come diversi metodi di blending, il per-vertex Gouraud shading, effetti nebbia, stencil buffer (per le ombre volumetriche) e simili, così gli sviluppatori usavano quello che potevano. Ben presto, alcuni effetti divennero davvero impressionanti, tutto in virtù dei fenomeni reali simulati utilizzando alcuni trucchi a buon mercato (e, a buon mercato per gli standard odierni).

Andava tutto molto bene, ma comunque era tutto limitato dalla quantità di funzioni che la pipeline a funzioni fisse poteva fare. Dopo tutto, il mondo reale ha così diversi e tanti materiali, e per simularli, l'unica variazione permessa era cambiare alcuni metodi di blending, aggiungere alcune texture in più, o modificare i colori di riflessione della luce.

Poi è successo: sono arrivate le prime GPU programmabili. Non arrivarono in una notte, naturalmente, ci aspettavamo che arrivassero un giorno prima ma la cosa suscitò comunque molta eccitazione. Queste GPU avevano quella che era chiamata una pipeline di rendering programmabile: ora si potevano scrivere programmi, chiamati shader, in un limitato linguaggio assembly, che venivano eseguiti per ogni vertice o frammento, sulla scheda video. Questo fu un grande salto in avanti e sempre meglio.

Presto i linguaggi assembly aumentarono in complessità ed espressività ed linguaggi di alto livello per la programmazione della GPU emersero, come HLSL, GLSL, e più tardi Cg. Oggi abbiamo geometry shader che possono anche generare nuovi vertici o shaders che controllano dinamicamente la tessellation in triangoli (processo di divisione di una mesh in una primitiva più semplice); al loro interno è possibile gestire tantissime texture, diramare processi dinamici e fare ogni sorta di matematica folle con i valori di input.

Quando si date agli sviluppatori questi vantaggi, diventano pazzi; ben presto stavano scrivendo shader per ogni genere di cose: parallax mapping, modelli di illuminazione personalizzati, rifrazione, e via dicendo. Più tardi, emersero anche i sistemi di illuminazione completamente personalizzati, come ad esempio l'ombreggiatura differita e le luci pre-pass, si potevano vedere effetti post elaborazione complessi come lo screen space ambient ambient occlusion e l'horizon based ambient occlusion. Alcuni hanno anche "abusato" nel fare shader, come compiti ripetitivi e matematicamente pesanti, elaborazione di statistiche o la suddivisione di stringhe in strutture hash . (Questo è stato prima che il la programmazione a scopo generico sulle GPU ottenesse il supporto delle masse.)

In breve, la computer grafica esplose con l'introduzione degli shader e con buona ragione: la possibilità di programmare cosa accade esattamente sui vertici, fragments, texture, e così via, e il farlo in fretta, ha portato a possibilità quasi infinite.

Una rappresentazione semplificata della pipeline programmabile. Notare come le fasi di trasformazione, di ombreggiatura o del texturing sono state sostituite da shader specializzati. (Tessellation omesso per chiarezza.)

La Svolta Completa

Ben presto, le pipeline a funzione fissa sono diventate obsolete, almeno per gli sviluppatori di giochi. Dopo tutto, perché preoccuparsi di tali ambienti chiusi quando si può programmare con precisione cosa succede ai vostri dati? Rimasero in uso per molto più a lungo in alcune applicazioni in cui il realismo non era un problema, come ad esempio per i CAD. Ma nel complesso, sono stati sempre ignorati.

OpenGL ES 2.0, uscito nel 2007, ha deprecato o rimosso la sua pipeline a funzione fissa in favore di una programmabile. OpenGL 3.2, nel 2009, finalmente rimosse ogni nozione di funzione fissa sui o sulla lavorazione dei fragment (tuttavia, rimane disponibile per l'utilizzo legacy mediante un profilo di compatibilità). E' chiaro che abbia poco senso oggi lavorare con una pipeline limitata quando si hanno a disposizione GPU potenti e capaci di fare cose impressionanti.

Anche se queste API costringono all'uso degli shaders (e questo include le DirectX, che, pur non togliendo esplicitamente la funzionalità, danno strumenti per aiutare la migrazione dal vecchio approccio, e non ha offrono più nessuna documentazione relativa alla FFP), sono comunque difficili da padroneggiare. Se si parte come neofiti della programmazione 3D, è molto più facile dare alle API le vostre matrici, i parametri di illuminazione, e quant'altro e farle fare tutto per voi.

Ma nel lungo periodo, si ha maggiore beneficio se si impara a scrivere programmi che descrivono con precisione i processi. Sarà complicato capire che cosa sta succedendo sotto il cofano, comprendere alcuni concetti molto importanti che le FFP non richiedevano, ed essere in grado di ottimizzare i vostri materiali molto facilmente per fare qualcosa di complesso che la funzione fissa non avrebbe mai poututo fare per voi (ed è anche utile per il debug!).

Ho citato OpenGL ES, permettetemi di scendere più in dettaglio. Man mano che i giochi su cellulare diventano sempre più popolari, ha senso creare mondi virtuali con crescente complessità. La maggior parte delle chiamate a funzione fissa sono state rimossi in ES 2.0 (e naturalmente, significa che sono anche assenti dalle versioni successive). Questo significa che essenzialmente, al fine di utilizzare una delle funzioni dopo ES 1.1, è necessario utilizzare shader.

ES 2.0 è supportato da iPhone 3GS, iPad fin dal primo rilascio, e iPod Touch dalla generazione 3 e superiori. Qualcomm Snapdragon, un chip ampiamente utilizzato nella produzione di telefoni Android, supporta OpenGL ES 2.0. Questo è sostegno molto ampio, perché ES 2.0 non è esattamente "nuovo": ha più di 7 anni ormai. Per ottenere il massimo da queste architetture, è necessario abbandonare la pipeline a funzione fissa.

Presumo che molti di voi lo abbiano fatto molto, molto tempo fa, ma non è così difficile per me immaginare alcuni motori grafici 2D o giochi legacy che utilizzano ancora le pipeline funzione fissa (perché non gli serve altro). Va tutto bene, ma il suo utilizzo per i nuovi progetti, o la formazione di programmatori specifici, sarebbe una perdita di tempo. Questo è amplificato dal fatto che un sacco di tutorial, grossolanamente obsoleti, si possono trovare su Internet che vi insegnano come utilizzare le FFP fin dall'inizio e prima ancora di capire cosa sta succedendo, ci sarete cascati dentro.

Il mio primo incontro con la grafica 3D, infatti, fu un antico tutorial DirectX 7 scritto in Visual Basic. A quel tempo, utilizzando la pipeline a funzione fissa, aveva senso, poiché l'hardware non era abbastanza avanzato per ottenere la stessa funzionalità e velocità con gli shader. Ma oggi, vediamo API grafiche che iniziano ad abbandonare o deprecare il supporto alle FFP che oramai sono solo un artefatto del passato. Si tratta di artefatti buoni e utili che ci rendono nostalgico, ma ci dovremmo starne alla larga. Sono vecchi e non più utilizzati.

Queste morbide riflessioni fresnel e rifrazioni, generate da un demo di OGRE (Open-source Graphics Rendering Engine, Motore di Rendering Grafico Open-source), non sarebbero mai potute essere fatte se si stesse ancora usando i vecchi metodi consigliati nei tutorial delle vecchie DirectX 8 o OpenGL 1.1.

Conclusioni

Se siete seriamente interessati allo sviluppo di giochi, appendete al chiodo del pipeline a funzione fissa, sono una reliquia dei tempi passati. Se stai pensando di entrare nella grafica 3D, il mio consiglio (e il parere di molti, molti sviluppatori là fuori) è quello di evitarle semplicemente.

Se vedete passare delle posizioni di illuminazione alle API grafica (non come un parametro allo shader), o funzioni di API chiamate come la glFogv, correre come il vento e non guardatevi indietro. C'è un nuovo mondo coraggioso di GPU programmabili là fuori, e sono in giro da molto tempo. Tutto il resto probabilmente è solo uno spreco del vostro tempo.

Anche se siete solo nella grafica 2D, è ancora una saggia idea non fare più affidamento sulle FFP. (Naturalmente, siamo d'accordo che anche voi non supporterete più i componenti hardware antichi.) Shader sono in grado di fornire eccezionali effetti fulminei. Immagini sfocate, nitidezza, warp grids, rendering vettoriale, e particelle o simulazioni fisiche su larga scala possono essere fatte sulla GPU e tutti possono trarne beneficio sia i giochi in 2D che 3D.

Così, ancora una volta, il mio consiglio, anche se non avete intenzione di imparare in modo esplicito lo sviluppo dei giochi 3D, è quello di imparare a scrivere shader. E' divertente lavorarci e vi garantisco che trascorrerete molte ore divertenti a perfezionare un effetto shader: uno skybox dinamico, vernice per auto o la mappatura di ombra in parallele, o qualunque altra cosa il vostro cuore desideri. Almeno questo è quello che è successo a me: una volta che si è abituati a lavorare con la pipeline fissa a causa di alcune limitazioni (come sono stato costretto a fare, nei giorni passati, al fine di ottenere prestazioni accettabili sulla mia 5200FX), la programmazione della GPU è una esplosione di divertimento.

Spero di aver spiegato a coloro per i quali non era chiaro, come la grafica 3D era utilizzata per lavorare molto tempo fa e come funziona ora, e spero di aver convinto i pochi di voi che erano sul punto di seguire i tutorial NeHe o Swiftless ad andare a vedere qualcosa di più moderno. Come sempre, forse avrò fatto alcuni errori, quindi sentitevi liberi di indicarli nei commenti. Fino alla prossima volta!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.