Trasformazione dei raggi in spazio oggetti per Motion Blur

12

Il mio raytracer supporta un'ampia varietà di oggetti. Per intersecarli, uso la tecnica standard di trasformazione dei raggi in spazio-oggetto. Funziona in modo fantastico fino a quando non aggiungo motion blur.

Ho modellato il motion blur come una sequenza di trasformazioni (per semplificare la discussione, diciamo esattamente due) invece di una. Il mio approccio è prendere la trasformazione inversa del raggio in entrambi i fotogrammi chiave e modificare le posizioni / direzioni.

Questo sembra funzionare bene per le traduzioni, ma si rompe per le rotazioni. Ad esempio qui ci sono due triangoli sottoposti a rotazioni di 30 e 90 gradi:

^{(4 campioni, ricostruzione MN, i campioni rossi sono arrivati vicino ai due fotogrammi chiave)}

Agli angoli, mi aspetto che i campioni deformati si trovino su una linea retta tra i due vertici. Invece, si gonfiano verso l'esterno. Questo è sbagliato. In scene più interessanti con trasformazioni più interessanti, provoca una varietà di modalità di fallimento. Ad esempio, ecco un'elica che subisce una rotazione di 45:

^{(100 campioni, normali visualizzati)}

Alcuni problemi sono dovuti alla rottura del BVH (presuppone che gli estremi degli oggetti si trovino sui fotogrammi chiave), ma anche un rendering con forza bruta non è corretto.

Posso risolvere tutto ciò facendo solo trasformazioni in avanti (trasforma oggetto, non il raggio), ma funziona solo per oggetti dove è possibile (solo triangoli, davvero).

Come posso fare in modo che il mio raytracer produca approssimazioni lineari alla trasformazione (in particolare la rotazione) trasformando i raggi, non gli oggetti?

raytracing transformations motion

— imallett
fonte

7

Lerpare le posizioni / direzioni dei raggi tra i fotogrammi chiave dovrebbe equivalere a lerpare le matrici inverse tra i fotogrammi chiave e trasformarle con la matrice lerpata. Il problema è che, se i fotogrammi chiave hanno rotazioni diverse, quella matrice lerped sarà in generale qualcosa di "strano", con taglio, scala non uniforme, ecc.

Non sarei sorpreso se alcune delle tue routine di intersezione e ombreggiatura non funzionassero correttamente in un sistema di coordinate così distorto, a meno che tu non le abbia specificamente testate e indurite contro tali casi. (Ad esempio, prendere il prodotto punto di due vettori di unità non fornisce la stessa risposta in un sistema di coordinate tranciato come in un sistema ortonormale.)

Questa è solo un'ipotesi, ma potrebbe funzionare meglio se si sceglie un metodo di interpolazione in cui la traduzione, la rotazione e la scala (se applicabile) vengono lerpate separatamente (usando i quaternioni per la parte di rotazione) e ricombinate.

— Nathan Reed
fonte

Sei sicuro che lerping l'oggetto trasformato in avanti equivale a lerping il raggio trasformato all'indietro? Ad esempio, posso rinormalizzare il raggio dopo il lerp (e ridimensionare la distanza del colpo di conseguenza). Questo non cambia il risultato.

— imallett,

@imallett Lerping il raggio dovrebbe equivalere a lerping le matrici inverse, ma non necessariamente a lerping delle matrici forward o lerping l'oggetto (poiché l'inversione non è un'operazione lineare). E non penso di rinormalizzare il raggio dopo che il lerp ha risolto del tutto le cose - puoi ancora essere in un sistema di coordinate tranciato, non uniformemente scalato che può rovinare la matematica nelle tue routine di intersezione e simili.

— Nathan Reed,

[Vedi modifica; immagine migliore] Almeno, penso che la rinormalizzazione dovrebbe escludere problemi con l'intersezione - ma è quello che ho pensato; lerping il raggio non è lerping l'oggetto. Nella tua risposta hai suggerito di ripetere TRS [inverso?] E di ricombinarlo. È così che lo fanno i renderer di produzione?

— imallett,

3

Non credo che tu possa andare terribilmente lontano con AFAICS, una singola approssimazione lineare a un'interpolazione piuttosto non lineare, ma forse questo documento / presentazione di Gribel et al. Sul mosso nella rasterizzazione può aiutare.

— Simon F.
fonte

Lo scompongo in un'approssimazione lineare, che è abbastanza tipica. È possibile gestire trasformazioni più complesse con più passaggi di questo tipo. Il mio problema non è nel rendere la trasformazione non lineare, ma nel correggere l'approssimazione lineare ad essa.

— imallett,