Je galère depuis plus de 2 jours la dessus... merci de m'aider !
 
En fait, il me faudrait juste une chtite fonction ...
 
Un truc qui doit etre couru en +, mais j'ai rien trouvé.
 
Il me faudrait une fonction qui prenne en compte la position actuelle de la caméra (donc x , y , z ) , son futur changement(via deltaX, DeltaY, DeltaAngle) , et qui fasse le changement de plan...
 
Donc comme OpenGL n'a pas de caméra, il me faudrait une fonction qui calcule la transformation inverse ds objets...
 
En gros, on fait reculer les objets pour avoir l'illusion qu'elle avance...
 
Bref, en fait, juste 3 fonctions mathématiques calculant la nouvelle position de la cam. via un delta X, Y et angle de vue  me seraient utiles ...
 
Merci d'avance ! (je préfèrerais le code qd mm )
 
PS : avancer reculer une caméra j'y arrive sans probs via une trasnlation inverse du reste... idem gauche/droite.
 
Mais calculer la nouvelle position de la caméra alors que l'on a regardé a 30° vers le haut et qu'on a avancé ben... dur dur dur

[edtdd]--Message édité par Tetedeiench--[/edtdd]

ben tu maintiens la position de ta caméra dans une matrice, pi tu parts de l'inverse de cette matrice ? (houla si je dis des conneries fo m'excuser fatiguey)
 
matrix cam, cam_i
 
cam_1 <- inverse cam  
 
glpush cam_1
 
glpush matrix_obj1
  traçage obj1
glpop
 
glpush cam_2
  traçage obj2
glpop
 
je serais étonné qu'il y est po d'approche comme ça ? (ou la matrice inverse à la fin)

[edtdd]--Message édité par bjone--[/edtdd]

ouaip, j'y ai pensé (C équivalent a faire les transformations a la main).
 
En fait, ce qui m'ennuie C de calculer les positions de la camera dans l'espace...
 
Mais je crois que j'ai eu une idée en utilisant un peu + les rotations ...
 
je m'explique.
 
le gars avance/recule va a gauche / droite : la C tout con, on calcule x et z et on update les positions mémorisées de la caméra, on fait une translation de -x et -z
 
le gars tourne sa caméra a gauche/droite , avance/recule : on update L'ANGLE passé en paramètre, représentant son écart par rapport au Z d'origine, et on calcule les positions avec sinus/cosinus (ca doit marcher a peu pres bieng).
 
Apres il suffit d'y placer la caméra et de  faire une rotation de cet angle.
 
le gars grimpe la caméra vers le haut ou le bas => On update l'angle formé avec l'axe X/Y  d'origine, en gros l'angle avec lequel il regarde  en haut.
 
On regarde de combien il avance, on calcule d'abord l'écart Z et Y que cela implique sans qu'il aie bougé (de toute facon cai la même chose sans prendre en compte l'angle latéral) on applique, on translate la caméra et on remets l'angle ou il était.
 
enfin, quand je dis translater la caméra je me comprends : j'induis "translater les objets inversement".
 
Et finalement C plutot bête a faire car il me suffira de remettre après chaque LoadIdentity un translatef et un rotatef et zouuuuu, elle est bonne
 
je teste ce soir en étant rentré de la facc
 
Ce qui est bizarre C que je me suis endormi, et que je me suis reveillé avec cette solution...
 
J'ai bossé en dormant ou quoi
 

 
Verra si ca marche

C'est parce que tu t'y prends mal:
il ne faut pas calculer la position de la camera
de maniere incrementale
mais il faut conserver dans un coin les parametres
globaux de ta camera (position absolue, rotation par rapport au monde)
Donc calculer la nouvelle matrice de projection + view
n'est pas plus difficile apres zero mouvement qu'apres
mille mouvements.
 
LEGREG

en parlant de ça, quelqu'un aurait une formule de "réparation" de matrice de rotation, pour compenser les erreurs de calcul successives sur les martices de rotations qu'on modifie à chaque VBL, histoire que ça reste une vraie matrice de rotation qui ne déforme pas l'objet?

 
ca arrive a force de faire des rotations successives non ?
me semble (pas sur de mon coup, qu'on me dise si je dis n'imp...) que le plus simple, c'est de convertir en quaternion, normaliser le quaternion et reconvertir en matrice

mouai le quaternion je le vois bien pour gerer
des trucs compliques comme simulateur de vol/espace
(ou tu es potentiellement dans toutes les orientations possibles)
ou alors des mouvements de camera complexes et fluides.
 
Par contre pour un quake like, les angles d'euler
ca marche tres bien => d'ou la matrice
et du meme coup ca te resoud les problemes d'approximations successives. (dans un quake like pas trop complique
tu n'as meme besoin que de memoriser deux angles.)
 
A+
LEGREG

Bon si t'avais programme sous DirectX  
j'aurais pas dit
parce que tu as les fonctions pour
calculer les quaternions (angles->quaternion, quaternion->matrice) dans la librairie standard..
 
Sous OpenGL, faudra trouver des sources ou faire
les calculs toi meme.
 
A+
LEGREG

 
vi je sais, mais dans l'idee c'etait que visiblement il faisait des transfo successives . Au bout d'un moment ta matrice part un peu en couille fo la reorthogonaliser . C un truc relou, qui est bpc plus facile a faire avec les quaternions, me semble t-il

ca n'a rien a voir.
 
tu composes ta matrice a partir
des nouveaux angles, tu remplaces
la matrice view existante: pas (trop) d'approximation,
cad elle est aussi propre que si tu etais
passee par les quaternions.
 
