Discussion :

[skeud]

Ok nickel, ça répond exactement à ma question.

Mais du coup, ce n'est pas les shaders qui vont réellement implémenté la lumière, ils vont juste définir la manière dont la matière (à qui l'on applique le shader) va refléter la lumière?

Autrement, dis, si je rajoute deux objets simples dans ma scène (un plan et une sphère) avec une lumière au dessus. Sans shader, je vais avoir l'ombre de la sphère sur le plan non?
En rajoutant les shader, je pourrais définir des perturbation de normal par exemple pour simuler l'eau.

Ais-je bien compris?

[maeiky]

Mais du coup, ce n'est pas les shaders qui vont réellement implémenté la lumière, ils vont juste définir la manière dont la matière (à qui l'on applique le shader) va refléter la lumière?

Pas vraiment normalement quand tu en utilise un tu n'utilise pas l'autre.

Les shaders permettent plus de contrôles et par conséquence c'est plus de travail.
Tu peux te faire une lumière Lolilolight (approximation d'approximation) ou généralement quelque chose au pixel près en relation avec la matière. Donc oui la lumière est dans les shaders directement ou "deferred".

[skeud]

Ok donc avec les technique actuelles d'openGL, c'est le shader qui définira la couleur du pixel de l'objet?

J'ai fait beaucoup de rendu 3D en raytracing, mais je suppose que le calcul des couleur/ombre/reflexion ne se fait pas de la même manière?

Mais comment le shader connait les points de lumière? Ce n'est pas des objets gérés par openGL? (que l'on définis bien sur)

Car si j'ai bien compris, on lie un shader à un objet, et lors du calcul du rendu de l'objet, on appelle le shader pour chaque "pixel" de l'objet rendu à l'écran?

C'est bien openGL qui s'occupe de définir quel "pixel" de l'objet est visible à l'écran non? Pourquoi n'est-ce pas openGL dans ce cas qui s'occuperait de détecter l'intersection avec un objet entre le pixel rendu et l'origine de la lumière? (Je parle ici de lumière directive et non ambiante).

[NevilClavain]

Mais du coup, ce n'est pas les shaders qui vont réellement implémenté la lumière, ils vont juste définir la manière dont la matière (à qui l'on applique le shader) va refléter la lumière?

Ca va plus loin qu'une histoire de lumière, avec les shaders tu "prend le contrôle" du GPU, et c'est toi qui fixe les règles du rendu, pixel par pixel, avec de la lumière ou autre chose si tu veux
ex : il est possible de faire un shader générant uniquement un effet de brouillard, sans éclairage particulier.

Sans shader, je vais avoir l'ombre de la sphère sur le plan non?

Non, sans shaders, tu n'aura rien à l'écran (sauf erreur)

Ok donc avec les technique actuelles d'openGL, c'est le shader qui définira la couleur du pixel de l'objet?

J'ai fait beaucoup de rendu 3D en raytracing, mais je suppose que le calcul des couleur/ombre/reflexion ne se fait pas de la même manière?

Mais comment le shader connait les points de lumière? Ce n'est pas des objets gérés par openGL? (que l'on définis bien sur)

Car si j'ai bien compris, on lie un shader à un objet, et lors du calcul du rendu de l'objet, on appelle le shader pour chaque "pixel" de l'objet rendu à l'écran?

C'est bien openGL qui s'occupe de définir quel "pixel" de l'objet est visible à l'écran non? Pourquoi n'est-ce pas openGL dans ce cas qui s'occuperait de détecter l'intersection avec un objet entre le pixel rendu et l'origine de la lumière? (Je parle ici de lumière directive et non ambiante).

Peut être devrais tu ouvrir un autre topic en reposant tes questions pour continuer la discussion, on est sur le fil de lolilolight ici, il risque de râler

[Invité]

Projet en pause car mon PC est en réparation. :/ Je reprendrai lorsque je récupérerai mon PC.

Je pense me pencher plutôt sur l'IA du jeux développer avec mon moteur à l'avenir pour ainsi finir mon rpg en 2D iso.

Bien entendu je memettrai à la 3D juste après en rajoutant une interface graphique au moteur dans le but de créer des modèles en 3D.

Dès que j'aurai récupérer mon PC (ou acheté un nouveau), je pourrai peut être effectuer des opérations atomiques au niveau du GPU, et donc, faire du batching au niveau du CPU.

