Discussion :

[skeud]

Perso je vois pas pourquoi tu fais autant de calcul dans tes fonctions, normalement, tu ne devrais pas avoir besoin d'autant d'instruction.

Tu pourrais clairement nous exposer ta manière de faire? Je veux dire par la, une sorte de pseudo-code logique, qui nous expliquerait les fonctions que tu enchaines. Car c'est à ce niveau là que ça pose problème je pense .

[Invité]

Ok, alors mon code fais ceci :

1)Pour tout les sommets, prendre les 3 sommets du triangles. (Cela dépend du type de primitive utilisée)
2)Transformer les sommets en coordonnées pixel. (avec les matrices de transformations, de vue, de projection et de viewport comme le fait opengl)
3)Rechercher la zone sur l'écran dans lequel est le triangle.
4)Pour chaque fragment du triangle, interpoler sa position en z, et tester si il est entre les plans zNear et zFar.
5)Si ce test passe, interpoler les couleurs, les coordonnées de textures, et toutes autre données des sommets.
6)Ensuite, appliquer le blending, par exemple dans mon cas le blending s'appliquerait comme ceci :

Si la couleur du fragment présent dans le framebuffer est vert (0, 1, 0, 1) et que l'on dessine un fragment rouge (1, 0, 0, 1) par dessus, alors, sa nouvelle couleur est :

(1 ,0 , 0, 1) * 1 + (0, 1, 0, 1) * 1 - 1 = SRCCOLOR * SRCALPHA + DSTCOLOR * 1 - SRCALPHA = (1, 0, 0, 1) + (0, 0, 0, 0) = (1,0, 0,1) = ROUGE.

Sinon, si la couleur du fragment présent dans le framebuffer est vert et que l'on dessine un fragment rouge par dessous, alors, sa nouvelle couleur est :

(0, 1, 0, 1) * 1 + (1, 0, 0, 1) * 1 - 1 = DSTCOLOR * DSTALPHA + SRCOLOR * 1 - DSTALPHA = (0, 1, 0, 1) + (0, 0, 0,0) = (0, 1, 0, 1) = VERT.

Ensuite, j'écris la position en z et la composante alpha du nouveau fragment dans le depthbuffer ainsi que sa couleur dans le framebuffer pour la passe suivante!

Mais ce n'est pas tout, après il y aura encore tout les calculs de lumière/ombre à faire. :/

Je suis entrain de me demander comment vais je faire pour faire cela de manière optimisée, surtout au niveau du CPU. :/

Peut être pourrai-je le faire avec le GPU mais pour le moment j'ai un gros problème de ce côté là que je viens juste de présenté.

[skeud]

Ok, ce que je vais faire, c'est d'essayer de faire un moteur de rendu avec opengl pour te montrer directement le code dont je parle, je pense que tu comprendras mieux de cette façon . J'essayerais de poster ça le plus vite possible .

[Invité]

Mais, faire l'inverse de ce que je fais c'est à dire envoyer un rayon du centre de la caméra vers chaque pixels du plan éloigné et puis faire un test avec chaque triangles des objets visible du monde ne serait t'il pas trop coûteux ?

Et si je fais des tests avec des sphere cela risque de donner des résultats trop approximatifs avec des cubes, non ?

Et puis cela serait quand même coûteux, je me demande bien qui fait ça dans les jeux.

[skeud]

Normalement, comme je te l'ais déjà dis et pour revenir à ton projet initiale, juste avec opengl tu peux le faire, avec un très bon FPS, c'est ta conception qui n'était pas bonne car tu faisais le boulot de openGL pour la gestion des lumière et compagnie, ce qui réduisait ton FPS et pouvais induire bon nombre de soucis.

Donc ce qu'il faudrait que tu fasses, c'est reprendre ce que tu faisais au début, avec juste openGL et sans shader, et sans lumière.
Une fois que cette partie est fonctionnelle, avec un FPS correct, tu rajoutes les lumières.
Une fois les lumières fonctionnelle, tu rajoute les shader pour avoir un rendu plus réaliste.

Et de cette manière tu te retrouveras avec un moteur de rendu, certes moins performant que ceux actuel, mais très correct pour un moteur amateur.

Ton problème c'est que tu veux tout rajouter d'un coup, et non pas par étape .

[Invité]

Oui, je vais le faire avec opengl parce que faire ça avec le CPU c'est pire niveau FPS.

Il faut juste que je trouve pourquoi j'ai ce problème avec l'alpha, après j'attaquerai les lumières, ça me surprend quand même beaucoup que je n'ai pas les même résultats avec le rendu CPU et GPU, peut être une erreur dans mon shader...

Sans shader ça marche bien pour autant que je fasse un tri.

Ca me surprend que mon blending ne marche pas dans le shader. :/

[Invité]

Bon, j'ai trouvé ce qui faisait tout foiré, en fait c'est lorsque t'installe ubuntu t'a une option qui te propose d'installer quelques librairies propriétaires, entre autre, pour la carte graphique, j'ai réinstallé ubuntu en décochant cette option et maintenant j'ai bien le même rendu que j'avais avant.

Erf ne jamais installé des librairies propriétaire sur des systèmes non propriétaire (ou l'inverse), c'est comme installer un système non saint sur un système saint.

[maeiky]

Propriétaire ou pas tu fais ton alpha de la mauvaise façon.

[Invité]

Bah, il fonctionne bien chez moi mon alpha.
Et les lumières et ombres aussi, je ne vois pas ce qui cloche avec ma technique.

Ce qui ralentis beaucoup le FPS ce n'est pas le GPU mais le CPU qui tourne à 100% tout le temps, je vais donc plutôt cherché de ce côté là.

Je pense me penché du côté des fonctions mathématiques, apparemment, ce sont elles qui, consommes le plus, peut être faire les calculs à la c++14 avec des templates, mais je ne sais pas si ça va fonctionné pour des variables non constantes, car en paramètre template on ne peux passer que des entiers constant. :/

Bref, il faudrait que je cherche un coup de ce côté là.

Peut être, ce tutoriel pourra t'il m'aider. :o

http://loulou.developpez.com/tutoriels/cpp/metaprog/

[maeiky]

Quand tu as le choix entre une méthode "gratuite" et une qui demande plus de calculs pour le même résultat, tu choisie la deuxième, en plus ça n'a pas l'air d'être géré par certains drivers comme tu dis?

Le pipline du alpha est déjà créer de façon hardware, pourquoi tu ne l'utilise pas?

[Invité]

Je voudrais bien l'utiliser cependant, je ne peux malheureusement pas changer le mode de blending suivant le z du pixel dans le buffer. :/

La seule solution que j'ai trouvé se sont des calculs complexes à faire au niveau du CPU pour découper les polygones non convexe en polygones convexes et les trier en temps réel, ce qui est bien sûr, plus lent que de le faire dans un shader.

[maeiky]

Tu les affiches dans l'ordre ou pas? Si c'est dans l'ordre tu n'as pas besoins de changer le blending.

Je vois pas ce que ça change d'avoir un polygone convexe ou pas dans tous ça?

[Invité]

Si deux polygônes s'entrecroisent, tu affiches lequel en premier ???

[skeud]

Petite question bête, mais pourquoi tu laisses pas faire openGL la dessus?

En l’occurrence si deux polygone se croise, tu affiche la partie des polygone visible, je vois pas ou est le soucis?

Je comprends pas pourquoi tu veux absolument recoder les fonctions d'openGL, il fonctionne très bien, pourquoi ne pas l'utiliser?

[Invité]

Parce que je ne veux pas faire de tri côté CPU, le CPU en a déjà suffisamment assez pour lui. (Là déjà il est a 100%)
Par contre le GPU n'est que à 40%, donc lui il peut se permettre de gérer cela, donc c'est bien opengl qui gère ça! (Mais je n'utilise pas le pipeline par défaut, j'utilise un shader pour gérer l'alpha)

Si j'active le depthtest avec l'alpha test je me retrouve avec du noir entre les tiles parce que on ne voit pas à travers les pixels semi-transparents.

Et les deux polygones sont visible vu qu'ils sont semi-transparent, il faut aussi que le blending se fasse correctement selon la position en z des deux fragments.

Bref avec mes connaissance d'opengl, seule le shader peut le faire, je ne connais aucune fonction d'opengl qui permette de le faire avec le pipeline par défaut, qui est d'ailleurs, déconseillé dans les versions plus récentes d'opengl.

Donc, tout passe d'office par des shaders.

Bon les ifs dans les shaders c'est peut être pas ce qu'il y a de mieux, mais la cause de la baisse du FPS c'est pas ça, c'est plutôt, le CPU qui en chie dans mon cas d'après le résultat des commandes top. Car même sans utilisé de shader, j'ai un FPS très bas. (De 20-30 maximum)

Bref si j'arrive à optimiser le CPU pour avoir un FPS de 60 sans les shaders je suis sûr que j'aurai minimum un FPS de 30 avec les shaders, et le problème du "low FPS" sera réglé.

C'est surtout le calcul côté CPU qui bouffe beaucoup (calcul vectoriel et matriciel :/ ), il faudrait que je puisse voir de ce côté là ce que je peux faire pour accélérer les calculs)

Mais le c++ est un bon langage et avec la méta-programmation et les fonctions inline ça devrait passer!

[maeiky]

Avec la méta-programmation, tu va genre sauvé 1% et ça va prendre 2 fois plus de temps à compiler.
Enlève des boucles et des calculs inutile à la place.

Si tu veux savoir si c'est vraiment le CPU qui ralentie tout, enlève tout ce qui est OpenGL et regarde sont niveau d'utilisation, tu risque d'être surpris, car le CPU attend que le GPU finisse ses transfères.

je ne connais aucune fonction d'opengl qui permette de le faire avec le pipeline par défaut, qui est d'ailleurs, déconseillé dans les versions plus récentes d'opengl.

Avec IOS, c'est possible de modifier le pipline, sinon c'est la bonne méthode pour avoir du alpha, il y a pas mal de moteur 3D qui n'ont même pas de Alpha et ne se serve que du depthtest. Le GPU travaille en parallèle, ta méthode ne calcule même pas le alpha de la bonne façon, soit tu le faits en ordre ou à la limite tu fais du alpha par multiplication, ou bien une méthode plus complexe avec du "Order Independant transparency"

[Invité]

Avec IOS, c'est possible de modifier le pipline.

Je ne possède pas IOS.

Si tu veux savoir si c'est vraiment le CPU qui ralentie tout, enlève tout ce qui est OpenGL et regarde sont niveau d'utilisation, tu risque d'être surpris, car le CPU attend que le GPU finisse ses transfères.

Même avec le CPU à lui tout seul, je n'ai pas un FPS très élevé, le calcul vectoriel et matriciel est assez gourmand. :/

Avec la méta-programmation, tu va genre sauvé 1% et ça va prendre 2 fois plus de temps à compiler.

Je ne sais pas, je n'ai jamais essayé, ça va prendre du temps à compilé ça oui, mais je vais quand même essayé, on ne sait jamais, ici, à se stade, toute optimisation est à prendre en considération.

Avec le système de raytracing je chute à 1 FPS, donc, je ne le ferais pas.

Le GPU travaille en parallèle, ta méthode ne calcule même pas le alpha de la bonne façon, soit tu le faits en ordre ou à la limite tu fais du alpha par multiplication, ou bien une méthode plus complexe avec du "Order Independant transparency"

De l'alpha par multiplication ???

[maeiky]

De l'alpha par multiplication ???

Certainement moins réaliste, mais ça serait déjà mieux que ce que tu fais:


http://www.openglsuperbible.com/2013/08/20/is-order-independent-transparency-really-necessary/

[Invité]

Bah, c'est ce que je fais là!

[maeiky]

D'après ce que j'ai compris tu fais un blending "normal" peut-importe l'ordre, sans trier les éléments. Ce qui donne un résultat totalement faux lorsqu'il y à plus d'une transparence. De plus ta formule change si l’élément est devant ou derrière et puisque tu n'utilise pas le blending intégrer à OGL, tu dois lire 2 textures différentes ce qui ralentie, en plus des calculs et ta condition.

Il n'y a pas 36 solutions :

Soit tu abandonne la transparence, il y à plein de moteur 3D très bien sans.
Soit tu les affiche dans l'ordre.
Soit tu fait ta transparence à part avec un procéder multiplicatif ou additif.
Soit tu utilise la méthode du weight : https://mynameismjp.wordpress.com/20...d-blended-oit/
Ou que tu utilise des linked list avec OGL 4+

Tout autre méthode sont bonne pour la poubelle.