In che modo i moderni motori di gioco ottengono il rendering in tempo reale rispetto al rendering "lento" di Blender?

Sono nuovo sia per Gamedev che per Blender, e c'è qualcosa che non posso scuotere:

In Blender, un singolo rendering (anche usando il renderer Cycles più avanzato) può richiedere fino a 45 secondi sulla mia macchina. Ma ovviamente, in un gioco, puoi avere una grafica incredibile, e quindi il rendering sta ovviamente avvenendo continuamente, più volte al secondo in tempo reale.

Quindi mi chiedo anche quale sia la disconnessione, riguardo a come sembrano essere "lenti" i rendering di Blender, rispetto a come i motori di gioco raggiungono il rendering in tempo reale (o quasi in tempo reale).

rendering blender

— smeeb
fonte

Il rendering in tempo reale è un argomento enorme in sé, ci sono molti libri scritti su di esso (incluso "Rendering in tempo reale"). E i renderer come Cycles funzionano in modo completamente diverso rispetto ai renderer 3D nei motori di gioco - non puoi davvero confrontarli

— UnholySheep

@UnholySheep Naturalmente puoi confrontarli. In quale altro modo qualcuno potrebbe spiegare la differenza, per rispondere alla domanda?

— user985366,

@ 10 Risposte Ma questa domanda non sarebbe attuale su quel sito.

— GiantCowFilms

@ 10 Risposte: Mentre l'OP menziona Blender, la domanda si riduce essenzialmente al motivo per cui i motori di gioco in tempo reale sembrano rendere le scene 3D più veloci rispetto ai renderer 3D approssimativamente realistici (come Blender, ma anche molti altri). Nota che questa è anche la domanda a cui ha risposto la risposta accettata. Con questo in mente, sono d'accordo che la domanda è più in tema qui sullo sviluppo del gioco , dove si possono porre domande sulla tecnologia generale di sviluppo del gioco, piuttosto che su Blender , dove le domande sono più specifiche di Blender in particolare.

— OR Mapper

Immagino che il segreto qui sia che l' incredibile non debba essere preciso. Esistono approssimazioni rapide per la matematica utilizzata nel rendering 3D, come InvSqrt

— Dmitry Grigoryev

Risposte:

115

Il rendering in tempo reale, anche il rendering in tempo reale moderno, è un sacco di trucchi, scorciatoie, hack e approssimazioni.

Prendi le ombre per esempio.

Non abbiamo ancora un meccanismo completamente preciso e robusto per il rendering di ombre in tempo reale da un numero arbitrario di luci e oggetti arbitrariamente complessi. Abbiamo più varianti delle tecniche di mappatura delle ombre, ma tutte soffrono dei problemi ben noti con le mappe delle ombre e anche le "correzioni" per questi sono in realtà solo una raccolta di soluzioni e compromessi (come regola empirica se vedi i termini "bias di profondità" o "offset poligonale" in qualsiasi cosa, quindi non è una tecnica robusta).

Un altro esempio di una tecnica utilizzata dai renderer in tempo reale è il precalcolo. Se qualcosa (ad es. Illuminazione) è troppo lento per essere calcolato in tempo reale (e questo può dipendere dal sistema di illuminazione che usi), possiamo pre-calcolarlo e archiviarlo, quindi possiamo usare i dati pre-calcolati in tempo reale -tempo per un aumento delle prestazioni, che spesso viene a scapito di effetti dinamici. Questo è un semplice compromesso tra memoria e calcolo: la memoria è spesso economica e abbondante, il calcolo spesso non lo è, quindi bruciamo la memoria aggiuntiva in cambio di un risparmio sul calcolo.

I renderer offline e gli strumenti di modellazione, d'altra parte, tendono a concentrarsi maggiormente sulla correttezza e sulla qualità. Inoltre, poiché stanno lavorando con geometrie che cambiano in modo dinamico (come un modello mentre lo stai costruendo), devono spesso ricalcolare le cose, mentre un renderer in tempo reale funzionerebbe con una versione finale che non ha questo requisito.

— Maximus Minimus
fonte

Un altro punto da menzionare è che la quantità di calcolo utilizzata per generare tutti i dati di cui un gioco avrà bisogno per rendere rapidamente le viste di un'area può essere un ordine di grandezza maggiore della quantità di calcolo che sarebbe richiesta per il rendering di una vista. Se il rendering delle viste di un'area richiederebbe un secondo senza alcun calcolo preliminare, ma alcuni dati precalcolati potrebbero ridurlo a 1/100 di secondo, passare 20 minuti sui calcoli preliminari potrebbe essere utile se le viste saranno necessarie in un gioco in tempo reale, ma se uno vuole solo un film di dieci secondi a 24 fps, sarebbe stato molto più veloce passare quattro minuti ...

— supercat