J'envisage donc d'abandonner mesa pour l'instant, et me consacrer à des drivers plus à la pointe, qui me pemettront d'avoir un meilleur FPS et donc, de pouvoir afficher plus de polygônes avec les effets de la 2D. (gestion de la transparence (order independant transparency), brouillard, réfraction, éclairage, ombrage, etc...)

J'en ai marre de devoir envoyer mes tiles par sections, plutôt que de faire du batching et de pouvoir remettre à jour mes textures pixel par pixel plutôt que section par section.

Avoir plus decontrôle sur le GPU est toujours mieux, et ça, ça ne passe pas sans l'opengl moderne. (>= à la version 4.2)

[Invité]

Salut!

J'ai été faire réparé mon PC avec l'argent reçu à mon anniversaire, et donc j'ai pu réinstaller windows.

Mon driver supporte bien la version 4.2 d'openGL.
Je vais donc pouvoir optimiser tout ça avec du batching ainsi que les opérations atomiques.

Je suis donc à la recherche de bons tutoriels sur les per pixels linked list, car je n'ai jamais utilisé cela.

PS : je ne trouve aucun tutoriel la dessus, pas pour le driver AMD en tout cas. :/

[Iradrille]

PS : je ne trouve aucun tutoriel la dessus, pas pour le driver AMD en tout cas. :/

http://developer.amd.com/resources/d...-publications/

Et plus particulièrement OIT and GI using DX11 linked lists: Nick Thibieroz & Holger Grün (2010).

Les exemples utilisent DX11, mais c'est exactement la même chose avec OpenGL : faut juste convertir le code HLSL en GLSL.

[Invité]

Ok, hé bien je vais essayer de convertir le code alors.

[Invité]

Salut!

Purée c'est infâme windows!

J'essaye de compiler ma librairie, déjà en console il ne veut pas.
Il me dit qu'il ne trouve pas le répertoire d'include de openSSL même en la mentionnant dans la variable d'environnement Path.

Alors j'essaye de compiler ma lib sous code::blocks et là je me retrouve avec une erreur de compilation hors que ça compile parfaitement sous ubuntu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
bool onIntersects (BaseInterface& interface, CollisionResultSet::Info& info) {
                    return interface.intersects(*this, info);
                }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

D:\Projets-c++\ODFAEG\include\odfaeg\Physics\boundingSphere.h|42|error: expected ',' or '...' before 'struct'|

Pourtant la structure existe bien!

Le jour ou le driver propriétaire de AMD fonctionnera avec ubuntu, je réinstalle ubuntu et je vire cette **** de windows.

Il ne me trouve aucun fichier d'en tête en mode console hors que j'ai bien mentionné dans la variable path leur localisation, et encore, je n'en suis même pas encore au linkage avec les fichiers .dll, ça, ça me fait aussi péter un câble.

(Et pourtant c'est cette plateforme qu'il faut utiliser dans le domaine commercial. :/ )

[foetus]

Parce que tu es un jeune Padawan

Il y a un fichier bat "vsvars32.bat" (<- ou un nom similaire) livré avec Visual qui permet de définir toutes tes variables d'environnement.

De plus, sous Windows, la commande est obsolète [à ce que j'ai compris]: il faut utiliser nmake.

Par contre tes sources ne sont pas sous nmake

[skeud]

Ptite remarque à la noix, mais ça ne serait pas à cause des retours charriots windows et unix qui diffèrent?

[Invité]

Bon, tant pis, je jette l'éponge, de toute façon c'est n'importe quoi, ça compile très bien sous ubuntu avec make, alors pourquoi ça ne le fait pas sous windows avec mingw32-make.

Bref, je repasserai sous ubuntu plus tard lorsque les drivers graphique propriétaires fonctionneront sur cette plateforme.

En attendant je pense que je vais juste faire des codes sources simple, utilisant les fonctionnalités de opengl 4.2 (sans passer par une lib) histoire de m'exercer un peu avant de les inclure dans mon framework.

[Invité]

Salut,

la version windows ne compile pas, il y a un temps j'arrivais à compiler ODFAEG sur windows sans problème mais ici :
-A la compilation de openSSL (une dépendance de ODFAEG) sur MSYS il me sort une erreur du style undefined reference to winmain@16.
-Lors de l'exécution d'un code minimaliste en openGL 3.3 le programme plante.
-Windows ne trouve pas les répertoires include des dépendances même en les renseignant dans la variable PATH.

Que ça soit avec TDM-GCC-32 en mode console ou bien avec visual studio la compilation échoue...

Je compte donc continuer à développer le moteur sous linux et abandonner la version windows, de toute façon avec virtual box il y a moyen d'exécuter les projets, même sous windows.

[Invité]

Je viens de regarder un code GLSL qui utilise une liste de fragments et je pense avoir enfin trouvé une solution!

Rien ne m'empêche de déclarer un tableau de fragments pour tout les fragments :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
vec4 fragmentList[ABUFFER_SIZE];

Je pourrai alors à chaque rendu, stocker la couleur du fragment dans un tableau (en espérant que à chaque nouvel appel à draw les variables du fragment shader ne sont pas réinitialisées), trier le tableau et appliquer l'alpha blending.

Est ce que c'est possible de faire cela même avec des anciennes version d'openGL, autrement dit, puis je garder en mémoire la couleur des fragments dessinés précédemment dans un tableau (et non plus dans une texture), afin de trier ce tableau et ensuite appliquer le blending ?

Ca donnerait quelque chose comme ça

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
//Insère le fragment dans la liste de fragments qui se superposent.
insererFragment(fragmentList, currentFragColor, nbFrags);
//Tri de la liste de fragments du plus éloigné au plus proche.
trierFragments(fragmentList, nbFrags);
//Application de l'alpha blending dans l'ordre. 
appliquerAlphaBlending(fragmentList, nbFrags);

Ou bien est ce impossible à faire sans image_store_load ?

Merci d'avance pour votre aide.

PS : Ha oui et aussi, y a t'il moyen de gérer une liste chaînée en GLSL ?

[Invité]

J'espérais pouvoir déclarer des variables globale pour chaque fragment, mais en fait ce n'est pas possible, la portée des variables est toujours limitée à la durée de l'exécution du shader et donc, à la fin du draw elles sont libérées.

Cependant, je pense que il y a quand même moyen d'optimiser.

Je pense créer une texture 3D plutôt que de faire appel à glbindtexture, et ne faire qu'un seul draw, ainsi, une seul invocation du shader, donc, la variable locale du shader ne sera pas libérée tant que la scène ne sera pas entièrement dessinée!

Bref, il faut que j'essaye de nouvelles choses, que je trouve de nouvelles idées afin de faire la même chose qu'avec l'opengl moderne (bindless textures, order independant transparency) mais en gardant une compatiblité avec les cartes graphiques plus anciennes qui ne supporte pas l'opengl moderne.

Mais là, j'ai enfin des idées! (Après des mois ou je séchais)

[maeiky]

Pour les variables qui reste en mémoire, il y a les variables uniform, mais elles sont ultra limitées avec un tableau d'un maximum d'environ 1024 indices. Ensuite les UBO, encore une fois limité aux indice de 1024, mais avec la possibilité d'en combiner plusieurs, limité à quelques ko.

La seule solution viable c'est avec OGL 4 et les linked list :
http://blog.icare3d.org/2010/07/open...-lists-of.html

En fait, tu ne fais même pas attention au limitations, même avec OGL 4 ça consomme énormément de mémoire. On a pas toute des cartes graphique de plusieurs gigs, la plupart on seulement 1go, on arrive très vite au plafond.

En plus, tout ça est très couteux comme opérations :

Linked lists can be down to half the speed of the basic approach when per-fragment additional costs are low, due to the additional memory access and the increased complexity of the fragment shader (more code, more registers).

Je sens que tu vas tourner en rond encore bien longtemps.

[Invité]

Oui j'ai essayé de compiler ses exemples de code mais ça ne compile pas.

Bref, j'ai tenter de faire quelque chose de plus simple et de plus optimisé en faisant un tri par insertion, le problème c'est que imageStore ne semble pas fonctionné, rien n'est écris dans mes textures.

Donc bon je risque de tourner en rond encore bien longtemps ..., si je me penche sur les per pixels linked list ...

Mon algorithme avec le rendu par section et un blending top-down ou bien down-top selon le cas ou le fragment est devant ou derrière est le seul qui fonctionne sur mon PC.

Si il y a une tile intermédiaire ce n'est point grâve, car, si je blend du rouge avec du bleu ça donne du violet, et si la tile intermédiaire est verte je blend du violet avec du vert ce qui va me donner une couleur. Si je change l'ordre je vais blend du rouge avec du vert ce qui va donner du jaune et ensuite je blend du jaune avec du bleu ça va me redonner cette même couleur, donc ..., comme je calcule la couleur intermédiaire à chaque draw ça ne pose pas de soucis vu que je blend avec la couleur intermédiaire.

Le seul inconvénient reste les nombreux appels à draw que cela implique de dessiner par section. (Mais pour le moment je n'ai pas de solution pour les réduire et je ne pense pas qu'il y en ai une.)

La seule solution sont les opérations qui permettent aux shader d'écrire et de lire dans la texture directement mais malheureusement ça ne fonctionne pas avec mon driver, de plus, la version la plus récente de mon driver ne fonctionne pas, quand je l'installe, je me tape un écran trop sombre pour pouvoir faire quoi que ce soit, la version de mon driver actuelle date du 5 décembre 2011, je suis même surpris qu'elle supporte déjà opengl4.2.
Même si imageStore ne fonctionne pas car ça n'écris rien dans la texture. :/

Bref je tourne en rond depuis plusieurs semaines comme vous pouvez le voir, je pense repartir sous linux pour finir mon RPG.
Lorsque ubuntu sortira une mise à jour avec une version de mesa supportant opengl4.2, alors là peut être que je pourrai optimiser mais je ne suis pas sûr que les per-pixel linked lists soient plus rapide que un dessin par section.

[maeiky]

C'est désespérant tout ça, ça pas comme si je ne t'avais pas donné la solution plusieurs fois, mais tu t'efforce de faire le contraire, voilà ce que ça donne.

Si il y a une tile intermédiaire ce n'est point grâve, car, si je blend du rouge avec du bleu ça donne du violet, et si la tile intermédiaire est verte je blend du violet avec du vert ce qui va me donner une couleur. Si je change l'ordre je vais blend du rouge avec du vert ce qui va donner du jaune et ensuite je blend du jaune avec du bleu ça va me redonner cette même couleur, donc ..., comme je calcule la couleur intermédiaire à chaque draw ça ne pose pas de soucis vu que je blend avec la couleur intermédiaire.

Félicitation, tu peux effectivement calculer le blending Front 2 Back ou Back 2 Front, mais tu ne peux pas changer de sens en plein milieu en découvrant de nouveaux intermédiaires. Si tu persiste tu va continuer d’avoir un rendu tout crappy, mais continu t'es bien parti.

Le seul inconvénient reste les nombreux appels à draw que cela implique de dessiner par section. (Mais pour le moment je n'ai pas de solution pour les réduire et je ne pense pas qu'il y en ai une.)

Normalement tu devrais pouvoir faire tout ton rendu avec un seul drawcall, ou quelques uns si ta scène est plus complexe. C'est quoi cette limitation par section?

[Invité]

Si on laissait ce problème de transparence de côté car de toute façon je ne peux pas avancer là dessus pour l'instant. (Même si il y a des solutions que tu m'as déjà donna comme par exemple le tri, ça pose problème pour les scènes plus complexe avec nécessité de décomposer les polys qui s'entrecroisent (ce qui surcharge trop le CPU))
D'ou la nécessité de faire un tri par fragments au niveau du GPU!

Avec un seul draw call, je ne peux pas faire de readback, car pour faire du readback, j'ai besoin que la texture soit à jour dans mon fragment shader pour chaque tile que je dessine.

Transparence ou pas j'ai vraiment besoin de faire du readback et pas seulement pour effectuer du blending.

Mais bon l'alpha blending correct sera appliquer lorsque j'aurai les drivers opensource seront plus à jour, maintenant que je sais que ma carte graphique peut supporter l'extension image load store, je n'ai plus qu'à attendre.

De toute façon le temps que je comprenne comment fonctionne ma carte graphique et comment coder un driver, ubuntu aura déjà fait sa mise à jour.

Il est donc inutile que je tourne en rond plus longtemps, je vais donc mettre ce projet en pause pour un autre projet (je suis sûr que tu sais de quel projet je veux parler), quand la mise à jour d'ubuntu supportant opengl 4.2 minimum sera faîtes et fonctionnelle, je reprendrai ce projet.

Il y a encore tant de choses que j'aimerais rendre fonctionnel avec mon moteur tel que l'instanced rendering (pour faire le tout avec un seul draw call) et les opérations atomiques sur les textures avec mes fragments shaders.

[Iradrille]

Si on laissait ce problème de transparence de côté car de toute façon je ne peux pas avancer là dessus pour l'instant. (Même si il y a des solutions que tu m'as déjà donna comme par exemple le tri, ça pose problème pour les scènes plus complexe avec nécessité de décomposer les polys qui s'entrecroisent (ce qui surcharge trop le CPU))
D'ou la nécessité de faire un tri par fragments au niveau du GPU!

Ou une autre solution : laisse l'utilisateur se démerder avec ça. Il veut plein de trucs transparents ? Cool, mais il se démerde avec et gère lui même ces cas particuliers.