Bonjour a tous,
je suis en train de matter la documentation d´un moteur 3D et y a une instruction qui retourne la matrice courrente de la camera, mais je ne comprend pas ce que c´est...
est ce que cela me donnerai les positions actuels de la camera?
Merci par avance...
Bob

" retourne" ? . .. c´est pas une opération mathématique ça... inverse, transpose, ou autre, mais " retourne" je vois pas...

p-e s´agit-il d´un " retournement" par rapport à un plan, c´est ce qu´on utilise pour faire les reflets ( pour un mirroir, on calcule la position de la caméra par rapport au plan du mirroir, on rend la scène depuis cette position dans une texture, et on plaque la texture sur le mirroir : depuis la vraie position de la caméra, on voit bien l´image refléchie).

Si tu explicites un peu le contexte ( détails des calculs sur la matrice, ou utilisation supposée), on pourra en dire plus...

tant qu´à etre parti sur les reflets, si on n´a qu´une scene statique, autant utiliser un env-map avec éventuellement un vertex shader, ça évitera deux rendus...

c´est je me suis mal exprimé, l´instruction retourne la valeur de la matrice ! !!
il n´y a pas de contexte j´ai lu ca dans la doc fournit avec le moteur que j´utilise ! !!

file ta doc a LGV il pourras t´aider comme ca

http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1ICameraSceneNode.html

voila l´adresse la ou il y a la fonction dont je te parle, tu n´as qu´a regarder... en fait je cherche une fonction qui retourne la position courante de la camera celon l´axe x, y et z...
si tu pouvais m´aider ca serait symap...

Ce qu´on appelle en OpenGL la matrice MATRIX_VIEW ( je pense que c´est de cette matrice que parle ton instruction) défini en effet la position précise de ta caméra.

C´est une matrice de transformation : elle se défini avec des vecteurs 4d ( coordonnées homogenes pour espace affine)

Tu as, nativement, un repere ( O,i,j,k)
La matrice contient les images de ces 3 vecteurs et de ce point par rapport au repere global.

Les coordonnées homogenes définissent qu´un point est de la forme :
( x,y,z,1)
et un vecteur :
( x,y,z,0)

ta matrice s´écrit exactement :

| xi xj xk xO |
| yi yj yk yO |
| zi zj zk zO |
| 0 0 0 1 |

Cela dit, les moteurs 3D comme OpenGL ou DirectX t´épargnent de connaitre exactement cela : c´est pour ta culture personnelle

moui... c´est bizarre qu´il n´y ait pas de getter sur la position...
Enfin tu dois pouvoir la récupérer à partir de la view matrix : les coeffs. M03 M13 et M23 ( avec Mij coeff ligne i colonne j) correspondent à la translation de l´objet caméra, autrement dit sa position, ce que tu veux donc.

( note que la matrice peut etre transposée, selon la convention adoptée par les sources que tu exploites, ce pourra donc etre les coefs M30, M31 et M32)

LOL, avec JY² on vient de te faire la version stéréo ; )

ok je vais regarder ca merci pour votre aide ! !!

dans le moteur, c´est la matrice de projection non?

On gère 3 matrices dans un scène 3D : la matrice de positionnement ( pour les objets), elle ne concerne pas la caméra. La matrice de vue ( celle dont on parle plus haut), qui est justement la position et l´orientation de la caméra. Et enfin la matrice de projection ( qui explicite la transformation permettant de passer du 3D au plan 2D de l´écran ; en gros c´est juste une projection selon une pyramide tronquée).
Pour la caméra, t´as dons 2 matrices à considérer : matrice de vue ( position/orientation) et matrice de projection ( angle de vision, near et far plane, etc.). Celle de projection, tu la fixes une fois pour toute en général elle varie pas. C´est dont dans la matrice de vue que tu dois récupérer les coefs de la dernières colonne xO, y0 et z0 dans le post à JY².

ok encore merci pour ton aide ! !!

olala comment ça à l´air compliqué ^^

lol

encore une fois, je le répete :
" Cela dit, les moteurs 3D comme OpenGL ou DirectX t´épargnent de connaitre exactement cela : c´est pour ta culture personnelle"

Ce genre de connaissance est nécessaire pour le mec qui veut reprogrammer un moteur 3D ! !

ça peut aider Cyber_Bob a la rigueur, mais les moteurs 3D ( de base comme OpenGL directX, ou évolués comme Irrlish) doivent normalement te permettre d´y manipuler sans connaitre a ce point le coté technique.

ben... je ne suis pas tout à fait sur le " avec un moteur 3D on a pas à connaitre ça".
Déjà, openGL et DirectX ne sont pas des moteurs, mais seulement des APIs ( par exemple, aucune notion de graphe de scène, ni dans l´un ni dans l´autre). Le " moteur" reste donc à réaliser
Ensuite, dès qu´on veut faire des choses un tout petit peu évoluées, les matrices sont essentielles à maitriser : ne serait-ce que pour du frustum clipping, comment faire si on ne sait pas à quoi correspondent les coefs d´une matrice homogène de R3..

Par contre je suis d´accord qu´un moteur évolué ( je ne connais pas Irrlish cela dit) devrait au moins fournir le minimum pour manipuler sa caméra correctement ( getters qu´ils faut, + considération comme un objet animable selon un path défini par points de controle par ex.)

Oui, c´est vrai Ce que je voulais dire, c´est que pour l´utilisation de base, tu peux t´en passer
Mais tu as raison : quand on veut optimiser un peu, ou faire des trucs + puissants, il est bon de connaitre le détail

Un moteur 3D aussi est une API...

Ca depend à quel niveau d´abstraction on se place, mais openGl est un moteur 3D, certes primitif, mais un moteur 3D quand même.

C´est un peu comme l´asm et le Java pour les langages de programmation...

voilà autre chose...
Les gens ont tendances à amalgamer tout ce qui est framework/api/engine/libs.

OpenGL est tout sauf un moteur 3D ; c´est une API, elle fournit des fonctions d´abstraction et propose des fonctionnalités.
Un moteur 3D est qqch qui gère des concepts de haut niveau : notion de scène, de graphe associé, d´objet, etc. Rien de tout ça dans openGL, donc ce n´est PAS un moteur...
Tout comme une API n´est pas juste une collection de libs, et tout comme un moteur n´est pas un framework...

et tant qu´à y être, évitons de mêler ASM et Java, bytecode et Java ou ASM et C/C++ si on veut, mais là encore la comparaison ne tient pas.
En ASM on fait autant qu´en C++, avec les memes concepts/notions si on le souhaite, c´est simplement beaucoup plus long/chiant. C´est une facilité que d´écrire dans un langage de haut niveau, mais les possibilités sont les memes ( il suffit de faire générer les . asm au lieu des . o pour s´en convaincre).