[opengl] à la recherche des fragment program sur geforce3/4

à la recherche des fragment program sur geforce3/4 [opengl] - C++ - Programmation

Marsh Posté le 29-09-2004 à 22:37:59    

Messieurs-dames, bonjour
 
Question à destination des pro d'opengl, attention.
 
Je développe depuis quelques mois un maxi jeu de bagnoles pourri en opengl utilisant ARB_VERTEX_PROGRAM et depuis peu ARB_FRAGMENT_PROGRAM. Il tourne sur radeon 9xxx et geforceFX mais pas sur geforce3/4 et c'est là ou ça m'ennuie. Les geforce3/4 supportent bien l'extension ARB_VERTEX_PROGRAM qui n'est d'ailleurs qu'une adaptation de NV_VERTEX_PROGRAM, mais pas du tout ARB_FRAGMENT_PROGRAM. D'autre part même si ces cartes sont sensées supporter les pixels shader, je ne vois rien qui ressemble à cela dans la liste de leur extensions. Je m'attendais à une sorte de NV_FRAGMENT_PROGRAM mais nada. Que dois-je en penser ? Que ARB_FRAGMENT_PROGRAM offre des pixels shaders de 2e génération (pixel shader 2.0 ?) incompatibles avec les geforce3/4 et les radeon8xxx ?
Qu'existe-t-il alors pour programmer des pixel shaders de 1e génération sur ces cartes ? Dois-je me contenter des NV_REGISTER_COMBINERS pour les geforce ?
Mais pourquoi, pourquoi ?
 
Merci pour votre attention !
 
john_john
 
 
ps: NV_FRAGMENT_PROGRAM existe bien, mais seulement à partir des geforcefx, damned.
 
pps: Est-ce une question de version de pilote ? Je sais que des fonctions nouvelles sont parfois apportées par des nouveaux pilotes, pourtant, ici même un pilote très récent ne semble pas offrir le support de ARB_FRAGMENT_PROGRAM aux geforce4
 
ppps: A part ça pour ceux que ça intéresse, mon jeu de bagnoles pourri commence à avoir une sacrée gueule, plus d'info sur demande [:

Reply

Marsh Posté le 29-09-2004 à 22:37:59   

Reply

Marsh Posté le 30-09-2004 à 15:16:29    