... generando le 240 visualizzazioni richieste al ritmo di una al secondo.

— supercat

@supercat e per questo motivo i tuoi rendering sono praticamente privi di fretta e ottieni molto controllo sul processo. Potresti usare un motore di gioco per renderizzare ... se tu fossi pronto a sacrificare le funzionalità. Ma come hai detto non ne vale la pena.

— joojaa,

Un esempio lampante di ciò che ricordo è il motore originale di Quake (~ 1996), che è stato in grado di ottenere una grafica 3D in tempo reale relativamente strabiliante su macchine molto limitate utilizzando combinazioni di tecniche di pre-calcolo estremamente dispendiose in termini di tempo. Alberi BSP ed effetti di illuminazione pre-renderizzati sono stati generati in anticipo; la progettazione di un livello per quel motore in genere comportava ore (di solito durante la notte) in attesa del completamento degli strumenti di compilazione delle mappe. Il compromesso è stato essenzialmente ridotto i tempi di rendering a scapito del tempo di creazione.

— Jason C

(Il motore Doom originale [1993] aveva precalcoli simili. Anche la Maratona potrebbe avere, ma non ricordo, ricordo di aver costruito i livelli di Maratona ma non ricordo cosa fosse coinvolto.)

— Jason C

109

La risposta attuale ha fatto un ottimo lavoro nel spiegare le questioni generali coinvolte, ma ritengo che manchi un dettaglio tecnico importante: il motore di rendering "Cycles" di Blender è un tipo di motore diverso da quello utilizzato dalla maggior parte dei giochi.

In genere i giochi vengono riprodotti ripetendo tutti i poligoni in una scena e disegnandoli singolarmente. Questo viene fatto 'proiettando' le coordinate del poligono attraverso una videocamera virtuale per produrre un'immagine piatta. Il motivo per cui questa tecnica viene utilizzata per i giochi è che l'hardware moderno è progettato attorno a questa tecnica e può essere fatto in tempo reale con livelli di dettaglio relativamente elevati. Per interesse, questa è anche la tecnica utilizzata dal precedente motore di rendering di Blender prima che la Blender Foundation lasciò cadere il vecchio motore a favore del motore Cycles.

I cicli invece sono ciò che è noto come un motore di raytracing. Invece di guardare i poligoni e renderli individualmente, proietta raggi di luce virtuali nella scena (uno per ogni pixel nell'immagine finale), rimbalza quel raggio di luce su diverse superfici e quindi usa quei dati per decidere di che colore il pixel dovrebbe essere. Il raytracing è una tecnica molto computazionalmente costosa che lo rende poco pratico per il rendering in tempo reale, ma viene utilizzato per il rendering di immagini e video perché fornisce livelli extra di dettaglio e realismo.

Si prega di notare che le mie brevi descrizioni di raytracing e rendering poligonale sono altamente ridotte per brevità. Se desideri saperne di più sulle tecniche, ti consiglio di cercare un tutorial o un libro approfondito, poiché sospetto che ci siano moltissime persone che hanno scritto spiegazioni migliori di quelle che avrei potuto raccogliere.

Si noti inoltre che ci sono una varietà di tecniche coinvolte nel rendering 3D e alcuni giochi utilizzano effettivamente variazioni di raytracing per determinati scopi.

— Pharap
fonte

+1 per un ottimo punto; Non sono andato deliberatamente nella tana del coniglio di raytracing vs rasterizzazione, quindi è bello averlo come supplemento.

— Maximus Minimus,

Questa risposta arriva al centro della differenza. I motori di gioco eseguono la rasterizzazione (in avanti o differita) mentre i renderer offline (come Blender, Renderman, ecc.) Eseguono il ray-tracing. Due approcci completamente diversi al disegno di un'immagine.

— Il

@ LeComteduMerde-fou Dato che gamedev è rivolto agli sviluppatori di giochi, ho sentito che una spiegazione tecnica supplementare sarebbe di beneficio per il lettore più tecnicamente incline.

— Pharap,

@ssell Vero, ma non si tratta solo di ray tracing - anche senza ray tracing, anche con il rendering GPU, il rendering di Blender è di solito molto più dettagliato e più lento. Ciò ha a che fare principalmente con l'attenzione alla correttezza: migliore filtraggio e risoluzione delle trame, anti-aliasing, illuminazione, mappatura dell'ombra, precisione Z, quad, superfici bidirezionali, conteggi di poligoni di grandi dimensioni, output ad alta risoluzione, mappatura di precisione , mancanza di mappe precalcolate, morphing, cinematica accurata ... è un lungo elenco di funzionalità che mancano o fingono ai motori di gioco.

— Luaan,

@Chii ho fatto un errore. Stavo pensando a ART VPS , era solo un'accelerazione, non in tempo reale.

— Jason C