Discussion :

[Invité]

Salut!

Ce week-end n'étant pas chez moi j'ai bien avancé pour finir la release 1.0.

Désormais le moteur peut afficher des lumières en 3D. (Même si ce n'est pas encore parfait et que je devrais afficher des sphères plutôt que de ellipses sur la lightmap)

Les indices de réfraction et tout ça ce sera pour la version 2.

Là ou j'en ai chié c'est quand même pour convertir le centre de la lumière en coordonnée fenêtre. :/

Il y a sûrement une meilleure solution travaillant en coordonnées mondes, et passer les informations de la lumières dans le shader, mais, je doute que ça marche dans le cas ou la lumière n'est pas circulaire mais de la forme que je veux, dans ce cas je devrais gérer toutes les collisions avec la lumière dans le shader, ce qui ne semble pas être mieux. :/

Bref, j'aime bien dessiner des lightmaps sur une texture de rendu en passant la bump map, le centre de la lumière, etc...

Je ne compte pas faire de lumière qui n'ont pas d'atténuation, ça n'a pas vraiment de sens pour moi. :/

Je compte plutôt faire des lumières de n'importe quelle forme en recalculant la couleur du pixel en fonction de la bump map, de la distance, ainsi que tout le reste.

[Invité]

Ca y est la release 1.0 est enfin terminée, celle-ci n'est autre qu'une version de base qui me servira à coder de petits projets de jeux, et de repérer et de corriger ainsi les bugs, et d'effectuer les dernières optimisations avant la version suivante.

Donc, s'en suivrons les versions 1.1, 1.2, etc...

Voici quelques vidéos qui montrent ce que la version 1.0 du moteur peut déjà faire :

Transmission de données chiffrées (ou non) en réseau, calculs de mouvements synchronisés de personnages et de monstres en réseau.

Rendus de lumières, ombres et particule avec sauvegarde des entités de la scènes dans un fichier à l'aide de la scérialisation. (Rendu de base sans réfraction, ni disfraction, ni bumpmapping, cela sera implémenté dans la version suivante)

ODFAEG propose déjà quelques rendus en 3D. (génération aléatoire d'une terrain ainsi que éclairage de base et particules)

Mais ceci n'est qu'un premier jet, je dois encore améliorer tout ça avec des textures 3D. (Ou bien des formes en 3D)

Car là l'éclairage n'est pas vraiment bon il devrait éclairer plus vers le haut.

Voilà, les versions suivantes seront surtout des corrections de bugs et des optimisations, car là mon FPS est assez bas. :/

[maeiky]

Je sais que tu as mis beaucoup d'effort et que ce n'est pas final, mais je n'arrive pas à comprendre tes ombres.

Pour la 3D faire un pré-rendu est nécessaire, mais j'ai des doutes pour la 2D, le résultat me semble étrange:

Ta matrice est inversé non?


Ça donne l'impression qu'ils lévitent?


Personnellement pour faire des ombres j'aurais procéder ainsi : faire un copie de tes objets qui ont des ombres, inversé verticalement et rendre le tout en noir en gardant le canal alpha, plus un diminution du alpha général.




De plus c’est trop lent, 15fps? Tu ne devrais jamais avoir de condition dans un fragment shader :

vec4 color = (haveTexture == 1) ? texture2D(texture, gl_TexCoord[0].xy) * gl_Color : gl_Color;
vec2 position = vec2 (gl_FragCoord.x / resolution.x, gl_FragCoord.y / resolution.y);
vec4 stencil = texture2D (stencilBuffer, position.xy);
if (firstPass == 1) {
if (color.z == 1) {
gl_FragColor = vec4(0, 0, 0, 1);”
} else {
gl_FragColor = gl_Color;
}
} else {
if (set == 1 && color.a >= stencil.a) {
gl_FragColor = vec4(1, 1, 1, 1);
} else if (stencil.g != 0) {
gl_FragColor = vec4(0, 0, 0, color.a);
} else {
gl_FragColor = vec4(1, 1, 1, 1);
}
}

Dernière remarque, normalement une version 1 est une version "final stable", pense à SFML ils sont pas rendu à 250 versions.

Ce ne sont que des remarques constructive, ton projet est tout de même original.

[Invité]

Salut, en ayant fait quelque tests avec gproof les fonctions qui bouffe le plus en performance se sont les fonctions mathématique des classes matrix4f et vec3f, je pense donc que le problème vient de là. :/

Peut être devrais je essayer de les optimiser avec le nouveau standart c++11.

Les version 1.x de SFML ne sont pas toujours des versions stable. :/

Il y a encore des issues.

Pour les ombres je pense fait quelque chose de plus générique pour la 2D et la 3D, le problème des sprites noici (comme je le faisais avant) c'est que ça ne marchera pas pour la 3D, j'ai donc dû trouvé une autre solution en plaçant la caméra au dessus l'observateur, et en utilisant une matrice pour inverser et centre les ombres, ainsi que faire des rotation en fonction de la position de la lumière qui génère l'ombre.

Pour les if dans les shaders je n'ai malheureusement pas le choix surtout si je veux gérer la semi-transparence en 3D.

[skeud]

Ton gproof prouve ce que je te dis depuis le début, ton shader devrait uniquement faire du traitement et non pas charger des textures comme tu le fait, elle doivent être chargées avant.
Tes shader bouffe tout ton proc car il ne font pas le boulot qu'ils devrait faire, tu les utilises pour effectué du travaille d'initialisation etc .... Ce travail sera appelé à chaque création de sommet, c'est donc normal que ça soit hyper long. Revois tes shader en premier lieu (déjà exporte les en dehors de ton moteur et charge les en fonction des objets et non directement dans ton code, parse les qu'une fois, puis applique les qu'une fois, lors de la création de ton objet.

Retire le traitement des lumière et ombre des tes shader, et créer une map d'ombre qu'une seule fois, une fois la scène chargée, tu y gagneras en performance je pense.

[Invité]

Le problème c'est que la scène change à chaque frame. :/ (Vu que la caméra se déplace)

Donc je dois réappliquer les shaders à chaque frame. :/

PS : les shaders ne sont pas chargé à chaque frame mais juste à l'initialisation, je ne fais juste que de changer certains paramètres des shaders à chaque frame.
Les textures sont générées à l'aide de FBO, afin d'avoir des grandes textures avec les normales, la hauteur, etc..., de toutes les entités de la scène par rapport à la position de l'observateur. (ce qui me permet de faire les calculs en passant les textures des FBO au shaders)

Mais même en réduisant le nombre de textures et le nombre de FBO ça n'augmente pas les perfs. :/

Je suis entrain de me demandé si le problème ne viendrais pas du driver, il faudrait que je puisse essayer sur un driver plus moderne, je me souviens que sur windows les perfs étaient quand même nettement meilleure avec un driver propriétaire.

[maeiky]

Ok, mais tu ne peux pas corriger ta matrice de projetions d'ombre? Si oui le résultat sera nettement plus convaincant. Pour les performances, c'est limite au niveau du CPU ou GPU (lequel est à 100%)?

À chaque envoie de variable au GPU, le CPU doit attendre le GPU, donc ça consomme le CPU pour rien, il faut que t'arrive à grouper tout ça pour avoir le moins d'appels possibles.

[skeud]

Les shader, il faut absolument que tu les optimise pour les appliqué que sur les objets qui ont changé et non pas tout le reste.

Et je persiste à dire que tes shader ne doivent faire que des transformations, il ne doit pas y avoir de condition, de création, de vérification de couleur etc ......

Sinon ils seront beaucoup trop lourd niveau traitement. La preuve, sans les shader, tu gagnes énormément de FPS...

[Invité]

Pour les ombres j'ai trouvé le problème, en fait c'est un problème avec l'alpha blending sur la composante de test. (Elle ne vaut plus 1 à cause de l'alpha blending ce qui me donnait des pixels transparent pour les ombres là ou il n'en fallait pas, je vais essayer de trouver une solution)

Pour les conditions je vais essayer mais ça va être difficile de les retirer. :/

Je n'ai jamais pu trouvé d'autre solution simple et satisfaisante, à part des calcules lourd côté CPU.

Hum, le GPU et le CPU ne travaillent t'il pas en parallèle ?

Le CPU n'est pas sensé attendre après le GPU avec le double buffering.

[Invité]

J'ai changé la 1ère vidéo, les ombres rendent nettement mieux maintenant.

[maeiky]

Tes ombres sont toujours inversés horizontalement et trop éloignés du personnage.

Est-ce ton GPU ou ton CPU qui est utilisé à 100%?

OpenGL n'est vraiment pas CPU friendly, il y a très peu de fonctions qui s'exécutent en parallèle, la plupart ont de la synchronisation. Pour ce qui est du parallèle il y a les bindless, aussi du coté de glMapBuffer, sinon dans ton les cas le CPU attend par polling que le GPU finisse. Ce qui faut faire c'est le plus de traitement en parallèle simultanément comme avec l'instancing. Dans le cas contraire le CPU attend après le GPU et vice-versa, ce qui cause du ralentissement des 2 cotés.

Edit :

Et je persiste à dire que tes shader ne doivent faire que des transformations, il ne doit pas y avoir de condition, de création, de vérification de couleur etc ......

Je ne suis pas tout à fait d’accord, il y a une différence entre le fragment shader et le vertex shader, le fragment doit être le plus optimisé possible car il est exécuté pour chaque pixels, les conditions dans les vertex ne sont pas dramatique. De plus il y a différence quand les conditions se font sur des variables uniformes, qui sont acceptables dans le fragment shader, car le compilateur peu les optimisés en créant plusieurs versions du shader.

[Invité]

OpenGL n'est vraiment pas CPU friendly, il y a très peu de fonctions qui s'exécutent en parallèle, la plupart ont de la synchronisation. Pour ce qui est du parallèle il y a les bindless, aussi du coté de glMapBuffer, sinon dans ton les cas le CPU attend par polling que le GPU finisse. Ce qui faut faire c'est le plus de traitement en parallèle simultanément comme avec l'instancing. Dans le cas contraire le CPU attend après le GPU et vice-versa, ce qui cause du ralentissement des 2 cotés.

Pourtant j'utilise de l'instanced rendering pour les textures donc je fais peu d'appels à glBindTexture, et j'utilise glMapBuffer ainsi que glUnmapBuffer également pour update les sommets.

Bref, je ne sais plus quoi faire d'autre. :/

Ha oui c'est vrai l'ombre du personnage n'est pas dans le bon sens et de ce fait elle est trop éloignée du personnage, je n'avais même pas remarqué.
Bref, je vais rajouter des fonctions dans la classe entité pour modifier le sens des ombres, ça devrait résoudre le problème. (Car il y a certaines ombres qui doivent être inversées, d'autres pas)

Je pense aussi que les if dans les shaders ne sont pas la cause, car ils proviennent soit de variables uniformes ou bien de textures updatée avec des FBO que je dessine ensuite avec des VBO, donc, je pense que opengl peut optimiser tout ça.

[maeiky]

Le double buffer est toujours activé, imagine que tu verrais apparaitre un à un les élément que tu dessine et même partiellement.Tout passe par un glswapbuffer.

[Invité]

Ok.

Comment puis je mesurer la consommation de CPU et de GPU sous ubuntu ?

Existe t'il des outils ?

Si oui, lesquels me suggériez vous d'utiliser ?

[maeiky]

Il faut que tu cible le goulot, si tu veux trouvé ton problème.

Pour le CPU, avec top.

Combien de cœur as ton PC? Puisqu’en réalité dépendamment de combien de thread tu utilise, il va se limité à un cœur, il est très difficile d'utilisé tout les cœurs également.

Pour le GPU, dépendamment si c'est AMD ou NVidia c'est une simple commande.

[Invité]

J'ai corrigé le soucis avec les ombres qui étaient du mauvais sens, je remettrai à jour la vidéo une prochaine fois car je ne suis pas là ce week-end mais je pense que je vais les mettre sur le 1er post.

Bon, je suis chez AMD donc, la commande ne devrait pas être difficile à trouver.

Je n'utilise qu'un seul thread pour tout. (Même pour le réseau)

[Invité]

Salut!

En ayant fait quelque tests, voici ce que j'obtiens :

Pour la consommation au niveau du GPU ça tourner autour de 30-40% donc ça va de ce côté là.

Le problème c'est la consommation CPU, elle tourne autour de 96 jusqu'au delà de 100%. (Sachant que j'ai 4 cœurs donc je ne sais pas si je dois considérer le maximum comme 400% ou bien 100% mais dans tout les cas je trouve que c'est beaucoup)

Il me semble que le CPU attends après le GPU. :/

Etant donné que je ne vois rien de suspect au niveau du profiler, le problème doit sûrement venir du driver opensource qui n'effectue pas les traitements en parallèle.

[skeud]

Je ne pense pas que le problème vienne du driver, sinon tu aurais ce problème partout dans toutes tes applis 3D. Le problème vient plus surement de ton code.

ton CPU doit attendre ton GPU par rapport aux shader, comme les shader sont exécutés sur le GPU, le CPU doit les attendre à chaque calcul de sommet etc ....

[Invité]

Salut!

La version 1.0 semble stable. (sur ma plateforme en tout cas, elle l'est)

Cependant le FPS est bas, trop bas pour la version II qui permettra de faire des rendus plus réaliste encore et d'afficher plus de sommets.

Il va donc falloir que je fasse des optimisations.

Les optimisations essentielles à venir dans la version 1.1.

Pour cela, il y a deux solutions :

-La 1ère consiste à faire du lancer de rayons avec le CPU, plutôt que avec le GPU, qui lui, prend le rayon entre la lumière (en coordonnée pixel) et le fragment (aussi en coordonnée pixel) pour effecteur les calculs pour l'éclairage.
ODFAEG utilise aussi des textures de rendus plutôt que des textures externes pour le depthbuffer, le framebuffer et la normal map de la scène, chose qui peut devenir vraiment trop compliquée à gérer côté CPU à cause de la transparence et des algorithmes de raytracing avec les polygones.
Mais cette solution, demanderait de changer totalement la structure du moteur, de plus il faudrait effectuer un lancer de rayon pour chaque lumière de la scène, je ne compte donc pas opter pour cette solution.

-La seconde consiste à utiliser un thread pour le rendu ainsi que l'utilisation de conteneurs lock-free afin de faire en sorte que le CPU n'attende plus après le GPU lors de l'exécution des shaders. (Cause principale du FPS trop bas)

Je vais opter pour celle solution.

Les nouvelles fonctionnalités qui seront ajoutée dans la versions 2 :

Il y a beaucoup de nouvelles fonctionnalités prévues, la version 1 était plutôt une version de tests, surtout pour les scènes plus complexes.

Mais c'est seulement dans la version 2.0 que les choses sérieuses vont commencer.

-Chargement de modèles 3D de formats externes : dans les jeux 3D les personnages/armes ainsi que tout les autres objets sont créer avec des logiciels externe puis exporté dans un format connu, le moteur n'a donc plus que les importer pour pouvoir les afficher.

-Encore plus de réalisme avec les shaders : pour l'instant ODFAEG ne gère pas les effets "miroir", la version 2.0 permettra de gérer cela en rajoutant une composante de réfraction et de disfraction aux matériaux des entités.

-Le bump mapping : pour l'instant ODFAEG ne tiens compte que de la géométrie de la scène pour le calcule de l'éclairage, mais, souvent dans les jeux, on se contente de dessiner des formes très basique en jouant avec les textures externes pour donner l'impression d'avoir des formes moins droite ou plus bosselée.

Pour cela on déforme les normales des objets de la scène en fonction du relief de la texture externe plaquée sur l'objet.

Dans la version 2 de ODFAEG on pourra ajouté une texture (une bump map) à chaque matériel des entités afin de donner cette impression de changement de géométrie.

-Un driver SQL : Présent dans beaucoup de framework également, je compte reprendre un driver SQL opensource afin de l'intégrer dans le framework, car poue le moment ODFAEG ne permet la sérialisation de donnée que dans des fichiers textes.

-Un système de GUI : Beaucoup employé dans les frameworks également, ce système permet de de créer des menus, des boutons, etc..., et de pouvoir les placer là ou on veut.

Pour les scènes plus complexe (avec les shaders), je risque d'avoir plus de mal, m'enfin bon, on verra bien, de toute façon, je ne compte pas faire d'applications hyper complexe dans un 1er temps.

PS : pourtant ici il est bien spécifié que les shaders tournent en parallèle pour les versions 3 et 4 d'opengl http://antongerdelan.net/opengl/shaders.html

N'est ce pas le cas pour les versions en dessous de la version 3.3. ?

[maeiky]

PS : pourtant ici il est bien spécifié que les shaders tournent en parallèle pour les versions 3 et 4

Il faut que tu te mette dans la peau de OpenGL, c'est du semi-parallèle, si tu fais un seul drawcall, il va s’exécuter en parallèle. Si tu en fait un deuxième de suite, tu impose un ordre d'affichage au GPU, donc il doit inévitablement attendre que le premier finisse, c'est pour ça que l'on préfère faire du batching. Il y a d'autres techniques avec OpenGL 4+ qui permet au GPU de dessiner en indirect.