Reprise du message précédent : EDIT: je met mes questions au fur à mesure que je progresse...
Citation :
Avec ce que tu as comme coordonnées pour la source lumineuse (0, 70, -70, 0), elle se trouve à l'infini. Donc tu ne pourras jamais placer un objet parfaitement au bon endroit.
Tu dois pouvoir essayer de placer une sphère à coup de translation dans la direction (0, 70, -70) à une distance assez grande pour être loin de la scène mais quand même dans la zone de tracé.
Par contre, pour la positionner correctement, il faut faire attention au fait qu'il y a DEUX piles de matrices dans OpenGL. Si ma mémoire est bonne (je me fais sans arrêt avoir avec ce genre de choses, j'ai des bouts de codes pour ne pas me tromper ), la lumière n'est affectée que par l'une des deux contrairement à la scène qui est affectée par les deux. Du coup, ça peut être un peu délicat à gérer...
1)Cela veut donc dire qu'avec une lumiere ponctuelle il m'est impossible de la placer sur la scene car elle est ponctuelle?Une lumiere directionelle peut-elle etre placer sur scene?J'ai vu un groupe qui avait réussi à emprisonner (ou du moins simuler)une lumiere dans une sphere (ce que je tente de faire égaelment!!!)
2) en plaçant la lumière à une distance visible sur mon plan,il serait donc possible de controler la lumiere?Car sinon je vais tenter de placer la lumiere dans la scène !
3)Sinon si je met la sphere à la même position que la lumiere étant positionné à l'infini comme peut-elle etre visible?
4)Je peux manipuler la lumiere ponctuelle via les touches du clavier grace à la rotation or il se déroule un phenomene bizarre quand l'avant de mes billes sont éclariés mais pas le mur ! alors que quand le mur est éclairé,les billes non..Je sais pas si c'est clair je vais tenter de décrire mon dessin
Mon programme se compose de 3 murs : un mur de fond,2 murs sur la gauche et la droite, un sol..
Sur ce sol est posé des billes et une caisse. Quand le programme on se retrouve de face au décor.
5)J'ai utilisé une lumière directionnele pour simuler la lampe et bizzarement ca marche assez,j'ai une créer une sphere et quand je la déplace elle éclaire mais trop faiblement les surfaces est ce du à la position de ma lumiere??
Je met la procédure ou je créer mes objets au cas ou si tu désires voir
1)Cela veut donc dire qu'avec une lumiere ponctuelle il m'est impossible de la placer sur la scene car elle est ponctuelle?Une lumiere directionelle peut-elle etre placer sur scene?
Ce que tu as défini, c'est une lumière directionnelle, pas ponctuelle (par directionnelle, je n'entends pas un spot, ce qui est possible également, mais une lumière qui vient de l'infini, par exemple de la droite vers la gauche).
Si tu veux une lumière ponctuelle, dans la scène, il te faut remplacer
int PositionLumiere[4] = {0,70,-70,0}
par
int PositionLumiere[4] = {0,70,-70,1}
(la quatrième coordonnées, elle sert pour un système de coordonnées dit homogène si tu en as déjà entendu parler... OpenGL fonctionne complètement avec ce genre de coordonnées. Dans le cas où elle est nulle, le point est à l'infini. Si elle est égale à 1, ce sont des coordonnées "normale". Sinon, ça fonctionne en gros comme un "scaling" des trois autres coordonnées, en ce sens que (2, 4, 0, 2) est équivalent à (1, 2, 0, 1), ca désigne le MEME point).
2) en plaçant la lumière à une distance visible sur mon plan,il serait donc possible de controler la lumiere?
Bien sûr (si je comprends ce qui t'intéresse). Ca fonctionne de la même façon. Il faut juste te souvenir que les lumières, dans OpenGL, ne projettent JAMAIS d'ombre, c'est à toi de les calculer si tu en veux...
3)Sinon si je met la sphere à la même position que la lumiere étant positionné à l'infini comme peut-elle etre visible?
Si tu essaies de mettre la sphère également à l'infini, elle ne sera pas dans la boite de tracé, et elle n'apparaîtra pas. Les lumières ne sont pas influencées par la boite de tracé, donc ce n'est pas un problème pour elles... Donc si tu la mets à l'infini, il faut trouver des coordonnées DANS la boite de tracé qui correspondent à peu près à l'endroit d'où vient la lumière, et selon ce que tu fais, ce peut être difficile à calculer.
4)Je peux manipuler la lumiere ponctuelle via les touches du clavier grace à la rotation or il se déroule un phenomene bizarre quand l'avant de mes billes sont éclariés mais pas le mur ! alors que quand le mur est éclairé,les billes non..Je sais pas si c'est clair je vais tenter de décrire mon dessin
Ca, ça ressemble à un bug de normale... Outre les points décrivant les extrémités de tes objets, il faut indiquer dans quelle direction est l'extérieur. Je pense que ton mur est déclaré à l'envers. Si tu ne déclares pas explicitement les normales (une commande glNormals pour chaque point qui prend en paramètre un vecteur de norme 1 qui pointe vers l'intérieur de ta pièce... cela dit, vu que ton mur est plat (donc la normale ne change pas), tu peux n'en préciser qu'une seule pour tout le polygone), alors il essaie de se débrouiller tout seul.
Je crois qu'il suit la règle du tire-bouchon, ie que quand tu regardes le mur, il faut mettre les points dans le sens direct (inverse des aiguilles d'une montre). Si ça bugge de cette façon, essaie de mettre les points dans l'ordre inverse pour le mur.
5)J'ai utilisé une lumière directionnele pour simuler la lampe et bizzarement ca marche assez,j'ai une créer une sphere et quand je la déplace elle éclaire mais trop faiblement les surfaces est ce du à la position de ma lumiere??
Je met la procédure ou je créer mes objets au cas ou si tu désires voir
Pour la lumière, comme ça, je ne saurais te répondre... Il faudrait plutôt que tu postes ce qui concerne sa configuration (déclaration, instanciation, variables liées à sa position et sa couleur, etc.)
D'autant que je ne sais pas si je comprends bien ce que tu entends par lumière directionnelle, en fait...
Ce que tu as défini, c'est une lumière directionnelle, pas ponctuelle (par directionnelle, je n'entends pas un spot, ce qui est possible également, mais une lumière qui vient de l'infini, par exemple de la droite vers la gauche).
Si tu veux une lumière ponctuelle, dans la scène, il te faut remplacer int PositionLumiere[4] = {0,70,-70,0} par int PositionLumiere[4] = {0,70,-70,1}
(la quatrième coordonnées, elle sert pour un système de coordonnées dit homogène si tu en as déjà entendu parler... OpenGL fonctionne complètement avec ce genre de coordonnées. Dans le cas où elle est nulle, le point est à l'infini. Si elle est égale à 1, ce sont des coordonnées "normale". Sinon, ça fonctionne en gros comme un "scaling" des trois autres coordonnées, en ce sens que (2, 4, 0, 2) est équivalent à (1, 2, 0, 1), ca désigne le MEME point).
Je crois que je confond là:
-1 égale lumiere PONCTUELLE,qu'on peut mettre dans le décord avec des coordonnées"normales"dans le plan
-0 DIRECTIONNELLE infini,on ne peut pas la déplacer dans le plan..
Citation :
Bien sûr (si je comprends ce qui t'intéresse). Ca fonctionne de la même façon. Il faut juste te souvenir que les lumières, dans OpenGL, ne projettent JAMAIS d'ombre, c'est à toi de les calculer si tu en veux...
Je crois que je ne vais pas gérer les ombrees
Citation :
Ca, ça ressemble à un bug de normale... Outre les points décrivant les extrémités de tes objets, il faut indiquer dans quelle direction est l'extérieur. Je pense que ton mur est déclaré à l'envers. Si tu ne déclares pas explicitement les normales (une commande glNormals pour chaque point qui prend en paramètre un vecteur de norme 1 qui pointe vers l'intérieur de ta pièce... cela dit, vu que ton mur est plat (donc la normale ne change pas), tu peux n'en préciser qu'une seule pour tout le polygone), alors il essaie de se débrouiller tout seul.
Je crois qu'il suit la règle du tire-bouchon, ie que quand tu regardes le mur, il faut mettre les points dans le sens direct (inverse des aiguilles d'une montre). Si ça bugge de cette façon, essaie de mettre les points dans l'ordre inverse pour le mur.
Ce qui expliquerait pourquoi les textures soient inversés...
Malheureusement je ne comprend pas bien les notions de "normales" : les intérieurs et les extérieursde du mur?
Je suis vaiment nul en mahtématique
Citation :
D'autant que je ne sais pas si je comprends bien ce que tu entends par lumière directionnelle, en fait...
C'est parc eque je confondais luumiere DIRECTIONNELLE ET PONCTUELLE..la lumiere que je déplacais était ponctuelle (enfin je pense)
Je suis actuellementen entreprise je ne peux pas mettre mon code,ce soiren esperant que tu seras là
Je crois que je confond là:
-1 égale lumiere PONCTUELLE,qu'on peut mettre dans le décord avec des coordonnées"normales"dans le plan
-0 DIRECTIONNELLE infini,on ne peut pas la déplacer dans le plan..
En gros, oui... Mais, ce n'est pas 'plan', c'est 'espace' Par contre, les lumières directionnelles on peut quand même les déplacer, seulement, elles restent toujours infiniment loin, ce que tu fournis, c'est un vecteur qui indique la direction dans laquelle on les trouve.
Ca me parait raisonnable (je n'ai quasiment jamais géré ça moi-même, sauf dans des cas simples (un jeu avec une boule sauteuse sur terrain plat) et quand j'ai voulu comprendre le fonctionnement des shadow volumes.
Ce qui expliquerait pourquoi les textures soient inversés...
Je ne suis pas certain de comprendre ce que tu entends par "inversées". Si c'est un texte à l'envers, alors non (ce sont les coordonnées à coup de glTex qui sont incorrectes). Si la texture est du mauvais côté du mur, c'est possible, mais en principe OpenGL texture des deux côtés au besoin.
Malheureusement je ne comprend pas bien les notions de "normales" : les intérieurs et les extérieursde du mur?
Je suis vaiment nul en mahtématique
Meuh non... C'est vrai que ça aide, mais on peut s'en sortir sans.
Une normale, c'est une direction. Quand tu as une surface, et que tu veux savoir comment elle renvoie la lumière, tu as besoin de calculer l'angle que fait ta surface avec le rayon de lumière (pense par exemple à la façon dont la lumière rebondirait sur un objet métallique, selon les lois de Décartes, même si en l'occurrence l'OpenGL ne gère pas les rebonds).
C'est en fait la direction perpendiculaire au plan tangeant à la surface. Pour faire simple, ça consiste à dire "l'observateur, il sera par là". Je prends un exemple :
Un mur qui va de x=0 à x=100 en largeur, et z=0 à z=20 en hauteur. Situé en y=0.
Si ton observateur se trouve du côté des y>0, alors la normale sera (0, 1, 0).
Si ton observateur se trouve du côté des y<0, alors la normale sera (0, -1, 0).
Pour le sol, comme tu te trouves au-dessus, la normale serait (0, 0, 1). Etc.
J'ai tenté d'utiliser glNormals3i mais je rentre des coordonnées par hasard (car je ne sais pas comment déterminer la normale de mes surfaces) et cela obscurcit la scène,enfin c'est sur au hasard c'est pas trop la bonne méthode...
EDIT : Koren merci d'avance si tu tenais à me répondre mais ma prof vient de m'envoyer un mail ( à minuit!La surprise que j'aurai eu si j'avais pas lu le mail..) pour me dire qu'elle ne sera pas à le demain,donc c'est reporté à vendredi
Message édité par zell789 le 17-04-2007 à 00:08:46
Cool D'autant que j'ai eu un problème de train et que je suis rentré très tard.
Pour les normales, si tu veux les calculer, tu peux prendre trois points d'un polygone et utiliser :
(y2-y1)*(z3-z1)-(y3-y1)*(z2-z1)
(z2-z1)*(x3-x1)-(z3-z1)*(x2-x1)
(x2-x1)*(y3-y1)-(x3-x1)*(y2-y1)
ou bien exactement l'opposé (id est -()*()+()*() )
Vive le produit vectoriel
Par contre, tu devrais utiliser glNormal3f plutôt ?
ou j'ai pris pour x1=30000 x2=-30000 x3=20000
y1=8000 y2=120000 y3=-8000
z ) -30000 (les cordonnées de z restent les mêmes)
ce qui donne : glNormal3f(0,0,(((-30000-30000)*(-8000-8000))-((20000-30000)*(12000-8000))));
J'obtiens quelques chose de bizarre: tout la scene s'éclaire ou tout s'assombrit (mal écrit ) alors que la boule qui contient la lumiere doit éclaircir le mur et pas le rendre totalement noir..
Je sais pas si je m'exprime bien...
par contre comment faire pour calculer la normale d'une sphere voici le type de déclaration que je fais:
les arguements de gluSphere sont (pris du GLinFrenck)
Citation :
Le premier paramètre désigne le quadric dont la sphère va dépendre, le second est le rayon de la sphère, le troisième est le nombre de subdivision en "longitude", et le dernier concerne les subdivisions en "latitude" (comme des parrallèles et des méridiens).
Les problèmes classiques lorsque l'on joue avec l'éclairage OpenGL sont :
-des normales qui n'ont pas une longueur unitaire
-une tesselation insuffisante de ta géométrie car OpenGL réalise les calculs d'éclairage par sommet et ensuite interpole pour trouver une valeur par pixel.
Ce document recense quelques unes des erreurs classiques, je pense que ça te sera utile.
ce qui donne : glNormal3f(0,0,(((-30000-30000)*(-8000-8000))-((20000-30000)*(12000-8000))));
J'obtiens quelques chose de bizarre: tout la scene s'éclaire ou tout s'assombrit (mal écrit ) alors que la boule qui contient la lumiere doit éclaircir le mur et pas le rendre totalement noir..
Je sais pas si je m'exprime bien...
Siu, bien, mais c'est de ma faute. J'ai oublié de dire qu'il fallait le normaliser, ainsi que le rappelle Zeross. Du coup, ça donne :
glNormal3f(0,0,1);
Toutes mes excuses (j'ai des procédures toutes faites pour gérer ça, et du coup, je ne m'en sers pas souvent, et quand je les précise à la main, je normalise machinalement).
par contre comment faire pour calculer la normale d'une sphere voici le type de déclaration que je fais:
Pas besoin, pour les quadriques, il s'en charge tout seul. C'est juste pour les polygones, quads, strips, etc (et en particulier, ça permet de simuler des surfaces courbes).
Je ne sais pas si il y a encore du monde mais j'ai appliqué le produit vectoriel mais j'ai trouvé glNormal3f (0,1,0);
y ayant toujours la même valeur il n'y a que le produit avec x et z qui ne donne pas de valeur nul or j'ai le fonctionnement inverse : si on s'éloignait du sol,la lumiere éclairait
j'ai changé par Glnormal3f(0,0,1) la ca marhce comme tu me l'avais recommandé Koren
Au faite est ce que les normals des polygones influences la reflexion sur les autres polygones
Merci beaucoup a a ceux qui me répondront avant vendredi matin
y ayant toujours la même valeur il n'y a que le produit avec x et z qui ne donne pas de valeur nul or j'ai le fonctionnement inverse : si on s'éloignait du sol,la lumiere éclairait
Je ne suis pas bien... Dans l'exemple que tu as posté, c'est Z qui ne change pas ?
Au faite est ce que les normals des polygones influences la reflexion sur les autres polygones
Non, OpenGL ne gère pas les réflexions. C'est juste pour savoir quelle quantité de lumière reçoit le polygone : plus la lumière est rasante (rayons quasi-orthogonaux avec la normale), plus c'est sombre.
Je ne suis pas bien... Dans l'exemple que tu as posté, c'est Z qui ne change pas ?
Pas tres logique mais plutot efficace,je change les coordonnées de glNormal au hasard et je test les résultats ce qui donnes des reflexions assez cohérentes : quand la sphere lumineuse s'éloigne la surface s'assombrit, et quand on se rapproche elle s'éclaire un peu plus..
Je ne comprend pas trop le pourquoi du comment mais je préfére ça que toute la scene qui s'obscurcie
Citation :
Non, OpenGL ne gère pas les réflexions. C'est juste pour savoir quelle quantité de lumière reçoit le polygone : plus la lumière est rasante (rayons quasi-orthogonaux avec la normale), plus c'est sombre.
Oui je viens de le remarquer apres ton post
Mon projet est au point : mouvement de caméra 3D(translation,rotation),texturing,lumiere mobile,j'ai placé quelques objets dans le décors
Seul regret la spheres ne se comporte pas comme une lumiere je voulais avoir une boule lumineuse et la il faure lui fait subir des rotations pour que la lumière soit bien capté sur toute la scene..
Message édité par zell789 le 20-04-2007 à 01:01:09
En tout cas j'espere continuer en OpenGL car c'est tres intéressant mais est ce que cela permet un garantir de carrière de se spécialiser en OpengGL ?
Les applications 3D, c'est certain qu'il va y avoir un besoin de développeurs. Je ne suis pas convaincu que OpenGL prendra le dessus (pour pas mal de choses, il est considéré comme un peu à la traîne, la faute à ceux qui mettent des années à nous pondre les spécifications alors que Microsoft a une forte réactivité avec ses propres API. En fait, c'est même Microsoft souvent qui arbitre les litiges et donne la direction à suivre). Maintenant, c'est la façon de penser qui prime.
Quant à savoir s'il y aura des débouchés, je ne sais pas exactement ce que les recruteurs chercheront. La plupart des gens que je connais qui bossent dans le domaine on un master et une thèse sur le sujet. Dont un vivement courtisé à la fois par Microsoft et nVidia Je ne prendrais sans doute pas le risque de ne faire "que" ça, mais ça devrait être un gros plus pour une recherche d'emploi que de maîtriser ces outils, je pense.
Zell => Je ne suis pas au niveau de Zeross, de Koren, ou de Skyfighter, mais ce que j'ai remarqué, c'est que tu as tendance à tracer tes figures dans le sens des aiguilles d'une montre, et à celà OpenGL considère que tu dessines l'arrière du polygone, donc tu peux te retrouver avec des problèmes de textures qui sont appliquées de l'autre côté du polygone.
Pense à avoir le réflexe de dessiner dans le sens inverse des aiguilles d'une montre pour qu'OpenGL considère que tu dessines l'avant du polygone, les textures auront alors plus de chances d'être du bon côté.
J'en suis sûr à 10%, mais il me semble qu'OpenGL attribue des normales par défaut sur les figures simples, et que par conséquent, dessiner un polygone dans le sens des aiguilles d'une montre peut donner lieu à des normales héritées par défaut qui iront dans le sens opposé à celui voulu.
J'en suis sûr à 10%, mais il me semble qu'OpenGL attribue des normales par défaut sur les figures simples, et que par conséquent, dessiner un polygone dans le sens des aiguilles d'une montre peut donner lieu à des normales héritées par défaut qui iront dans le sens opposé à celui voulu.
Tu as tout à fait raison (d'ailleurs on en parlait plus haut, ça doit expliquer certains de ses problèmes d'éclairage)
Zell => Je ne suis pas au niveau de Zeross, de Koren, ou de Skyfighter, mais ce que j'ai remarqué, c'est que tu as tendance à tracer tes figures dans le sens des aiguilles d'une montre, et à celà OpenGL considère que tu dessines l'arrière du polygone, donc tu peux te retrouver avec des problèmes de textures qui sont appliquées de l'autre côté du polygone.
Pense à avoir le réflexe de dessiner dans le sens inverse des aiguilles d'une montre pour qu'OpenGL considère que tu dessines l'avant du polygone, les textures auront alors plus de chances d'être du bon côté.
Merci
En faite ca dépend,j'ai du mal à me répérer dans ma tete avec les espaces 3D.Peut etre qu'implicitement je l'ai fais dans le sens de l'aiguille d'une montre ! Par contre si je n'oublie pas trop vite j'ai beaucoup moins de mal à dessiner maintenant !
Oui j'ai eu le probleme avec la texture inversé (en faite avec qu'une seule car j'ai modifié les codes des textures)
Je me souviendrai de ton conseil la prochaine fois
Citation :
Je ne prendrais sans doute pas le risque de ne faire "que" ça, mais ça devrait être un gros plus pour une recherche d'emploi que de maîtriser ces outils, je pense.
C'est ce que je pensais,ca peut etre un "bon bagage" !
Actuellement j'ai arreté un peu l'OpenGL car mon stage me demande plus des compétences en PHP/MySQL/HTML/Javascript(surement) et vu que l'année derniere j'ai pas été tres sérieux en PHP,je me souviens que des bases et encore
De plus j'ai l'impression que Javascript semble un etre un "plus" indispensable avec HTML car pour créer des menus déroulants ou des menu "ouvrant-fermant" (par exemple je clique sur config ca ouvre un menu config,je reclique ca ferme)Je vois du JavaScript dans le code,rien a voir avec Java ,JavaScript
J'avais postulé a Quantic Dream,WHitebird production et BAM Studio mais ils m'ont tous refuser ou ne m'ont jamais répondu (malgré les relances)dommages j'aurai voulu a quoi ressemblait un studio de Jeux video
De plus j'ai l'impression que Javascript semble un etre un "plus" indispensable avec HTML car pour créer des menus déroulants ou des menu "ouvrant-fermant" (par exemple je clique sur config ca ouvre un menu config,je reclique ca ferme)Je vois du JavaScript dans le code,rien a voir avec Java ,JavaScript
Javascript est pas mal utilisé pour ça, mais pas besoin de Javascript pour ce genre de choses avec les normes actuelles de HTML. Ca se fait sans aucune difficulté avec un peu de CSS, et à mon sens, c'est infiniment plus élégant. Ca a l'avantage de fonctionner même si le javascript est désactivé et/ou non supporté, et ça devient une liste si le browser est trop ancien pour du css. Tu peux évidemment avoir des soucis avec quelques rares browsers qui supportent partiellement CSS avec des bogues, mais il n'y en a plus beaucoup.
De toute façon, si tu te mets à faire du HTML de façon sérieuse, je te recommande de t'intéresser à CSS (pas seulement pour les menus, mais pour tout ce qui est mise en forme et positionnement).
Ca a l'avantage de fonctionner même si le javascript est désactivé et/ou non supporté, et ça devient une liste si le browser est trop ancien pour du css. Tu peux évidemment avoir des soucis avec quelques rares browsers qui supportent partiellement CSS avec des bogues, mais il n'y en a plus beaucoup.
Genre internet explorer J'ai pas teste sur le dernier, il supporte la transparence dans les css
---------------
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d.
1f u c4n wr1t3 1t t00.
Javascript est pas mal utilisé pour ça, mais pas besoin de Javascript pour ce genre de choses avec les normes actuelles de HTML. Ca se fait sans aucune difficulté avec un peu de CSS, et à mon sens, c'est infiniment plus élégant. Ca a l'avantage de fonctionner même si le javascript est désactivé et/ou non supporté, et ça devient une liste si le browser est trop ancien pour du css. Tu peux évidemment avoir des soucis avec quelques rares browsers qui supportent partiellement CSS avec des bogues, mais il n'y en a plus beaucoup.
De toute façon, si tu te mets à faire du HTML de façon sérieuse, je te recommande de t'intéresser à CSS (pas seulement pour les menus, mais pour tout ce qui est mise en forme et positionnement).
D'accord,il est donc préférable d'utiliser CSS alors
Bon il parait que pour les galères C++ (builder) on peut demander ici.
Alors ma nana doit programmer pour sa QTS, et notamment en C++. Et aujourd'hui, elle voulait bidouiller sur l'ordi, et paf erreur:
Citation :
quand je clique sur projet>options, j'ai une erreur : "violation d'accès à l'adresse x. Ecriture de l'adresse x." Et cette erreur, je ne l'ai pas sur mon pc au boulot, mais que sur le pc de Sophocle.
Message édité par sophocle le 22-05-2007 à 18:13:49
), la lumière n'est affectée que par l'une des deux contrairement à la scène qui est affectée par les deux. Du coup, ça peut être un peu délicat à gérer...
Je ne prendrais sans doute pas le risque de ne faire "que" ça, mais ça devrait être un gros plus pour une recherche d'emploi que de maîtriser ces outils, je pense.
© 2000-2008, Splitgames Network - Tous droits réservés | Nous contacter