oui ARB_fp c'est R300+ & NV30+
pour GF3/4 (comme tu l'as dit) : reg combiners
pour R8500 : ATI_fragment_shader
 
voilou
 
PS :non c'est pas une question de pilote, c'est une question de hardware.  
PPS : allez, fais péter le lien vers ton jeu :) (et mets des screenshots, j'ai qu'une pauvre R8500 donc pas de ARB_fp :()

Reply

Marsh Posté le 30-09-2004 à 23:29:48    

Ok ! Merci pour les infos.
Après quelques modifs, mon jeu sait maintenant s'adapter pour tourner sur geforce3/4 et radeon 8500. Je vais tester mais il n'y pas de raison, j'y perdrai en perf par rapport aux cartes plus récentes (comme je n'utilise pas encore les reg combiner ni les ATI_fragment_shader, je dois m'y prendre à deux fois pour dessiner mes objets) Mais le rendu est quasi identique.
 
J'ai bien un site web qui parle de mon zeu, mais il n'est pas à jour, j'en indiquerai l'adresse dès que possible (une ancienne version est en téléchargement libre, mais elle n'a plus grand chose à voir avec l'actuelle et à vrai dire elle commence à me faire un peu honte, je vais l'abandonner à la DASS d'ailleurs)
 
ps: Ce n'est pas une question de pilote dis-tu ? ok, mais ça arrive parfois. Par exemple, le support de NV/ARB_vertex_program par les Geforce2 (oui 2) a été possible à partir d'une certaine version de pilote. Me gouré-je ?
 
pps: en guise de teaser, voici les quelques trucs sympas que j'ai développés dans mon zeu pourri: bumpmapping complet, ombres volumétriques, bagnoles photogéniques (elles font les stars), détection de collisions maison, moteur physique maison (pas top d'ailleurs mais honnête pour ce qu'il a à faire), jeu en réseau, customisation des bagnoles, assurance de rigolade pendant au moins 4 minutes. Je poste des captures dès que possible.

Reply

Marsh Posté le 30-09-2004 à 23:38:49    

toutes mes salutations à quelqu'un qui essayes de faire un jeu pourri dans son coin. (moi c'est un jeu super pourri de combat spacial en directx, et y'a pas de combat encore, donc tu es bien avancé sur ta liste de dev).

Reply

Marsh Posté le 01-10-2004 à 00:56:58    

ARB_vp peut etre émulé par le CPU sans trop dégrader les performances, c'est pour cela que cette extension est exposée par le driver même pour les vieilles cartes (jusqu'à GeForce 256 si je ne m'abuse). On ne peut pas vraiment dire que le GPU supporte la fonctionnalité à proprement parler, mais le résultat est le même.
Pour ce qui est de ARB_fp, c'est une autre histoire. Typiquement, son execution sur CPU donne un framerate à un seul chiffre (et petit en plus, le chiffre). Donc la, pas de miracle, si c'est pas supporté en hardware par le GPU, pas de fragment program.
 
Bon et sinon grouille toi de mettre à jour le site :p Tu nous as mis l'eau à la bouche la ;-)
Sinon le bump j'imagine que tu le fais en DOT3, non? T'as collé un peu d'environment mapping sur les caisses histoire de faire métalique?

Reply

Marsh Posté le 01-10-2004 à 22:34:21    

Super cool ! Mon new site pourri est on line.
Soyez indulgents il est un peu ... conceptuel.
http://perso.wanadoo.fr/mezzoban/
Vous y trouverez des captures d'écran du genre...
http://perso.wanadoo.fr/mezzoban/captures/mezzoban-0.70-09.png
 
J'ai besoin d'un peu de temps encore pour préparer une version téléchargeable du jeu (minimum geforce3 (sauf gf4mx) ou radeon 8500).
 
Le mapping environnemental est la dernière évolution graphique que je voulais apporter au zeu... avant de m'atteler à la refonte du moteur physique. Parce que aujourd'hui la physique est ... lunaire et carrément frustrante il faut dire.
 
john_john
 
ps: salutations à tous les créateurs de zeux pourris de la terre.

Reply

Marsh Posté le 01-10-2004 à 23:08:01    

j'aime bien les commentaires: "Les deux bolides rigolent"

Reply

Marsh Posté le 01-10-2004 à 23:18:55    

Je vois que t'as pris la skybox d'un mod pour halflife, ce serait vachement plus beau de la faire toi même en 4-5 clicks avec terragen ou un autre soft non ?

Reply

Marsh Posté le 09-10-2004 à 13:39:46    

Sapristischtroumpf ! La dernière version de mon jeu pourri est on line, je vous redirige sur mon site
http://perso.wanadoo.fr/mezzoban
section "télécharger". Cette version intermédiaire exige une Geforce3/4 ou une Radeon8500 mais est un peu plus joli sur GeforceFX ou Radeon9500 ou supérieur.
 
Honnêtement, c'est le jeu du siècle.
 
J'attends les réactions des motivés.
 
john_john
 
ps pour retrox: ayest, j'ai mis du mapping environnemental. C'est bien cool comme effet, merci du conseil.
 
pps pour whatde: skybox made in terragen, merci aussi du conseil
 
ppps pour Smaragdus qui doute avec une mauvaise foi probable de la récence des technologies opengl par rapport à dx9 dans un autre sujet: c'est de l'opengl 1.5 (la 2.0 vient de sortir) et j'utilise massivement les pixels shaders des GPU de génération NV30/R300. Et tiens-toi bien, il existe une version complètement identique de mon jeu qui tourne sous linux.

Reply

Marsh Posté le 09-10-2004 à 13:50:07    

j'ai une geforce 3, carte graphique non supportée :(

Reply

Marsh Posté le 09-10-2004 à 13:50:07   

Reply

Marsh Posté le 09-10-2004 à 13:54:32    

Merdeeeuh, arf, tu veux m'en reparler sur mon adresse mail ?
(elle est dans le fichier texte)
File-moi les traces de la fenêtre dos, je réagirai le plus vite possible.
J'avoue que je n'avais pas testé sur geforce3 (sur 4 oui mais je croyais que les mêmes extensions étaient supportées).
Tu as des pilotes récents ? (question naïve)
Merci déjà d'avoir essayé !

Reply

Marsh Posté le 09-10-2004 à 13:57:38    

les pilotes c'est 43.45

Reply

Marsh Posté le 09-10-2004 à 14:02:47    

Citation :


EXTENSIONS: Support de GL_ARB_multitexture
EXTENSIONS: Support de GL_ARB_texture_cube_map
EXTENSIONS: Support de GL_ARB_texture_env_combine
EXTENSIONS: Support de GL_ARB_texture_env_dot3
EXTENSIONS: Support de GL_ARB_vertex_program
EXTENSIONS: Support de GL_NV_vertex_program
Exige les extensions GL_ARB_multitexture, GL_ARB_texture_env_combine, GL_ARB_ver
tex_buffer_object, GL_ARB_texture_env_dot3 et GL_ARB_texture_cube_map, GL_ARB_ve
rtex_program
Extensions: GL_ARB_depth_texture GL_ARB_imaging GL_ARB_multisample GL_ARB_multit
exture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_
texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_textur
e_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_tran
spose_matrix GL_ARB_vertex_program GL_ARB_window_pos GL_S3_s3tc GL_EXT_abgr GL_E
XT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_comp
iled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_
arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters GL_E
XT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_s
hadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture3D G
L_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp
 GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EX
T_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_t
exture_object GL_EXT_vertex_array GL_HP_occlusion_test GL_IBM_texture_mirrored_r
epeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_de
pth_clamp GL_NV_fence GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_multisam
ple_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_dat
a_range GL_NV_point_sprite GL_NV_register_combiners GL_NV_register_combiners2 GL
_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 G
L_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_vertex_a
rray_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_
1 GL_NVX_ycrcb GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_lod
GL_SGIX_depth_texture GL_SGIX_shadow GL_WIN_swap_hint WGL_EXT_swap_control
carte graphique non supportee

Reply

Marsh Posté le 09-10-2004 à 14:11:56    

Pas de support de GL_ARB_vertex_buffer_object !?
Maismaismaismais ?
La geforce3 ne les supporte pas ? je suis dans l'espace.
C'est ça le problème, peut-être une mise à jour de tes pilotes qui ne sont pas récents pourraît apporter ce support et régler la question.
La geforce4 les supporte, ça je peux l'assurer. Mon jeu n'utilise que ça ou presque et tourne bien dessus. Essaie avec des pilotes plus récents situv'.
Merci encore !

Reply

Marsh Posté le 09-10-2004 à 14:23:25    

Si si, VBO est supporté par à peu pres tout ce qui existe sur le marché (meme par MESA).
Le driver est trop vieux, c'est tout. (ils en sont dans les 66.XX maintenant si je me souviens bien)
 
PS : je vais télécharger la chose ;)
 
edit : 11Mo c'est trop pour mon 56K  :(


Message édité par retrox le 09-10-2004 à 14:36:38
Reply

Marsh Posté le 09-10-2004 à 14:24:24    

ok j'essayerai (pas tout de suite)
 
pourtant les 43.45 sont pas si vieux, quand je l'ai acheter on etait meme pas  au detonator xp, ca devais etre les 12.xx
 
edit : a oui, deja 66.xx :D bon ok


Message édité par cris56 le 09-10-2004 à 14:25:19
Reply

Marsh Posté le 09-10-2004 à 14:27:52    

heu oui, je vois pas pourquoi une geforce 3 supporterai pas les VBO. (c'est qu'un container à vertex après-tout)

Reply

Marsh Posté le 09-10-2004 à 14:48:05    

héhé 600fps en fenêtré ça tourne pas trop mal :D
 
pour tes collisions, la bordure est gérée en 2D et tu testes les sommets de la bounding box de la voiture ?

Reply

Marsh Posté le 09-10-2004 à 15:33:57    

waouh, 600fps !
tu dois avoir au moins un 2200+ et une geforcefx. Me trompé-je ?
Humblement, j'ai passé pas mal de temps à optimiser mon bousin, j'entends par là les optimisations de l'efficacité des appels opengl. Il me reste encore une bonne marge de progression à réaliser avec tout les tests de cône de vision pour désactiver les objets non visibles. Ce sera mon tout dernier boulot.
 
Pour les collisions, non c'est pas ça. La barrière est gérée exactement comme les voitures, en 3d, au polygone près, mais le problème que tu sembles soulever (les voitures peuvent se rentrer un peu dedans) vient du simple fait que mon moteur physique ne sait pas encore gérer les rebonds après collision. Le test de collision est exact et exhaustif mais est sous-exploité par le moteur physique en somme.
 
Et en plein écran 1280x1024 par exemple, ça donne quoi ?

Reply

Marsh Posté le 09-10-2004 à 15:45:26    

9800pro et dudu 1600 passé en xp o/c à 2.2 (voir config)
 
attends je te dis pour le 1280x1024...

Reply

Marsh Posté le 09-10-2004 à 15:47:57    

280/300fps..

Reply

Marsh Posté le 09-10-2004 à 16:33:14    

Pas mal du tout !
Les commandes sont un peu déroutantes, par example j'ai du mal à tourner en freinant, et l'on tourne un peu trop facilement à basse vitesse, et parfois je n'y arrive pas à grande vitesse.
110 fps en 1152x864 XP1800 R9800 normale
Beau travail, les décors sont superbes, dommage qu'ils ne soient pas tjs visibles, faudrait un paysage différent, la route en bas on verrai mieux, en tout cas chapeau bas ;)

Reply

Marsh Posté le 09-10-2004 à 17:11:48    

Vraiment bien, malgrés la jouabilité selective, mais c'est le jeu
 
 
pourquoi pour le filtrage anisotropique tu le fais pas directe ?

Reply

Marsh Posté le 09-10-2004 à 17:12:42    

J'ai entre 85 et 110 fps en 1280*1024 sur un 1800+ gf4ti4200.
Même remarques pour les controles que Cricri_


Message édité par WhatDe le 09-10-2004 à 17:13:17
Reply

Marsh Posté le 09-10-2004 à 17:42:52    

Hihi, merci à mes admirateurs chaque instant plus nombreux. Merci merci, vraiment, je vous aime tous. Ce que j'ai fait c'est grâce à vous, merci à tous.
 
Hem...
Alors bon, il y a deux problèmes, premièrement les roues arrières sont directionnelles. A basse vitesse elle s'opposent aux roues avant pour tourner plus vivement, à moyenne vitesse elles sont passives, et à haute elles accompagnent les roues avant pour baisser la vivacité des coups de volants et augmenter la stabilité de la bagnole. Du coup il est effectivement plus facile de tourner à basse qu'à haute vitesse, c'est une sorte d'aide à la conduite car à haute vitesse, mon moteur physique est assez intraitable sur les ecarts de trajectoires et la perte d'adhérence survient vite ce qui se traduit immanquablement par un "décollage" de la voiture. Son contrôle est totalement perdu, et la voiture file tout droit. La seule manière de récupérer le pilotage, c'est de ramener les roues dans le sens du déplacement pour récupérer de l'adhérence. Autrement les freins sont inopérants.
Je sais que c'est un peu de la bidouille, mais c'est le seul défi que propose mon jeu actuellement, celui de savoir trajecter à la limite de la perte d'adhérence. Lorsque j'aurai un vrai moteur physique (c'est le 2e problème) les choses seront vraiment différentes. D'ailleurs ça tombe bien, je devais en acheter un ce soir chez aldi.
 
pour le problème de l'aniso, j'avoue que je ne m'y suis pas encore penché, je ne sais pas comment faire pour l'activer en opengl. Mais ce serait surement bien de l'intégrer. Vouich.
 
ps: 110 fps en 1152x864 sur une radeon 9800, ça me paraît peu. Je tablerais plutôt sur du 200. Tu as du fsaa ou de l'aniso activé ?
 
pps: alors ? qui va tester le multijoueur en premier ? Moi je décline, je n'ai qu'un pov 56k provisoire.
 
ppps: parler d'aniso, je sais pas pourquoi, mais ça m'a donné soif.

Reply

Marsh Posté le 09-10-2004 à 17:49:06    

john_john a écrit :


ps: 110 fps en 1152x864 sur une radeon 9800, ça me paraît peu. Je tablerais plutôt sur du 200. Tu as du fsaa ou de l'aniso activé ?


 
Heuuhhh ... je n'ai pas fsaa dans opengl, y a aniso de coché, ce sont les réglages par défaut je n'y connais rien ...
et je suis en 16 bits pour l'affichage.

Reply

Marsh Posté le 09-10-2004 à 17:54:14    

pour l'aniso :
 
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 2.0f);  
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);  
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_LINEAR);  
 
sur la texture courante

Reply

Marsh Posté le 09-10-2004 à 18:02:22    

Ah ouais, c'est clair, chuis tout con passé à côté. C'est décoiffant de complexité.
Merci mec ! Je croyais que c'était plus complexe que ça.
 
pour cricri_ : pour info, fsaa = antialiasing = anti-crénelage en français du massif central. Et si tu as en plus de l'aniso 4 ou 8x, c'est normal que tes performances chutent un peu. Par contre, 16bits en affichage c'est un peu ... démodé, je te conseille vivement 32. Tu as tout à y gagner.

Reply

Marsh Posté le 09-10-2004 à 18:08:18    

ben entre 16 et 32 bits (pour le mode video) je sais pas si on  vois vraiment une difference (je parle pas de la profondeur des texture)
 
mais en 16 bits ca pourra etre legerement plus performant vu que les frame buffer (en double ou en triple) sont moins  gros -> gains en bande passante
 
corrigez moi si je me trompe


Message édité par cris56 le 09-10-2004 à 18:08:56
Reply

Marsh Posté le 09-10-2004 à 18:12:52    

oui & non.
 
les contrôleurs mémoire des cartes actuelles sont optimisés pour un format pixel de 32bits.
 
vu la résolution des textures employées, je doutes que la bande-passante soit la limite sur une carte moderne (disons rad9800).
 
après tu t'en fous, tu laisse l'option à l'utilisateur.
 
par contre oublie l'antialiasing en 16bpp. (remarque ça dépends de la technique utilisée)

Reply

Marsh Posté le 09-10-2004 à 18:14:54    

Merci pour les infos ;)
 
J'ai esayé de bricoler avec ces options mais ça n'a pas l'air de changer grand chose, j'ai tout remis à préférences de l'application.


Message édité par cricri_ le 09-10-2004 à 18:15:08
Reply

Marsh Posté le 09-10-2004 à 18:26:22    

bjone > ok
 
j'ai pas trop compris comment etait foutu la lumiere (celle qui bouge, plutot speculaire), des fois  on dirais qu'elle suit la voiture, puis elle disparait et reapparais par intermitance...
 
c'est dommage car c'est ce qui met en valeur le bump mapping (pour les ombres projettés ca doit etre une lumiere fixe je suppose)
donc des fois ya pas de lumiere et la route est toute noir, on voit aucun details

Reply

Marsh Posté le 10-10-2004 à 01:25:43    

Euuuuuh g pas tout lu mais g cru comprendre que tu faisais ta physique. Si ton but c'est juste de faire le jeu, pourquoi ne pas utiliser une lib ? Y'a Tokamak qu'est gratuit, et ODE qu'est open-source (Tokamak est nettement plus rapide).

Reply

Marsh Posté le 10-10-2004 à 03:25:23    

bah la curiositée je suppose :D

Reply

Marsh Posté le 10-10-2004 à 10:16:50    

Oui sinon il aurait probablement utilisé un moteur 3d tout fait aussi.

Reply

Marsh Posté le 10-10-2004 à 14:51:21    

Citation :

bjone:
bah la curiositée je suppose :D


Ouich, quelque chose comme ça.
 
Pour ce qui est du problème de la lumière sautillante sur la route, je sais qu'il y a un pitit soucis, comme si la lumière bougeait selon nos propres mouvements.
En réalité, comme on est collé sur la route lorsqu'on conduit, les demi-vecteurs H utilisés dans le calcul spéculaire varient très violemment d'un vertex à un autre d'un même polygone. Je dois encore investiguer mais c'est le coeur du problème je crois. Il suffit de passer en mode caméra libre et de s'élever suffisamment pour s'apercevoir que ce problème disparaît et que l'effet spéculaire est enfin correct.

Reply

Marsh Posté le 10-10-2004 à 14:56:10    

La version Linux, la version Linux ! :)

Reply

Marsh Posté le 10-10-2004 à 15:19:10    

john_john a écrit :

Citation :

bjone:
bah la curiositée je suppose :D


Ouich, quelque chose comme ça.
 
Pour ce qui est du problème de la lumière sautillante sur la route, je sais qu'il y a un pitit soucis, comme si la lumière bougeait selon nos propres mouvements.
En réalité, comme on est collé sur la route lorsqu'on conduit, les demi-vecteurs H utilisés dans le calcul spéculaire varient très violemment d'un vertex à un autre d'un même polygone. Je dois encore investiguer mais c'est le coeur du problème je crois. Il suffit de passer en mode caméra libre et de s'élever suffisamment pour s'apercevoir que ce problème disparaît et que l'effet spéculaire est enfin correct.


 
c'est soit un problème de normalisation, soit de la manière dont tu calcules le vecteur vue.
 
en fait pour ton bump, normalement tu ramènes le vecteur vue et lumière dans le repère du vertex par vertex (logique), ces deux vecteurs sont interpolés (et se retrouvent potentiellement dénormalisés) par pixels, et ensuite par pixel tu fais tes scalaires entre ces vecteurs (via le half-way).
 
enfin bref, tu as deux problèmes:
 
1) dénormalisation potentielle
2) vecteur vue imprécis si proche d'un gros triangle
 
de manière générale tu auras plus de précisions sur une radeon 9500+ / geforce fx.
 
en fait le maximum de précision viens en interpolant la base de chaque vertex ainsi que la coordoonée spaciale, le tout par pixel, afin de calculer le vecteur vue->coordoonée spaciale et lumière->coordoonée spaciale, et de les ramener dans le repère texture, ce par pixel.
 
au lieu, de ramener la vue et la lumière dans le repère texture par vertex.
 
je sais j'ai expérimenté la chose sur mon propre code, et pour les cas où la caméra est très proche des triangles bumpés, c'est ce qui génére le max de précision.
 
mais oublie la chose sans radeon 9500+/geforce fx.

Reply

Marsh Posté le 10-10-2004 à 15:19:51    

tu as aussi du banding un peu partout, enfin bref, vive les cartes en virgule flottante par pixel.

Reply

Marsh Posté le 10-10-2004 à 16:05:35    

Voici le programme qui s'occupe de l'effet spéculaire de la route:

Code :
  1. "!!ARBvp1.0\
  2. OPTION ARB_position_invariant;\
  3. ATTRIB iPos             = vertex.position;\
  4. ATTRIB iColor         = vertex.color;\
  5. ATTRIB iNormal          = vertex.normal;\
  6. ATTRIB iTexCoord0 = vertex.texcoord[0];\
  7. ATTRIB iTexCoord1 = vertex.texcoord[1];\
  8. ATTRIB iTexCoord2 = vertex.texcoord[2];\
  9. ATTRIB iTexCoord3 = vertex.texcoord[3];\
  10. ATTRIB coordS  = vertex.attrib[12];\
  11. ATTRIB coordT  = vertex.attrib[13];\
  12. PARAM  lightPos  = state.light[0].position;\ #pos. lumiere
  13. PARAM  eyePos      = state.light[1].position;\ #pos. observateur
  14. TEMP  halfVector, vertexToLight, vertexToEye;\
  15. OUTPUT oColor  = result.color;\
  16. OUTPUT oTexCoord0 = result.texcoord[0];\
  17. OUTPUT oTexCoord1 = result.texcoord[1];\
  18. OUTPUT oTexCoord2 = result.texcoord[2];\
  19. OUTPUT oTexCoord3 = result.texcoord[3];\
  20. \
  21. # calcul du vecteur L(lumiere) \n\
  22. SUB vertexToLight, lightPos, iPos;\
  23. DP3  vertexToLight.w, vertexToLight, vertexToLight;\
  24. RSQ  vertexToLight.w, vertexToLight.w;\
  25. MUL  vertexToLight.xyz, vertexToLight.w, vertexToLight;\
  26. \
  27. # calcul du vecteur E(vue) \n\
  28. SUB vertexToEye, eyePos, iPos;\
  29. DP3  vertexToEye.w, vertexToEye, vertexToEye;\
  30. RSQ  vertexToEye.w, vertexToEye.w;\
  31. MUL  vertexToEye.xyz, vertexToEye.w, vertexToEye;\
  32. \
  33. # calcul du vecteur H(demi) \n\
  34. ADD halfVector, vertexToLight, vertexToEye;\
  35. \
  36. # calcul des coordonnees de textures du cubeMap\n\
  37. DP3 oTexCoord0.x, coordS, halfVector;\
  38. DP3 oTexCoord0.y, coordT, halfVector;\
  39. DP3 oTexCoord0.z, iNormal, halfVector;\
  40. \
  41. MOV  oColor, iColor;\
  42. MOV oTexCoord1, iTexCoord1;\
  43. MOV oTexCoord2, iTexCoord2;\
  44. MOV oTexCoord3, iTexCoord3;\
  45. END";


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 ?

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed