| |||||
| Dernière réponse | |
|---|---|
| Sujet : [OpenGL/C++] Gestion de caméra | |
| flo850 | c'est M_PI dabs la norme ansi je crois , mais PI marche dans l'immense pajorité des cas |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| flo850 | c'est M_PI dabs la norme ansi je crois , mais PI marche dans l'immense pajorité des cas |
| wave | 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. |
| flo850 | tant pis :cry:
desolé, je croyais que c'était standard |
| chrisbk | cosd visu connais pas |
| flo850 | 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 ) |
| LeGreg | 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 |
| flo850 | 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 |
| LeGreg | ou sont elles definies tes fonctions
cosd et cosdf? ca ne m'a pas l'air d'etre tres standard. LEGREG |
| flo850 | 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); |
| chrisbk |
|
| Tetedeiench | Putain j'ai trouvé grace a ma calculette...
le cos de math.h C des radians les enculés :D rah les salauds :D Du coup ca change tout :D |
| Tetedeiench | 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 ? |
| Tetedeiench | J'ai un probleme quand meme ...
Voila ce que j'ai pondu : (je prends en compte que horizontalement dans un premier temps)
[edtdd]--Message édité par Tetedeiench--[/edtdd] |
| wave | Ok merci! |
| LeGreg |
[edtdd]--Message édité par legreg--[/edtdd] |
| wave | 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. |
| chrisbk |
[edtdd]--Message édité par chrisbk--[/edtdd] |
| LeGreg | 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 |
| chrisbk |
|
| 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 |
| LeGreg |
|
| chrisbk |
|
| wave | 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? |
| LeGreg | 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 |
| Tetedeiench | 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 :hot: 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 :??: :D Verra si ca marche :) |
| bjone | 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] |
| Tetedeiench | 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] |




