Discussion :

[Laurent7601]

Attention aux limites d'imgui.
On s'en sert généralement pour de l'UI de debug, ou à la limite pour l'éditeur, mais pas dans un jeu

Ok, merci pour la précision, j'ai mon propre système d'overlay pour mes jeux, mais, I'm gui c'est juste pour embellir mon éditeur et éviter de devoir coder tout les widgets à la main.

J'ai fini l'implémentation de mes point lights + CSM mais j'ai encore des bugs (Je corrigerai les bugs quand j'aurais un éditeur ce sera plus facile quand je pourrais voir les lumières et les déplacer)



J'ai terminé l'implémentation avec les lumières multiples. Je dois la tester.

[Laurent7601]

Pour plus de puissance pour faire tourner ODFAEG, et pour plus tard, des meshs/tasks shaders et du raytracing avec ma nouvelle RTX 5070 TI!

En attendant j'ai terminé le rendu shadow passes multi-lumières, maintenant je dois tout installé sur ce nouveau PC!

Y'aura encore juste quelques soucis d'affichage à régler.

[LittleWhite]

Oh bah nice !

[Laurent7601]

Ca y est! Après 48h d'archarnements, jour + nuit, j'arrive maintenant à exécuter la petite démo de la nouvelle version du moteur sur windows avec clang. (MSVC échoue lors de la compilation du moteur, clang-cl même chose)

J'en ai chié avec la config, j'ai dû simuler un environment linux (avec msys2) et installer et configurer toutes les dépendances pour cmake car impossible de compiler les dépendances vcpkg et conan, car l'écosystème est complètement cassé sur windows, j'ai aussi eu des conflits avec le flag gnu++20 qui se mettait tout seul. J'ai aussi dû modifier le nommage des types des classse String et Utf que j'ai repris de la SFML pour les rendre compatible avec libc++. Bref j'ai galéré pendant 48h, avec un tas d'emmerdes. J'ai corrigé le soucis du crash avec le mutex global sur windows. (La variable statique du mutex utilisée avant l'initialisation de la variable statique)

[Laurent7601]

Ca fait super longtemps que j'attendais de pouvoir utiliser une telle feature! En effet, c'était lourd avant (génération de tout les sommets côté CPU pour une heightmap et voxel map + le culling par face pour les voxel maps), avec les meshes shader je vais pouvoir générer la géométrie à partir de n'importe quelle buffer (ou même à partir de rien), car le GPU est encore plus programmable! Je détestais vraiment devoir, dépendre de primitives existantes dans le geometry shader et de vertex/index buffer dans le vertex shader.

[dragonjoker59]

Je détestais vraiment devoir, dépendre de primitives existantes dans le geometry shader et de vertex/index buffer dans le vertex shader.

Euh... Tu peux générer tes sommets à partir de rien, dans le vertex shader. Tu peux dire "dessine 36 sommets", et reconstruire ton cube (par exemple) directement depuis le vertex ID, ou utiliser ce même vertex ID pour indexer dans un buffer les informations recherchées (vertex pulling)

[nouby]

Merci, c'est le résultat de 30 ans d'expérience en c++ et 2 ans avec vulkan. Je vais justement commencer à migrer le code de la gui du moteur vers I'm gui, ça sera plus beau, j'ai juste un problème de config à régler, les fichiers de config génèrés par Conan ne sont pas bon avec I'm gui, demain je vais essayer avec vcpkg. Si tu veux participer en tant que scénariste/gameplay, pourrais tu m'envoyer tes coordonnées discord s'il te plait ? J'ai justement plusieurs idées de jeux, mais je n'ai pas encore défini tout le gameplay et le scénario. Juste améliorer le jouabilité car je ne suis pas satisfait de la jouabilité des jeux existant, essentiellement à cause que faut être un vrai pianiste parfois, aucune commande vocale (ça sera prévu dans mon moteur, les moteurs existant ne le font pas nativement) ou encore trop de gestion à la souris. (Attaquer+se déplacer) Ou pathfinding bugué prêt des murs ou encore problème de caméra en 3D à une seule vue, sans pouvoir la changer. Je déteste tout ça dans les jeux existant. Raison pour laquelle j'ai fais mon propre moteur. Je pourrai commencer à coder le jeux l'année prochaine quand j'aurai terminé la migration.

Salut, j'ai pas encore de chaine discord mais je compte en faire une pour mon jeu 2D en cours.
Mais je ne veux pas mélanger deux choses différentes (mon jeu et les tiens sur ma chaine, et réserver ma chaine seulement à mon jeu. Je te préviens dés que je la crée.

[Laurent7601]

Salut, j'ai pas encore de chaine discord mais je compte en faire une pour mon jeu 2D en cours.
Mais je ne veux pas mélanger deux choses différentes (mon jeu et les tiens sur ma chaine, et réserver ma chaine seulement à mon jeu. Je te préviens dés que je la crée.

D'accord préviens moi dès que tu as fais cela, on échangera au niveau du gameplay du premier vrai jeux du moteur.

J'ai fait une nouvelle mise à jour pour la gestion des shaders. On peut désormais choisir la compilateur spriv avec cmake et le moteur compile les shaders avec cmake de glsl vers spriv. Et ma classe Shader peut désormais charger ces fichiers spriv. C'est plus propre, ça permet de résoudre le problème des différentes version de spirv installée sur une même OS avec le sdk de vulkan et l'environement de msys2 par exemple. (Sa version de spirv est trop ancienne pour compiler les mesh shaders)
J'ai dû donc trouvé une autre manière de faire avec l'aide de l'IA. ODFAEG peut désomrais compiler des mesh et task shaders.

J'ai pas encore testé au niveau du rendu ce que ça donne, mais les mesh shaders sont plus performant que les vertex shaders d'après l'IA, et ça te permet d'éviter de devoir utiliser un piepline par topologie ce qui est très lourd (faut juste 3 mesh shaders, un pour les points, un autre pour les lignes et un pour les triangles) On peut, peut être générer des sommets avec le vertex shader et le vertex pulling à partir de n'importe quel type de buffer pour produire la géométrie comme avec un mesh shader, mais je trouve pas ça optimal, c'est plus pour l'ancien hardware et la compatilbité. Par exemple pour générer une heightmap juste à partir des heights. Mais le soucis c'est que dans le vertex shader on ne peut pas générer de primitives, donc, pour générer des triangles strips à partir des heights de la height map..., ce qui est beaucoup plus simple côté éditeur, car, plus besoin de modifier les heights des triangles strips côté CPU ce qui était un vrai enfer vu que le mesh shader peut générer les triangles strips. Raison pour laquelle j'ai acheté du nouveau hardware. Je suis tranquille comme ça, et je pense pas que j'aurais encore besoin de carte graphique avant de longue années. (Avant la sortie de mon premier jeux)

[dragonjoker59]

D'accord préviens moi dès que tu as fais cela, on échangera au niveau du gameplay du premier vrai jeux du moteur.

J'ai fait une nouvelle mise à jour pour la gestion des shaders. On peut désormais choisir la compilateur spriv avec cmake et le moteur compile les shaders avec cmake de glsl vers spriv. Et ma classe Shader peut désormais charger ces fichiers spriv. C'est plus propre, ça permet de résoudre le problème des différentes version de spirv installée sur une même OS avec le sdk de vulkan et l'environement de msys2 par exemple. (Sa version de spirv est trop ancienne pour compiler les mesh shaders)
J'ai dû donc trouvé une autre manière de faire avec l'aide de l'IA. ODFAEG peut désomrais compiler des mesh et task shaders.

J'ai pas encore testé au niveau du rendu ce que ça donne, mais les mesh shaders sont plus performant que les vertex shaders d'après l'IA, et ça te permet d'éviter de devoir utiliser un piepline par topologie ce qui est très lourd (faut juste 3 mesh shaders, un pour les points, un autre pour les lignes et un pour les triangles) On peut, peut être générer des sommets avec le vertex shader et le vertex pulling à partir de n'importe quel type de buffer pour produire la géométrie comme avec un mesh shader, mais je trouve pas ça optimal, c'est plus pour l'ancien hardware et la compatilbité. Par exemple pour générer une heightmap juste à partir des heights. Mais le soucis c'est que dans le vertex shader on ne peut pas générer de primitives, donc, pour générer des triangles strips à partir des heights de la height map..., ce qui est beaucoup plus simple côté éditeur, car, plus besoin de modifier les heights des triangles strips côté CPU ce qui était un vrai enfer vu que le mesh shader peut générer les triangles strips. Raison pour laquelle j'ai acheté du nouveau hardware. Je suis tranquille comme ça, et je pense pas que j'aurais encore besoin de carte graphique avant de longue années. (Avant la sortie de mon premier jeux)

Du coup, quand tu vas livrer un jeu, il viendra donc avec son exécutable, les DLL de ton moteur (et autres dépendances) et les shaders pré-compilés en SPIR-V, dans une version qui ne correspondra pas forcément au hardware du PC sur lequel tu installes le jeu ?
Ne serait-il pas mieux de faire l'étape de compilation GLSL -> SPIR-V à la première exécution du jeu sur le PC client ? (et donc link glslangValidator à ton moteur, et le mettre dans les DLL de dépendance)

[Laurent7601]

Du coup, quand tu vas livrer un jeu, il viendra donc avec son exécutable, les DLL de ton moteur (et autres dépendances) et les shaders pré-compilés en SPIR-V, dans une version qui ne correspondra pas forcément au hardware du PC sur lequel tu installes le jeu ?
Ne serait-il pas mieux de faire l'étape de compilation GLSL -> SPIR-V à la première exécution du jeu sur le PC client ? (et donc link glslangValidator à ton moteur, et le mettre dans les DLL de dépendance)

Tu veux dire faire la compilation au runtime ? C'est ce que j'avais fait, mais ça pose problème, dans le cas ou dans le code de compilation des shaders du moteur, il invoque le mauvais compilateur GLSL=>spirv. (Ce qui est mon cas, vu que j'en ai 2 dont un pas compatible avec les mesh shaders) Mais la vérification du compatilibté hardware/vulkan features, je la fais au niveau du device, en vérifiant quelles extension son supportées. Si les mesh shaders ne sont pas supportés je passe par un pipeline classique. J'ai presque fini l'implémentation des mesh shaders, ça affiche pas tout les meshes parce que je dois découper les mesh assimps en meshs de sommets de 64 sommets et 32 primitives au niveau des indices, parce que les mesh shaders ne peuvent gérer que de petits groupe de sommets. (Question d'opitmisation) C'est asseze lourd, je ne devais pas faire celà avec les vertex shaders, mais bon.

[Laurent7601]

Salut! J'ai terminé d'implémenté le pipeline mesh shaders avec mon moteur et c'est beaucoup plus simple, j'ai enfin pu gommer les bugs d'affichage que j'avais avec le pipeline classique. (Ou 'javais des bugs d'afficgae avec les textures et avec le material id et le gl_DrawId) ^^

Ca rend beaucoup mieux!!!



Les mesh shaders sont beaucoup plus simple à utiliser que le pipeline classique pour moi. (Même si ça peut parâtre plus compliqué parce que faut découper les meshes en petit meshes, et aussi, émettre soit même les primitives)

Le problème avec gl_DrawId c'est que tu ne peux pas avoir de trous, donc fallait que j'utilise un buffer d'output de matériaux supplémentaire pour les matériaux et les dupliquer, pour faire en sorte qu'ils soient consécutifs, tandis qu'avec les mesh shaders, je peux passer la material id du mesh directement au fragment shader. Ca résoud les bugs d'affichage que j'avais avec le pipeline classique!

EDIT => FPS : entre 1350 et 1650.

[Laurent7601]

Bonjour! J'ai tester les perfs et le pipeline classique est plus performant surtout avec des scènes lourde comme bistro, parce que le vertex shader n'a pas de limites au niveau du nombre de sommets qu'on peut lui passer, contrairement au mesh shader ou il faut tout découper, en mesh de sommets de 256 sommets max (pas plus). Le fait de devoir faire un dispatch ou une boucle sur tout ces meshlets pour le culling ralenti beaucoup trop le FPS. Bistro extérior avec mon pipeline de rendu classique (vertex shader) tourne à 580 FPS sur ma RTX 5070 TI. Hors que avec les mesh shaders, je tombe à 40 FPS seulement. J'ai donc finallement décidé de ne pas les utiliser de plus ça ne résoud pas mes bugs d'affichage avec cette scène. De plus avec bistro mes normales sont pas bonne dans le mon fragment shader contrairement avec les modèles sketchfab.

[Laurent7601]

Salut! J'ai réussi à implémenté les mesh-shaders et un système de génration de meshlets côté CPU mais c'est encore trop lent sur des scènes comme bistro, il faut faire un système de clusters pour le frustrum culling et réduire le nombre massif de meshlets (+ de 300 000 meshlets je crois bien générés avec les mesh de bistro) car contrairement au pipeline classique y'a pas de frstrum culling lors de l'input assembly parce que tu dois simplement le programmer toi même, mais ceci relève de l'optimisation prématurée pour un premier jeux pour faire un moteur nanite-like et passer de l'affichage de scènes de 10-50M de polys avec le pipeline classique à plus de 100M de polys juste pour faire des scènes ultra détaillées et ce n'est pas gratuit. (même avec l'aide de l'IA)
Pour en venir à league, ça a été mon moba favori pendant un petit temps, j'ai enchainé les parties, mais, quand j'ai découvert ses défault, le FPS qui platfonne à 200 sur ma RTX 5070, sur mon écran géant, injouable avec le studio driver de développement du moins (les sorts mettent 0.5 sec avant de se lancer), alors que mon moteur utilise les techniques de rendu moderne ou le FPS est 3* plus élevé (en pipeline classique) avec des scènes beaucoup plus lourde que League avec sa 2D iso. Je planifie une refonte totale d'un jeux style league une fois, que j'aurais fini de migrer toutes les classes et la GUI de la version précédente de ODFAEG qui était lente dû à son CPU driven, et je compte même, faire un refont league mais en 3D, parce que un moteur rapide pour de la 2D iso j'en vois pas l'intérêt. Ca ne promouvoira pas le but principal du moteur si je n'affiche pas de scènes complexe/détaillées. Et au niveau du gameplay je pense changer totalement ce système de matchmaking. Je commence à en avoir raz le bol des games non équilibrées la majorité du temps. Je vais faire un système de matchmaking pas basé sur les stats, avec un système 5 joueurs avec 3 joueurs et 2 bots qui se rééquilibreront, suivant le match. (Avec en prime un système de remplacement de joueurs par bots pour le troll/afk pour réduire la toxicité très élevée avec League, c'est pas les joueurs qui sont toxique selon moi, c'est le jeux qui les rends comme cela) Mais un tel projet ça me demande, beaucoup d'énergie, beaucoup de temps, beaucoup de motivation et aussi de l'argent bien sûr si plus tard j'ai besoin d'infographistes qui je suis sûr ne travaillent pas gratuit, il m'a déjà fallut déboursé des sous pour l'instissement matériel sans être sûr que ça rapporte un jour parce que je ne suis pas sûr d'avoir la motivation, le temps, et l'argent pour payer les futur infographistes une fois que la réécriture du moteur soit fini ou voir même les trouver. La migration GPU-Driven des centaines de classes pour le rendu vulkan (vulkan est très verbeux) je suis là dessus depuis 1à2 mois maintenant sans avoir optimisé les nouvelles features de vulkan (rendu mesh shading) que je ne ferai probablement pas maintenant car j'ai envie d'arriver au développement du jeux le plus vite possible. Apparemment je suis dans la tranche d'âge, beaucoup d'indies on commencer à vendre leur premier jeux entre 30 et 45 ans, il est temps...

[Laurent7601]

Salut, je vais essayer de viser un publique plus large, en publiant, demain, la version publique de la première démo jouable que j'ai développé y'a longtemps avec la première version du moteur. (La version opengGL) La démo avec la vesion vulkan, beaucoup plus performante suivra. Et enfin le jeux complet quand j'aurai enfin une équipe pour créer du vrai contenu avec mon moteur (déjà la finition des features du moteur c'est..., un travail de longue haleine, la création de contenu, sans artistes/game designer voir même autre codeur c'est, pas évident tout seul, surtout que je ne suis pas du tout à laise avec la prtie artistique)

Le moteur a aussi été fait après que j'ai participé brièvement à 2 projets. (Qui apparemment auraient été laissé à l'abandon ?)

-Holyspirit de Grégoire. (L'implémentation des threads dans son jeu, accélérais le gameplay, pas normal, le framerate est sensé être indépendant du gameplay, il me dit, ton implémentation muli-threads ne fonctionne pas, normal, la gameplay de son jeux n'était pas bien synchronisé)

-Yildiz online de Shakal. Là c'était un problème physique, pas de recalcul de la vitesse, suivant la trajectoire, vaissaux qui tournait en rond.