Discussion :

[zenux]

Bonjour,

Je developpe un petit moteur 3D et suivant la scène à afficher, il peut y avoir entre 0 et 100 lampes qui affectent la scène.
J'aimerais transférer les informations (position, couleur, etc) de ces lampes à mon fragment shader GLSL.

Pour l'instant, dans mon shader, j'ai ceci: "uniform vec3 lightPosition[100];" au cas où ma scène devrait afficher 100 lampes !
N'y a-t-il pas une solution plus clean pour avoir un 'uniform' avec une taille variable ?

Merci d'avance.

[AuraHxC]

Il me semble que les tableaux en GLSL doivent être des tableaux de taille fixe donc connu à la compilation => j'en suis plus sûr mais il me semble que j'avais lu ça dans la spec car j'avais eu le même soucis.
Le seul moyen que je vois pour obtenir un semblant de tableau dynamique serait d'utiliser une texture comme un tableau d'information autre que des couleurs.

[zenux]

Merci pour votre réponse.

J'avais déjà pensé à l'idée d'utiliser une texture mais je trouve cela assez lourd et pas très beau. Si personne n'a d'autre proposition, je serai forcé d'utiliser une texture

[LittleWhite]

Bonjour,

Moi je doute sur la nécessité de passer 100 lampes dans un shader. Est-ce qu'une technique de G-Buffer ne serait pas plus éfficace.
Le G-Buffering est une technique en deux passe, une pour rendre la scène dans une texture, l'autre pour appliquer des lumières sur la texture (à peu près).

Sinon, la solution de la texture me semble approprié (quitte à utiliser une texture 1D)

[pyros]

Passer une texture à un shader ce n'est pas sale

Une texture est juste un tableau 1/2/3D de valeurs. Ok, dans 99% des cas, c'est une image, mais dans l'absolue ça reste un tableau de valeur et la manière la plus efficace d'envoyer des grosses données au shader.

[oxyde356]

Dans le cas du forward rendering, personnellement j'utiliserais les deux méthodes. D'abord un tableau pouvant pas exemple contenir 8/16/32 lampes et si ce buffer est plein (il suffit d'avoir un uniform indiquant le nombre de lampes utilisées), alors continue d'extraire les lampes via une texture. Etant donné que l'accès à un uniform est bien plus rapide qu'un texture fetch tu y gagnera surement mais c'est un peu plus compliqué à coder.

[math_lab]

Je sais bien que les GPU ont pas mal gagné en puissance, mais avoir une centaine de lampes a gérer en forward rendering, ça me semble un peu trop costaud. Surtout que dans la plupart des cas, j'imagine que t'auras pas plus de 4 lampes qui affecteront un objet. Donc soit tu découpes ta scène en petits morceaux qui auront leur lampes a eux (c'est ce qui se faisait a l’époque de doom 3 et far cry), soit tu passes en deferred shading (ce qui se fait très souvent sur les jeux récents). Bon après, tu peux toujours essayer de voir avec la méthode bourrin, mais a mon avis, ça va faire mal.

[zenux]

Merci pour vos réponses.

Moi je doute sur la nécessité de passer 100 lampes dans un shader. Est-ce qu'une technique de G-Buffer ne serait pas plus éfficace.
Le G-Buffering est une technique en deux passe, une pour rendre la scène dans une texture, l'autre pour appliquer des lumières sur la texture (à peu près).

Si je comprends bien: tu parles du deferred shading ? C'est ce que je fais actuellement dans mon moteur 3D mais je ne vois pas en quoi ça résoud mon problème. Il faudra quand même passer les lampes au shader qui affiche les textures, non ?

Etant donné que l'accès à un uniform est bien plus rapide qu'un texture fetch tu y gagnera surement

Pourquoi est-ce plus lent d'accéder à une texture qu'à un uniform ? Au final, ce n'est jamais qu'un tableau, non ?

Merci d'avance

[oxyde356]

Ce n'est pas la même zone mémoire.

[LittleWhite]

Si je comprends bien: tu parles du deferred shading ? C'est ce que je fais actuellement dans mon moteur 3D mais je ne vois pas en quoi ça résoud mon problème. Il faudra quand même passer les lampes au shader qui affiche les textures, non ?

Oui, je parle bien du deferred shading. Merci de m'avoir rappelé le nom.
Dans la technique de base, en deferred shading, les lampes sont dessiner avec un billboard de halo de lumière.
Donc, on peut généralement éviter de passer les informations des lampes.

Ainsi, je me demande donc, pourquoi vous vous en avez besoin.

[zenux]

Dans la technique de base, en deferred shading, les lampes sont dessiner avec un billboard de halo de lumière.
Donc, on peut généralement éviter de passer les informations des lampes.

Peux-tu détailler ce fonctionnement ?

D'après ce que je connais le deferred shading se fait en 2 passes:
1. On crée les textutes qui contiennent: normales, positions, couleurs diffuse, etc
2. On assemble toutes les textures et on effectue l'éclairage sur les pixels. On a donc besoin de transférer les données des lampes.

[LittleWhite]

2. On rassemble toutes les textures et on effectue l'éclairage sur les pixels. On a donc besoin de transférer les données des lampes.

Oui, mais dans cette phrase, pour faire les éclairages, on applique comme des particules. Ce que je veux dire, c'est que pour faire l'application de l'éclairage, on applique des textures, sur les zones ou la lumière se propage (point light).
Ainsi, on ne fait les calcul de lumière que sur les zones réellement éclairé (et que pour les lumières qui éclairent cette endroit).

http://fr.wikipedia.org/wiki/Deferred_Shading
http://http.developer.nvidia.com/GPU...ems3_ch19.html

[zenux]

Merci, je vais lire ces documents. Le deuxième à l'air particuliairement interresant
Comme tout à été dit dans ce sujet, je vais le résoudre.