Par contre les quaternions peuvent t'aider a eviter
les fameux "gimbal locks" quand tu veux etre dans n'importe
quelle orientation possible: tu peux continuer a travailler
avec les angles d'euler mais uniquement dans ton repere local.
et il permettent egalement d'interpoler
naturellement entre entre deux rotations  
ce que les angles d'Euler ne permettent pas.
(tu ne peux pas non plus interpoler lineairement les
matrices..)
 
A+
LEGREG

 
Nan ce que je pensais (scrogneugneu ), c'est qu'il ne creait pas une nouvelle matrice a chaque frame, mais qu'il utilisait la matrice de la precedente frame qu'il ajustait avec les nouvelles input de l'utilisateurs => imprecision au bout d'un moment
 
Sinon pour le reste je suis bien d'acc avec toi

[edtdd]--Message édité par chrisbk--[/edtdd]

c'est exactement ce que je pensais. Sur la playstation y'a des librairies qui font ça très bien, mais je cherche le code pour faire la même chose sur PC.

 
hum a partir d'une matrice 3x3 quelconque revenir
a une matrice orthonormee?
un truc facile a comprendre et a implanter:
tu consideres chaque colonne de ta matrice
comme les coordonnees d'une base quelconque et tu orthonormalises
cette base:  
prends le premier vecteur, tu le divises par sa norme, c'est v'1.
tu prends le deuxieme vecteur, tu prends la partie orthogonale
a ton premier vecteur (v2 - (v'1.v2)*v'1 ), et tu divises le resultat par sa norme => v'2
Troisieme vecteur => meme processus mais avec les deux precedents
vecteurs => v'3
(v'1, v'2, v'3) est donc par construction une nouvelle
base orthonormee.
 
c'est peut-etre pas la meilleure solution
de toute facon ca reste une approximation d'approximations.
 
A+
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]

Ok merci!

J'ai un probleme quand meme ...
 
Voila ce que j'ai pondu : (je prends en compte que horizontalement dans un premier temps)
 

 
X,Y et Z sont les positions de ma caméra.
 
Delta le déplacement a prendre en compte.
 
Deltahori = Angle formé horizontalement avec l'axe Z.
 
DeltaVert = Angle formé verticalement avec l'axe Y.
 
Sur le plan maths, ca se tiens a l'aise.
 
je pense avoir pondu un truc plutot correct (a des signes pres, bon, ca rends des choses inverses au pire des cas).
 
Sauf que la... C pas trop le cas.
 
le blem viens de cos ou sinus...
 
Si l'angle = 0.0f no problem.
 
Si il augmente un peu, ma sphère de référence translate de 45° de gauche a droite en avancant (en diagonale style carré donc, alors que ca ne devrait pas etre le cas).
 
Je tourne encore un peu, cette fois ci elle va horizontalement.
 
je retourne encore un peu, ca deviens carrément du délire, elle reviens parrallèle a moi en avancant / reculant...
 
Evidemment entre les deux je tombe sur des angles bizarre... que je ne capte décidément pas.
 
J'ai merdé ou la pour avoir un comportement aussi étrange ?
 
m'est avis que ca viens du sinus/cos, pourtant, voula ce que j'ai fait comme gestion d'évènement :

Cai ou que j'ai merdouillé ?
 
Je fais bien un GLloadIdentity avant d'appeler les deux fonctions dans mon loop...

[edtdd]--Message édité par Tetedeiench--[/edtdd]

En fait...
 
J'(ai l'impression qu'il me fait un cos-1 (vous savez, la fonction inverse du cosinus) au lieu d'un cosinus classique...
 
car ca change de signe tres souvent ...
 
En gros, des que l'angle dépasse une unité...
 
Style cos(1.5f) > 0 et cos (2.5f) < 0 ...
 
J'ai tout oublié de mes maths ou je me suis planté grave ?

Putain j'ai trouvé grace a ma calculette...
 
le cos de math.h C des radians les enculés
 
rah les salauds
 
Du coup ca change tout

Tetedeiench a écrit a écrit : Putain j'ai trouvé grace a ma calculette...   le cos de math.h C des radians les enculés   rah les salauds   Du coup ca change tout

 
 

 
ttes les fonction trigo sont en radian . c bon a savoir hein ?

non , pour les degres y'a cosd , sind ...
parceque   double cos(double angl_en _radian);
           double cosd(double angle_e _deg);
           float cosdf(float angle_e _deg);

ou sont elles definies tes fonctions
cosd et cosdf?
ca ne m'a pas l'air d'etre tres standard.
 
LEGREG

tapes man cos
 et tu verra , elle sont definies avec cos , sin et  tan .
c vrai qu'on ne peux pas avoir leman directement.
je ne les ai pas testé sous win, mais seulement sous unix

mouai c'est ca le pb
si elles ne sont definies que sous unix..
y'a pas une note sur AnsiC dans ton man?
 
(dans la doc MSDN y'a toujours un petit <compatibility notes>
ou <microsoft specific>, comme ca pas d'embrouilles.)
 
A+
LEGREG

il ne disent rien de + dans le man .
généralement , quand ils ne precisent rien , c'est que c'est dans la norme ansiC , mais je ne peux rien affirmer
si quelqu'un a un PC sous win , ce serait sympa qu'il regarde .
au pire ,je regarderai chez moi ce soir ( sous borland par exemple )

cosd visu connais pas

tant pis
desolé, je croyais que c'était standard

c'est pas grave on peut les refaire facilement des fonctions comme ça.
 
float cosd(float x)
{
   return(cos(x*PI/180.0f));
}
 
enfin PI s'appelle peut-être pas comme ça, je me souviens plus.

c'est M_PI dabs la norme ansi je crois , mais PI marche dans l'immense pajorité des cas