Référence image pour la question:
(image du tutoriel CG )
L'API D3D9 nous a habitués aux mondes matriciels .
Cependant, si vous utilisez des matrices universelles, vous devez alors multiplier une matrice supplémentaire dans le shader (ce qui finit par être le même pour beaucoup de sommets).
D'où la convention OpenGL de concaténation des matrices de modélisation et de visualisation en une seule matrice (GL_MODELVIEWMATRIX = View * World).
Quoi de mieux et pourquoi?
Non. À aucun moment, vous ne devriez avoir une matrice du monde explicite dans votre shader.
Une explication détaillée de pourquoi peut être trouvée ici , mais la version courte est vraiment très simple: vous n'en avez jamais besoin et cela peut tuer votre précision en virgule flottante.
Si votre espace mondial est trop grand, une caméra éloignée de l'origine peut entraîner des problèmes de précision en virgule flottante.
Tout l'espace du monde n'est rien d'autre qu'un intermédiaire entre l'espace modèle et l'espace caméra. C'est un endroit où vous pouvez exprimer la caméra et tous les autres objets dans le même espace. Mais tout ce que vous l'utilisez est de générer une matrice monde-caméra, que vous appliquez ensuite à toutes les matrices modèle-monde pour créer des matrices modèle-caméra.
Vous pouvez traiter les problèmes de précision en C ++ en utilisant des doubles au lieu de flottants pour les calculs matriciels. Vous pouvez les reconvertir en flottants avant de les télécharger dans le shader.
Alors pourquoi auriez-vous besoin d' une transformation explicite de l'espace-monde dans votre shader? Dans votre code source, oui. Mais dans ton shader? Que feriez-vous avec cela que vous ne pouvez pas faire avec l'espace de la caméra?
L'éclairage peut être fait dans l'espace de la caméra aussi facilement que dans l'espace mondial; tout ce que vous avez à faire est de transformer vos positions / directions d'éclairage en espace de caméra. Après tout, l'espace de la caméra a la même échelle que l'espace du monde. Vous effectuez cette transformation une fois par image par lumière; à peine un fardeau de performance, même sur le CPU.
Il est donc absolument inutile d'exposer vos shaders à une transformation explicite de l' espace mondial. C'est juste une étape intermédiaire que vous pliez dans vos matrices.
Vous ne feriez pas multiplier la matrice supplémentaire dans votre shader. L'astuce est que vous effectuez votre multiplication matricielle une fois par image sur le processeur, puis téléchargez le résultat final sur votre vertex shader. Cela vous donne une position par multiplication matricielle par sommet, que vous ayez un monde ou une vue séparée ou concaténée.
Dans de nombreux cas, vous souhaitez de toute façon que le monde se positionne dans le vertex shader, à d'autres fins. Par exemple, vous devez calculer le vecteur de vue, pour passer dans le pixel shader pour évaluer spéculaire.
La matrice local vers monde est également nécessaire pour transformer les vecteurs tangents et les vecteurs normaux [1] en espace mondial pour l'ombrage, en supposant que vous effectuez l'ombrage dans l'espace mondial (vous pouvez le faire dans l'espace tangent, auquel cas vous auriez besoin un ensemble différent de matrices).
Donc, l'OMI, il est logique d'avoir deux matrices: local-à-monde et monde-à-clip. Cette dernière est le produit de la matrice de vue et de la matrice de projection. Passez les deux au vertex shader et faites les multiplications comme:
posWorld = mul(posLocal, matLocalToWorld)
posClip = mul(posWorld, matWorldToClip)[1] (Tant que vous n'avez pas de mise à l'échelle non uniforme. Dans ce cas, les normales doivent être transformées par la transposition inverse de la matrice local-mondial.)