Reprise du message précédent :
Vous m'avez donné l'envie de m'y remettre  
 
Autrement, je souhaiterai pouvoir concevoir des modèles complexes par un log de 3D. Lequel s'en sort bien pour une exportation vers OpenGl ?

Il n'y a pas de façon simple de faire un soleil "visible". La seule façon de le bidouiller, c'est de dessiner une sphèe à l'endroit de la lumière en désactivant la lumière elle-même au moment du tracé (sinon on risque d'avoir des soucis vu que la source est dedans) ou en la redéclarant en ambiante.
 

Je suppose que tu veux un éclat sur les boules, parce que les reflets (type miroir ou illumination globale), ce n'est pas "faisable" automatiquement en OpenGL. Au passage, il est important si tu fais ça pour avoir un bon résultat de définir un matériau pour tes objets.
 

Non, il demande un pointeur constant vers un tableau. Les valeurs du tableau peuvent tout à fait être variables...
 

C'est souvent le cas. En général, on met au minimum un paramètre de lumière ambiante de (0.5, 0.5, 0.5) par exemple. Ca évite les coins sombres dans la scène. Puis tu peux mettre une lumière diffuse importante (genre (1.0, 1.0, 1.0)) pour avoir des effets de lumière. Donc deux glLight(), l'un avec GL_AMBIANT, l'autre avec GL_DIFFUSE.
 

Tu as du mal à placer la source ou tu veux ? Tu as pensé que la position d'une source de lumière, c'est un vecteur à QUATRE coordonnées ? La dernière doit être à 1.0 si tu as un source ponctuelle, et 0.0 si tu as une source éloignée à l'infini (auquel cas, les trois autres paramètres indiquent la direction).
 
