ScratchAPixel : Quelqu'un a-t-il déjà implémenté leur projection perspective ?

Le problème exposé dans ce sujet a été résolu.

De retour JuDePom !

$$ \begin{bmatrix} 300 & 150 & 0 & 0 \\ 150 & 300 & 0 && 0 \\ 125 & 125 & -150 && 0 \\ 150 & 150 & 0 & 1 \end{bmatrix} $$

Effectivement tu avais bien vu le truc, 1 Seq = 1 ligne.

Ma matrice se lit comme sur cet exemple (cf. ScratchAPixel) :

Image utilisateur
Image utilisateur

Donc logiquement, ma matrice place la caméra au centre du cube, avec l’axe Z orienté vers le cube perpendiculairement aux faces avant et arrière de ce dernier, et les axes X et Y parallèles aux arrêtes haute/basse des faces avant et arrière.

Rappel :

Le cube est :

1
2
3
4
5
6
7
8
          Seq(0, 300, 0),
          Seq(0, 300, -300),
          Seq(0, 0, 0),
          Seq(0, 0, -300),
          Seq(300, 300, 0),
          Seq(300, 300, -300),
          Seq(300, 0, 0),
          Seq(300, 0, -300)

La matrice est :

1
2
3
4
          Seq(300, 150, 0, 0),
          Seq(150, 300, 0, 0),
          Seq(125, 125, -150, 0),
          Seq(150, 150, 0, 1)

Pour vous montrer que je suis bien déterminé à comprendre pourquoi ça ne fonctionne pas :pirate: , j’ai fait ce graphique qui résume ce qui ne va pas et comment une matrice de transformation modifie la position des points d’un repère à un autre.

Je rappelle que je suis sûr à 100% que ma projection perspective et la partie rasterization marchent à 100%. C’est vraiment juste la matrice de transformation que j’ai choisie qui pose souci.

Edit : c’est encore une nouvelle matrice de transformation que j’utilise désormais (cf. le graphique ci-dessous).

Image utilisateur
+0 -0

En fait c’est bon ça marchait depuis le début, genre avec cette matrice de transformation :

1
2
3
4
          Seq(1, 0, 0, 0),
          Seq(0, 1, 0, 0),
          Seq(0, 0, 1, 0),
          Seq(1, 1, -400, 1)

Par contre si avant ça ne marchait pas, c’était dû au fait que j’avais oublié que le cube devait être centré sur l’origine du repère du monde .....................................................

A la place, je l’avais défini de cette façon : "coin bas gauche du cube de profondeur la plus proche = origine du monde"....... :'(

Du coup avec ce cube d’arête = 300 :

1
2
3
4
5
6
7
8
9
          Seq(-150, 150, -150),
          Seq(-150, 150, 150),
          Seq(150, 150, -150),
          Seq(150, 150, 150),

          Seq(-150, -150, -150),
          Seq(-150, -150, 150),
          Seq(150, -150, -150),
          Seq(150, -150, 150)

Cela donne :

Image utilisateur

Par contre je n’exclue pas de retourner vers vous pour des questions plus théoriques sur cette façon de projeter perspectivement des points !

Cool :)

Par contre, je n’ai pas l’habitude (en fait, jamais) de voir les matrices de transformations dans le sens que tu les écris. Généralement, lorsque l’on est amené à faire des calculs les vecteurs sont (dans les cours que j’ai eut et les différents articles que j’ai lu) représentés verticalement, et on obtient des choses du genre:

$$ [ \begin{bmatrix} 1 & 0 & 0 & dx \\ 0 & 1 & 0 & dy \\ 0 & 0 & 1 & dz \\ 0 & 0 & 0 & 1 \end{bmatrix} * \begin{bmatrix} x \\ y \\ z \\ 0 \end{bmatrix} ] $$

Je ne savais pas du tout s’il s’agissait d’une convention, j’ai demandé à deux collègues qui font ça depuis bien plus longtemps que moi, et ils m’ont répondu qu’en tout cas, eux faisaient comme ça, et que (au moins en computer graphics), c’était la représentation préférée.

Je me suis donc demandé pourquoi tu les représentait en lignes, et pas en colonnes. Et j’ai eut la réponse, c’est "à cause" de Scratchapixel pour toi et les lignes, et des maths pour moi et les colonnes :p ):

So you may think, "there must be a reason to prefer one system to another". In fact, both conventions are correct and give us the same result, but for some technical reasons, Maths and Physics texts generally treat vectors as column vectors.

Order of transformation when we use colum-major matrices is more similar in mathematics to the way we write function evaluation and composition.

The row-major matrix convention however makes matrices easier to teach which is the reason we use it for Scratchapixel (as well as Maya, DirectX. They are also defined as the standard in the RenderMan specifications). However some 3D APIs such as OpenGL, use a column-major convention.

row-major-vs-column-major-vector

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte