Gérer les shaders "proprement"

Bonjour!

Alors voilà, je suis en train de coder un moteur de jeu, et j'ai réalisé tout à l'heure que ce qui me bloque vraiment est en fait de trouver un moyen efficace de rajouter des fonctionnalités pour l'affichage selon les envies du designer. Vous l'aurez peut-être compris, il s'agit de la gestion des Shaders.

Par exemple, je me vois mal créer un shader pour quand la scène contient 1-2-3 lumières. Je pourrais faire un tableau de lumières dedans et modifier ce nombre au début avant la compilation du shader. Mais après, si je veux modifier les textures et les lumières, il me faudra à chaque fois modifier et recompiler le shader... N'y aurait-il pas un moyen plus productif si l'on excepte de retourner à la "fixed pipeline"?

Il faut savoir que je bosse en Java avec la LWJGL, donc je suis du genre à éviter de faire des appels multiples à glUniformBlahBlah.(ce qui est de toute façon le cas aussi avec Qt, vu que glew ne veut pas fonctionner du tout pour je ne sais quelle raison)

Merci d'avance pour avoir pris le temps de me lire et qui sait, peut-être, de me répondre,
Cordialement,
Maxime

Citation:

---

Envoyé par hilaia

Il faut savoir que je bosse en Java avec la LWJGL, donc je suis du genre à éviter de faire des appels multiples à glUniformBlahBlah.(ce qui est de toute façon le cas aussi avec Qt, vu que glew ne veut pas fonctionner du tout pour je ne sais quelle raison)

---

Je doute fort que tu ne saches le faire rapidement sans utilise glUniform... mais peut être ais-je tort. LWJGL ou pas ;)

Oui ça c'est sûr, je ne veux pas les éviter totalement mais en faire le moins possible. Par ailleurs, j'aurais aimé savoir quand les variables sont communes entre différents shaders(ça arrive assez souvent, c'est rien que pour les attributs qui ont des places en mémoire relativement simples?)

Merci pour votre attention

A part si tu veux effectivement écrire un shader par matériau - en supposant qu'un matériau n'est visible qu'à un seul endroit de la scène, avec un nombre déterminé et immuable de lumières - tu seras obligé de passer par les glUniformXXX.
Le passage par ces fonctions te permettra d'avoir un shader par type de rendu (rendu "normal", bump/normal mapping, relief mapping, post-FX, ...)
Pour mon moteur, j'ai tout un set de variables uniform prédéfinies par le moteur. Ces variables contiennent entre autres les informations de matériau (ambient, emissive, shininess, specular, diffuse) et les informations des lumières (stockées dans une texture). A partir de là je peux, avec un même shader, rendre des objets situés dans des scènes complètement différentes. On appelle ça la réutilisabilité du code :P.

Pour ta 2ème question, il n'y a qu'en OpenGL 2.x qu'il existe des variable "attribute"communes. C'était couplé avec les fonctions glVertexPointer, glColorPointer, ... qui permettaient d'utiliser dans un shader les variables glVertex, glColor.
Ces fonctions étant dépréciées en 3.X, on utilise maintenant glVertexAttribPointer, qui elle prend le nom de la variable concernée par le buffer donné.

En conclusion, c'est à toi de définir les variables "communes" entre différents shaders (seuls les noms seront communs). Par exemple j'ai comme noms de varaibles uniform "c3d_v4MatAmbient", "c3d_iLightsCount"...

il faudrait alors travailler avec les Constant Buffers (DirectX) ou Uniform Buffer Object (OpenGL)
(http://www.jotschi.de/?p=427)
je vois bien quelque chose du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct LightInfo { vec3 position; vec3 direction; vec3 color; float angle; }; layout(std140) uniform lightBuffer { int nbLights; //entre 0 et 10 LightInfo lights[10]; };

---

Aaah, super les gars, merci.

J'avais oublié que j'avais déjà lu quelque chose sur les textures pour les lumières.

Et je pensais surtout aux variable uniform, pas attribute, quand je parlais de variables "dupliquées" dans des shaders, vu que j'utilise également glVertexAttribPointer. Je sais pas y'a des trucs bizarres des fois quand on fait pas glUniformXX à chaque changement de shader.

@screetch: là ce que j'aime moins c'est le fait d'avoir un nombre "cappé" de lumières... dans une texture(paramétrées en GL_NEAREST) je me vois bien mettre l'inverse du nombre en (0, 0) et faire un for jusqu'à atteindre 1.(grossièrement, je vais me documenter pour que ça reste performant))
Mais je vais quand même jeter un coup d'oeil :) .

Merci à vous!

il y a un minimum de 12 buffers supportes par shader, et chaque buffer peut faire 16 ko minimum (soit grosso merdo 256 Light comme presentee precedemment par buffer)

a mon avis tu arriveras pas a faire un forward rendering correct de 256 lumieres, mais comme tu preferes, la texture ca marchera aussi

Ok ça va, merci pour les infos, je regarderai ce soir dans quelle mesure cela peut-être mieux/plus clair que les textures... Perso je veux surtout un code bien propre ^^ j'imagine que niveau perfs il ne doit pas y avoir beaucoup de différence aussi.

De plus, j'essaye le plus possible que ce soit compatible avec OpenGL 2.1, pour un peu plus de portabilité, mais en utilisant les fonctions non-dépréciées quand même. Je changerai certainement bientôt mais je préfère être sûr de mon choix avant. C'est vrai que faire sans les FBOs c'est con mais c'est pas comme si je comptais pondre un méga jeu non plus pendant la LD.