Reprise du message précédent :
Voici le programme qui s'occupe de l'effet spéculaire de la route:

l'unité 0 contient le cubemap normalisant, la 1 la normal map, la 2 rien, la 3 la texture de base.
Comme tu vois, je normalise mes vecteur vue et lumière avant de les additionner et de projeter le résultat sur la base de chaque vertex. Et cette projection est elle même normalisée par le cubemap puis interpolée en chaque pixel.
Je ne saisis pas où pour survenir la dénormalisation.
 
Autrement, je préférerais autant que possible trouver une solution qui se passe de fragment program, histoire de rester compatible avec les nv20/r200.
 
Ca te dit quelque chose ?

La version linux ? ouaip je peux la mettre en ligne aussi, mais je ne l'ai jamais testée qu'avec ma configuration. Je n'assurerai rien de son fonctionnement sur une autre configuration, notamment à base de geforce (à une époque j'ai eu des soucis assez pénibles de compilation avec des bibliothèques nvidia sous linux et je me suis depuis détourné des tests sur ce système)
 
Ceci dit, elle est strictement identique à la version windows, les perf en moins tout de même (pilote ati oblige, j'ai presque 40% de fps en moins) Alors je prendrai un peu de temps pour la préparer mais il faudra me promettre que votre linux est correctement configuré et possède les bons pilotes opengl propriétaire.
Promis ? On lève le doigt svp.
Bon ok.

Je la veut aussi    
L'autre jour j'ai du rebooter rien que pour tester ton jeu de la mort  

 
bah, mais c'est pas du bump que tu fais, c'est de l'éclairage par vertex, et non par pixel. (déjà)
 
donc oui tu te retrouves avec les défauts de l'éclairage par vertex. (si gros triangle, spéculaire un peu cracra)

Intéressé par la version Linux Pilote nvidia / ti4200 ok. !

Rôôh lui... même  que si d'abord ! C'est peut être pas de L'éclairage à 100% par pixel, mais c'est quand même du bump dot3 par pixel. Actuellement les fragment program me servent à limiter à une seule passe le dessin de tous les objets et à paramétrer finement les équations de blending. Sur les nv20/r200 je suis obligé d'effectuer deux passes et de m'en remettre aux fonctions de blending génériques.
L'effet est moins joli et moins performant mais globalement équivalent.
Maintenant, si j'utilise des fp plus complexes pour un éclairage à 100% par pixel, je casse cette équivalence et me voilà bien embêté. Mais c'est peut-être la seule solution qui me permettra un effet spéculaire correct sur la route.
 
Ceci dit, je connais bien les limitations de l'éclairage par vertex, mais le cubemap en pallie beaucoup. Pas toutes malheureusement. Damned.
 
Pour la version linux, please un peu de patience siouplait, j'essaierai de la livrer dans la semaine. Merci pour les encouragements !

c'était histoire de faire mon relou
 
edit: en fait c'est juste que tu calcules le halfway par vertex, et non par pixel.
 
ça doit être ça qui doit boussiller le comportement du spéculaire.
normalement il faut faire évoluer (interpoler) séparément le vecteur vue et lumière, et faire le halfway par pixel (et faire le dot3 avec la normal map avec ce halfway).
 
ça pourrait déjà aider à stabiliser le spéculaire. (après comme j'ai dit, l'idéal, c'est de calculer le vecteur vue et lumière par pixel).

Par Ahoura Mazhda ! La version linux est disponible sur mon site.
Soyez indulgents, pitié, je ne l'ai jamais testée que sur ma machine. Ceci dit elle partage 98% de son code avec la version windows, elle a les mêmes exigences et effectue les mêmes tests de compatibilité au démarrage. Mais ne vous fâchez-pas si ça plante dès le début, pitié, ce n'est qu'une version de test.
 
"NON pas de place pour les faibles et les pleurnichards, tu vas payer comme les autres !"
"argll"
 
http://perso.wanadoo.fr/mezzoban

OUILLEOUILLE, j'ai oublié de prévenir, il faut avoir compilé et installé la bibliothèque glut !!!!

Yes
 
Je viens de tester, mais j'ai un petit soucis au lancement  
 

 
Je tourne avec un 2.6.8.1 et les derniers nvidia 6111, Quake et UT tournent sans soucis.  
 
Je suis pas très au courant, mais peut-être qu'il vaut peut-être mieux utiliser glXGetProcAdressARB ?
 

 
Edit : c'est peut etre spécifique au driver nvidia ?

Ay ! C'était peut-être bien ça mon ancien problème avec les drivers nvidia, Bon, sympa d'avoir payé les pots cassés, je vais tester une solution, peut-être ce soir. Je te tiens au courant.

Super @+

Aucun problème pour moi elle tourne parfait sous linux

Ok, le problème vient peut-être de moi alors. Tu as quel drivers ?

J'ai une ATI

Ok

Argl, un petite message rapide pour gueuler contre le pilote ATI sous linux: "GRUMF!" Impossible d'utiliser glXGetProcAddressARB au lieu de glXGetProcAddress. Y-a-t'il quelqu'un dans l'assemblée qui a déjà réussi ce tour de force ? Moi, même si la fonction est présente dans glx.h et dans libGL.so, il refuse systématiquement de la lier à la compilation en prétextant qu'il ne la trouve pas. Je ne crois pas avoir de problème de conflit (ça serait bien la première fois), et je viens de mettre les tout derniers pilotes en vain.
Il y a un truc secret à savoir sur glXGetProcAddressARB dans les pilotes ati ? Pourquoi les pilotes nvidia refusent glXGetProcAddress ? Pourquoi le nutela est-il si bon ?
C'est précisément ce problème qui m'avait stoppé il y a quelques mois dans mes tests sous linux (celui concernant glXGetProcAddressARB, pas le nutela).
 
La france a besoin de votre aide !

Regarde peut-être dans le code source de SDL pour voir comment il s'en sorte avec SDL_GL_GetProcAddress :
 
http://sdldoc.csn.ul.ie/sdlglgetprocaddress.php