Tu peux aussi jouer avec GL_SPOT_* si tu veux une lumière directionnelle (pratique pour faire des lampes de bureau ou des torches
 

Pas de problème... Désolé de répondre si tard, j'ai bossé une bonne partie de la soirée.

Si tu veux de vraies ombres, c'est très très compilqué, oui. Ca demande une très bonne maîtrise de l'OpenGL. Sinon, tu peux simplement dessiner un disque semi-transparent noir au bon endroit juste au-dessus du sol... c'est ce que beaucoup de jeux font !
 
 
Quant à moi, j'ai absolument moyen de faire tourner un truc en OpenGL, mais :
 
- j'ai un ordi qui me répond

et n'affiche rien du tout (vive Linux)
 
- j'ai un autre ordi sous Windows dans lequel je n'ai pas envie d'installer OpenCV à la main
 
Et par ailleurs, j'aimerais savoir comment je peux avoir un résultat différent pour cvInvert selon que j'utilise CV_LU ou CV_SVD, et pourquoi un printf d'une variable est différent selon la position du return 0; dans le mail, placé *après* le printf, évidemment (ie problème d'écrasement de données par un truc qui doit être strippé à la compilation quand je sors prématurément  
 

Je peux le faire à coup de fwrite, de gdb ou de mon propre logiciel de debug (à coup de messages via socket), ça ne change rien (et le flush encore moins). J'ai un débordement important, fourbe, et qui dépend d'une partie qui n'est pas incluse dans le binaire quand je vire la fin du fichier. C'est le exit précoce qui fait que ça marche, parce qu'il ne doit pas inclure certaines fonctions. Qu'elles soient exécutées ou non n'a aucune espèce d'importance, le truc, c'est qu'elles soient présentes dans le binaire ou non.
 
Bref, un vrai gros bug étrange et chiant à trouver comme le C sait les faire. J'ai fini par écrire la matrice dans un fichier avec un exit précoce, et la recharger dans le programme plutôt que de la calculer. Certes, ça fait crade, mais je suis pressé.

Dis Koren, ca fait un moment que je n'ai pas verifie les ameliorations de performances des drivers de ma carte mais es-tu sur que glDrawPixels est plus rapide qu'un quad texture? Il y a 3-4 ans de cela ce n'etait vraiment pas du tout le cas.

En fait, ça dépend... Sur le fond, les deux font à peu près la même chose (avec le positionnement en moins pour glDrawPixels). La différence de vitesse, elle vient surtout du fait que la texture est dans la mémoire vidéo, le buffer de pixels dans la mémoire centrale.
 
Donc fatalement, assez souvent, le glDrawPixels est moins rapide parce qu'il dépend du bus, de la mémoire, et de ce que fait la machine le reste du temps. Maintenant, selon que tu affiches toujours le même ou que tu changes à chaque image, ça ne donnera pas le même résultat (en gros, si tu veux les comparer, il faut comparer le glDrawPixels au draw texturé + le glTexImage2d...)
 
Cela dit, l'intérêt du glDrawPixels, il n'est pas dans la vitesse (souvent, pour ce genre de projet, ce n'est pas une question de vitesse) mais dans la facilité. Il est un peu moins nécessaire de jouer avec la caméra et les coordonnées du Quad. Et puis, si l'image n'est pas de la forme 2^n x 2^n, tu n'as pas à jouer à la retailler...
 
Par ailleurs, sur ma machine précédente, il y avait un bug (connu et courant) sur le texturing openGL qui faisait qu'il était assez lent, de toute façon. Qui plus est, sur un portable où la mémoire vidéo est partagée, tu n'as pas le gain en perf de la texture dans la mémoire vidéo.
 
Voilà  
 
Enfin bref, je ne recommandais pas cette solution pour des questions de performances, mais plutôt de facilité.

Vi, c'est délicat à localiser...
 

Sous une Debian GNU Linux (testing standard à jour)...

Ce n'est pas forcément facile à expliquer, mais je vais essayer. Quand tu indiques une translation avec OpenGL, il tourne le repère courant, pour faire simple. Je ne sais pas si tu as fait du Logo, mais en gros, ça correspond en quelque sorte à tourner la souris de Logo.
 
Du coup, si tu fais une rotation, l'objet que tu traces après sera tourné... mais aussi tous ceux qui suivent. Par ailleurs, les translations qui suivent sont aussi "tournées", donc ça devient un cauchemar.
 
En gros, si tu veux une solution pas trop compliquée :
- tu te places normalement avec une translation
- tu tournes le repère
- tu traces l'objet
- tu tournes le repère exactement dans l'autre sens pour annuler
- tu utilises une translation pour aller vers l'objet suivant
 
Là où ça devient délicat, c'est si l'objet ne tourne pas autour du point qui t'intéresse, auquel cas il faut encore ajouter d'autres translations. Mais là, ça devient des maths...

Bon, ben j'ai le regret de te dire que c'est exactement ça
 
En gros, OpenGL se souvient d'une* matrice M 4x4. Tous les points sont des vecteurs v à 4 coordonnées.
 
Première chose, glLoadIdentity() -> on place l'identité dans M
Ensuite, toutes les commandes vont modifier cette matrice...
 
Par exemple, glTranslate(x, y, z) produit la matrice T
1 0 0 x
0 1 0 y
0 0 1 z
0 0 0 1
et remplace M par le produit de M avec T
 
Ca correspond en pratique à une translation du repère. Idem pour les instructions de projection, de rotation, de redimentionnement, etc.
 
Si OpenGL a besoin d'afficher un point décrit par un vecteur v, il calcule M.v ce qui lui donne un vecteur v'. Les coordonnées de v' (X, Y, Z, T) fournissent les coordonnées écran : X/T et Y/T et la profondeur Z/T (pour le Z-buffer).
 
Bon, très schématiquement. En pratique, on peut s'en servir sans savoir comment ça marche, mais on merde un peu parfois pour comprendre dans quel sens ça tourne
 
 
* (en fait deux, GL_PROJECTION et GL_MODELVIEW, mais bon... pour ton projet, si cette subtilité n'est pas évidente, ce n'est pas un problème)

Si, le glLoadIdentity, c'est à faire au tout début, en premier. Avant le gluLookAt ou équivalent. Sinon, tu as raison, ça réinitialise la matrice. (et du coup, si tu en mets une en plein milieu, oui, les objets se retrouvent n'importe où )

Pas nécessairement... Imagines-toi un repère avec trois axes. Chaque fois que tu fais une translation, il se déplace selon ses axes. Chaque fois que tu mets une translation, il pivote sur lui-même. Quand tu traces un objet, il se trace selon les axes de ce repère mobile.
 
J'avais songé à faire un tutoriel interactif pour expliquer ça, mais je n'ai jamais trouvé le temps. Pour ceux qui ont fait du Logo, encore une fois, c'est exactement le principe.
 

En Java, je n'ai jamais fait, mais si tu as des problèmes et que c'est un serveur par sockets, tu peux toujours demander... ça doit suffisamment ressembler au C pour que je puisse me raccrocher aux clients/serveurs que j'ai programmés.
 
Bon courage en tous cas...

Perso, je procède différemment, d'habitude. Je ne forke pas le programme, mais je garde tout en un seul thread. La raison pour laquelle tu obtiens la même réponse sur tous les clients, c'est peut-être justement parce que tu as un problème de mémoire partagée quand tu splittes les threads (en particulier, les pointeurs après le fork pointent tous vers la MEME adresse, ce qui peut poser problème, mais beaucoup d'autres variables sont partagées).
 
Alors forcément, avec un seul thread, c'est un brin plus tordu à gérer, mais en fait, on peut écouter (du moins en C) TOUS les sockets en même temps, et avoir une action dépendant du socket qui a reçu un message. Ca évite quelques problèmes, mais ça peut en créer d'autres. C'est mieux surtout quand tous les joueurs jouent dans une même partie, pour un client applicatif, c'est différent.
 

A mon sens, ça devrait fonctionner ainsi : le serveur envoie au client les moments où les taupes entrent, sortent, et éventuellement sont assomées (si j'ai bien compris). Le client envoie au serveur les actions du joueur. Ce devrait être le serveur qui gère les conséquences de ces actions (taupe assomée, par exemple, les points, etc).
 
Pour centraliser les points, si tu choisis la méthode multi-thread, fournit à chaque thread un pointeur avant le fork vers une structure (appartenant au programme principal) dans laquelle il pourra mettre les résultats. Pense à mettre un flag dans la structure pour dire 'ça y est, c'est rempli'. Ainsi, le programme principal n'a qu'à surveiller les flags des structures de chaque thread pour savoir quand un thread a fourni son score. A noter que tu peux renvoyer des données dans le thread de la même façon, via la structure. Penses juste à mettre des flags pour savoir quand on peut lire les données, et dans la mesure du possible, utilise un accès en écriture uniquement pour l'un ou pour l'autre pour chaque donnée (l'autre ayant accès uniquement en lecture) et utilise des flags de terminaison, ça évitera les problèmes d'accès concurrent.
 
Bon courage, et bonne nuit

Je ne sais quoi dire si ce n'est
 
CVS, c'est bien (ou plutôt subversion que CVS, d'ailleurs)... Mais même quand je n'utilise pas de CVS, j'ai un make package pour faire des snapshots réguliers du projet, maintenant que la place disque n'est plus un soucis.
 
 
Skyfighter : je n'ai pas bien compris non plus le principe de ce jeu en réseau, je dois dire.

Tu n'aurais pas connaissance d'un bon site contenant des fichiers de traduction XML pour davsvn (Subversion via Apache) par hasard ?  

Zell789 : Content d'apprendre que la soutenance s'est bien passée, finalement...
 

En fait, quand tu installes le module SVN pour Apache, tu peux utiliser subversion via le web, ce qui m'est très utile (par exemple pour aller regarder un fichier d'un de mes projets sans avoir à télécharger des morceaux du projet, simplement en allant ouvrir une page web). Par ailleurs, on peut aller regarder de vieilles versions et autres joyeusetés du même genre. Cela dit, il produit si ma mémoire est bonne du XML, qui doit être mis en forme via un fichier de 'traduction'. Or celui par défaut donne un résultat moche... J'ai trouvé mieux, mais pas suffisamment de fichiers pour me servir d'exemple pour faire quelque chose qui me plaise vraiment.

Subversion utilise du xslt standard, apparemment, mais je n'ai jamais pris le courage d'apprendre à m'en servir (je n'en ai pas eu l'usage en fait).
 
SInon, oui, ça pond du html, mais indirectement, et on peut contrôler le html produit justement de cette façon...

Tu peux jouer avec les distances minimales et maximales d'affichage par exemple avec GluPerspective. Ca permet aussi de jouer avec la distance focale de la caméra.
 

Que veux-tu dire par murs à l'envers ?

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...