Come viene eseguito il rendering del software?

Vorrei esplorare la rasterizzazione basata su software in tempo reale. So che tutto sta andando verso la GPU in questi giorni, ma ci sono alcuni giochi in cui ha ancora senso usare un renderer software.

Ad esempio: Voxeltron

Voxatron è uno sparatutto nell'arena che si svolge in un mondo fatto di voxel (cubetti, tipo di). Tutto nel gioco viene visualizzato in un display voxel virtuale 128x128x64, inclusi i menu e l'inventario dei giocatori. Se guardi da vicino, a volte puoi vedere l'inventario (punteggio / vita / munizioni) proiettare un'ombra su alcuni degli oggetti sul terreno.

Ho lavorato a lungo su strumenti di rendering e modellazione voxel, con l'obiettivo finale di realizzare un grande gioco di avventura esplorativa. Circa mezzo anno fa si è fuso con il lavoro che stavo facendo sugli sparatutto in arena per Conflux, e questo è il risultato.

È un gioco abbastanza semplice, soprattutto Robotron ambientato in un mondo distruttibile 3d con creature sciocche. Non sono sicuro di quanto importanti saranno le implicazioni della distruttibilità per il gameplay, ma è sicuramente divertente far saltare pezzi di muro. Ho anche aggiunto un pickup sperimentale per la costruzione di muri che puoi usare per costruire barriere per nasconderti dai mostri spaventosi.

Il gioco si svolge in un piccolo set di arene. Alcune dispongono di stanze con pezzi d'azione, tra Knightlore e Smash TV. Questo è un po 'del design originale basato sull'avventura che torna di nascosto e una scusa per creare ambienti tematici.

Caratteristiche:

• Rendering software personalizzato con ombre morbide.
• Sintetizzatore audio e musicale integrato (utilizzato anche per la musica del trailer).
• Riproduzione e registrazione post partita.

Presumo che tu conosca già qualche algebra lineare di base, il tipo coinvolto in: proiezioni 3d, impostazione della telecamera, trasformazione dei vertici in posizione mondiale, ecc ... Se non lo fai, ci sono molti ottimi posti da cui imparare. Eccone due che mi piacciono:

Architettura di Game Engine

• Breve copertura dell'algebra lineare di base ma copre tutto ciò che devi sapere. Vale la pena avere il libro anche per molte altre ragioni.

Rendering in tempo reale

• Una copertura un po 'più dettagliata ma si attacca ancora solo a ciò che potresti aver bisogno di sapere. Ancora una volta, lo consiglio per gli argomenti trattati nel resto dei capitoli.

Una volta che sai come rappresentare e gestire gli oggetti 3d, sei pronto a guardare come disegnarli sullo schermo. In genere questo viene fatto con una tecnica di rasterizzazione del triangolo della linea di scansione. In realtà è un concetto piuttosto semplice. Disegna una riga di un triangolo alla volta mentre interpoli le coordinate di colore e trama uv. Questo processo è continuato per tutti i triangoli sullo schermo. È anche possibile implementare un buffer di profondità per gestire il rendering fuori ordine.

Questo è trattato in modo più dettagliato in questi articoli:

Tutorial - Introduzione al rendering basato su software: Triangle Rasterization

Software Rendering School: Part I

E solo per divertimento, dai un'occhiata al seguente articolo:

Revisione del codice sorgente di Quake 2 3/4 (rendering software)

Questo è un argomento piuttosto ampio. Ci sono due parti di base, tuttavia: la teoria effettiva della pipeline di trasformazione grafica e rasterizzazione e i bit di implementazione effettivi che ti consentono di far esplodere i pixel sullo schermo come preferisci. Inoltre, c'è anche l'ottimizzazione (in particolare di quest'ultimo bit).

La prima parte è fortunatamente la stessa della teoria utilizzata per la pipeline grafica esposta da hardware e API moderni. Se lo sai già, sei pronto. In caso contrario, ti consiglio un buon libro.Questo è abbastanza buono.

Ci sono molte opzioni per la seconda parte. Dipendono fortemente dal sistema operativo e dalle scelte della toolchain. Se stai usando C o C ++, su Windows, puoi semplicemente tracciare i pixel direttamente su una bitmap GDI ( SetPixelè semplice, ma dolorosamente, inutile lento -CreateDIBSection ti dà una porzione di byte grezzi che puoi manipolare a una velocità molto più veloce).

Puoi anche acquisire una superficie DirectDraw e scrivere su quella oppure scrivere su una trama Direct3D o OpenGL. In questi ultimi casi continuerai a utilizzare l'hardware, ma fintanto che esegui tu stesso tutta la composizione dell'immagine finale sulla CPU e usi solo le API hardware per copiare i risultati sullo schermo, conta comunque. Sui PC moderni non è comunque possibile accedere alla VRAM grezza o altro direttamente.

Se desideri saperne di più, dovresti probabilmente creare domande più specifiche. Io o altri saremo felici di rispondergli.

Va bene affronterò questa domanda dalle basi; qualsiasi cosa oltre a ciò è un modo per estendere un semplice QA; devi comprare un libro sull'argomento.

La differenza fondamentale tra il rendering nel software e l'uso di una GPU sta nel tracciare i pixel. Cioè, quando si esegue il rendering del software, si è in definitiva responsabili della stampa di ogni maledetto pixel, mentre con una GPU la stampa di pixel è ampiamente automatizzata dall'hardware e si "massaggia" la pipeline di pixel usando gli shader.

Ad esempio, pensa a cosa devi fare come programmatore per visualizzare un triangolo 3D sullo schermo. Con una GPU, dici praticamente all'hardware quali sono le coordinate X, Y, Z dei vertici e quindi la scheda video riempie tutti i pixel sullo schermo che compongono l'immagine di un triangolo. Puoi usare uno shader per dire alla GPU di cambiare il colore di ogni pixel in base a una trama o qualcosa del genere, ma alla fine si riduce alla GPU riempiendo automaticamente tutti i pixel per te.

Effettuando il rendering del software, dovresti calcolare quali pixel sullo schermo riempire, quindi fare il blitting per riempire effettivamente quei pixel. Cioè, faresti la matematica della matrice per trasformare dallo spazio delle coordinate della scena 3D allo spazio della vista, quindi proiettare i punti dallo spazio della vista sullo schermo, ecc.