Discussion :

[wokky]

(Re)Bonjour ,
Si j'ai bien compris il est impossible d'avoir plus de 8 lumières activé dans une scène en hardware, les jeux actuel en on plus je pense comment font-ils ? Sont ils obligés de créer un device en software ?

[Laurent Gomila]

De nos jours les lumières ne sont plus gérées avec le FFP, tout est en shader. Ce qui élimine cette limite de 8.

De toute façon il faudra tout de même que tu t'imposes une limite, car ça peut vite devenir très coûteux. Par exemple tu peux ne choisir que les X lumières qui contribuent le plus à la scène courante, et remplacer les autres par des fakes (billboard, etc..).

[wokky]

Et les jeux actuel sont ils basés uniquement sur les shaders ?( je veus dire par là qu'ils courcircuitent tout le temps le FFP).

[Laurent Gomila]

Pour l'éclairage dynamique, ça devient quasi-obligatoire.

Mais bon là on parle des jeux commerciaux, pour certains petits jeux amateurs tu pourras très bien t'en tirer sans sortir autrement.

[wokky]

Je me suis fixé de gros objectifs, et ca prendra le temps qu'il faudra je suis pas pressé, j'essaye de comprendre toute les techniques qu'un jeu "pro" peut utiliser afin de faire des rendus de nos jours qui sont incroyable. Sachant que tu es le "master" de cette catégorie et moi un "newbe" motivé, je voulais savoir si ca serait plus utile que je fasse un topic personnel qui vont regrouper mes questions dans le futur car ca m'embête un peu de devoir créer un topic à chaque fois (et c'est pas très ésthetique ) ou bien de discuter par messagerie instantannée, ca peut paraître bizarre mais je pense que cela peut être bénéfique d'avoir un "mentor".

[Laurent Gomila]

Tant qu'on reste sur le même sujet (par exemple les lumières) inutile de créer de nouveaux sujets, mais si tu veux des infos sur autre chose il vaut mieux créer une nouvelle discussion.

[bafman]

si tu veut voir comment sont géré les lumières non FFP, j'ai fait toute une série de tutos la dessus. C'est en OpenGL, mais les principes restent les même, ce sont justes les appels à l'API qui changent.
le tout se trouve ici

[wokky]

Donc pour résumer si j'ai bien compris les jeux actuel "pro" n'utilise jamais le ffp que ce soit le vertex processing ou le pixel processing pendant tout les rendus ? donc dans chaque vertex shader on doit implémenter la phase de T&L ?
Et merci bafman pour ce renseignement

[Laurent Gomila]

Donc pour résumer si j'ai bien compris les jeux actuel "pro" n'utilise jamais le ffp que ce soit le vertex processing ou le pixel processing pendant tout les rendu ? donc dans chaque vertex shader on doit implémenter la phase de T&L ?

C'est ça.

[wokky]

Mais admettons que je veuille uniquement "modifier" l'éclairage par shader et garder la transformation par défaut du FFP, car faire une transformation par le FFP à l'air beaucoups plus simple en definissant les matrices world, view, projection.
Ca me parrait bizarre que si à chaque fois que l'on veut faire par exemple un "effet" de lumière on est obligé d'implémenter dans le shader la transformation (ou vice versa).
Ex: Une primitive utilise le meme système d'éclairage sur ses vertices mais pas la meme transformation, ca veut dire que chaque shader qui va modifier la position va se retrouver avec le meme code pour l'eclairage.

[Albenejean]

Un vertex shader remplace les parties transformation et éclairage du FFP. Si tu utilise un vertex shader, tu désactive ces deux fonctions.

D'un autre côté la partie transformation n'est vraiment pas la plus compliqué des deux parties...

[wokky]

Vaut il mieux coder différents effets séparement ou tout dans un le shader et faire des tests (conditions) ?

[MorpheuxDX]

Mais admettons que je veuille uniquement "modifier" l'éclairage par shader et garder la transformation par défaut du FFP, car faire une transformation par le FFP à l'air beaucoups plus simple en definissant les matrices world, view, projection.
Ca me parrait bizarre que si à chaque fois que l'on veut faire par exemple un "effet" de lumière on est obligé d'implémenter dans le shader la transformation (ou vice versa).
Ex: Une primitive utilise le meme système d'éclairage sur ses vertices mais pas la meme transformation, ca veut dire que chaque shader qui va modifier la position va se retrouver avec le meme code pour l'eclairage.

Si tu codes les shaders directement en asm, tu peux séparer les Pixel shader d'un coté
(travail uniquement sur la sortie graphique dans le pipeline de chaque pixel),
et les Vertex Shader (tu travailles sur les vertices a proprement parler).

Dans ce cas, tu peux garder la transformation FFP (pipeline standart) en utilisant uniquement
que les PixelShader.

Maintenant, est-ce que cela va vraiment t'aider pour ton problème lié a l'affichage de tes
éclairages, je ne suis pas sur... maintenant, les transformations en passant par
les VertexShader n'est pas si sorcié, et tu emploi de toute façon la plupart du temps
les matrices de base dont tu parles (View, Projection, World), que tu passe en parametre a ton shader.

[nicroman]

Donc pour résumer si j'ai bien compris les jeux actuel "pro" n'utilise jamais le ffp que ce soit le vertex processing ou le pixel processing pendant tout les rendus ? donc dans chaque vertex shader on doit implémenter la phase de T&L ?

Exactement...

A noter que 90% des cartes "2.0" (et 100% de celles "3.0+") n'ont carrément pas de FFP...
Le driver se charge de "traduire" le FFP en vertex-shader / pixel-shader.

Donc si l'API que tu utilises propose un FFP, et que celui-ci te suffit, rien ne t'empêche de l'utiliser... ca n'ira ni plus vite, ni moins vite...

Quant aux lumières...
Ce qui est fait dans la plupart des jeux actuel est, pour chaque objet, on va trier les lumières par ordre d'importance.
- On considère les N-1 lumières les plus importantes pour un objet, qu'on va utiliser telles quelles.
- La lumière N, selon que sont facteur d'importance est plus ou moins proche de celui de N-1 ou N+1, va être utilisé 'normalement' avec ce facteur.
- Le "reste" du facteur va être "baké" dans une spherical-harmonic, ainsi que toutes les autres lumières de la scene...

Et voilà... un shader avec N lumières + spherical harmonic...
Reste à déterminer le "meilleur" N (et avoir un bon algorithme de tri des lumières).
Personnellement:
N=1 donne de mauvais résultats.
N=2, c'est 1 seule lumière "pleine"... pas terrible
N=3, ca commence à avoir de la gueule.
N=4, ca à l'air parfait
N=5, je vois pas la différence avec N=4