Transformation des rayons en espace objet pour le flou de mouvement

12

Mon raytracer prend en charge une grande variété d'objets. Pour les recouper, j'utilise la technique standard de transformation des rayons en espace objet. Cela fonctionne à merveille jusqu'à ce que j'ajoute du flou de mouvement.

Je modélise le flou de mouvement comme une séquence de transformations (pour simplifier la discussion, disons exactement deux) au lieu d'une. Mon approche consiste à prendre la transformée inverse du rayon aux deux images clés et à lire les positions / directions.

Cela semble bien fonctionner pour les traductions, mais il se décompose pour les rotations. Par exemple, voici deux triangles subissant des rotations de 30 et 90 degrés:

^{(4 échantillons, reconstruction MN, les échantillons rouges provenaient de près des deux images clés)}

Aux coins, je m'attendrais à ce que les échantillons lerpés se trouvent sur une ligne droite entre les deux sommets. Au lieu de cela, ils se gonflent vers l'extérieur. C'est faux. Dans des scènes plus intéressantes avec des transformations plus intéressantes, cela provoque une variété de modes de défaillance. Par exemple, voici une hélice subissant une rotation de 45:

^{(100 échantillons, normales visualisées)}

Certains problèmes sont dus à la rupture BVH (cela suppose que les extrema des objets se trouvent au niveau des images clés), mais même un rendu en force brute est incorrect.

Je peux résoudre tout cela en faisant des transformations directes uniquement (objet de transformation, pas le rayon), mais cela ne fonctionne que pour les objets où cela est possible (uniquement les triangles, vraiment).

Comment puis-je faire en sorte que mon raytracer produise des approximations linéaires de la transformation (en particulier la rotation) en transformant les rayons, pas les objets?

raytracing transformations motion

— imallett
source

7

Le fait de lerper les positions / directions des rayons entre les images clés doit être équivalent à lerper les matrices inverses entre les images clés et à les transformer par la matrice lerpée. Le problème est que si les images clés ont des rotations différentes, cette matrice lerpée sera en général quelque chose de "bizarre", avec cisaillement, échelle non uniforme, etc.

Je ne serais pas surpris si certaines de vos routines d'intersection et d'ombrage ne fonctionnent pas correctement dans un système de coordonnées aussi déformé, à moins que vous ne les ayez spécifiquement testés et renforcés contre de tels cas. (Par exemple, prendre le produit scalaire de deux vecteurs unitaires ne donne pas la même réponse dans un système de coordonnées cisaillé que dans un système orthonormé.)

C'est juste une supposition, mais cela pourrait mieux fonctionner si vous choisissez une méthode d'interpolation où la translation, la rotation et l'échelle (le cas échéant) sont lerpées séparément (en utilisant des quaternions pour la partie rotation) et re-combinées.

— Nathan Reed
source

Êtes-vous sûr que le lerping de l'objet transformé en avant est le même que le lerping du rayon transformé en arrière? Par exemple, je peux renormaliser le rayon après le lerp (et mettre à l'échelle la distance de frappe en conséquence). Cela ne change pas le résultat.

— imallett

@imallett Lerping le rayon devrait être équivalent à lerping les matrices inverses, mais pas nécessairement à lerping les matrices directes ou lerping l'objet (car l'inversion n'est pas une opération linéaire). Et je ne pense pas que la renormalisation du rayon après que le lerp corrige complètement les choses - vous pouvez toujours être dans un système de coordonnées cisaillé, à l'échelle non uniforme qui peut bousiller les mathématiques dans vos routines d'intersection et autres.

— Nathan Reed

[Voir éditer; meilleure image] Au moins, je pense que la renormalisation devrait exclure les problèmes avec l'intersection - mais c'est ce que je pensais; lerping le rayon n'est pas lerping l'objet. Dans votre réponse, vous avez suggéré de lerper [inverse?] TRS puis de recombiner. Est-ce ainsi que les rendus de production le font?

— imallett

3

AFAICS, je ne pense pas que vous irez vraiment loin, une simple approximation linéaire d'une interpolation plutôt non linéaire, mais peut-être cet article / présentation de Gribel et al sur le flou de mouvement dans la rastérisation peut aider.

— Simon F
source

Je le décompose en une approximation linéaire, ce qui est assez typique. On peut gérer des transformations plus complexes avec plusieurs de ces étapes. Mon problème n'est pas de rendre la transformation non linéaire, mais de corriger son approximation linéaire.

— imallett