Discussion :

[Laurent7601]

Je continue à corriger les bugs et j'en ai encore corrigé un dans ODFAEG Creator la sélection du rectangle de texture en mode aligné avec la grille ne se faisait pas au bonne endroit par rapport à la position de la souris, ce soucis est maintenant réglé.

Je vais continuer à créer le premier niveau pour le jeux tout en corrigeant les derniers bugs éventuels.

J'ai dû laissé tombé la 3D parce que en gérant tout (transparence, ombres, lumières et réfraction) le FPS est assez bas car il y a plus de polygones à afficher en 3D.

[Bryce de Mouriès]

J'admire la pugnacité dont tu fais preuve pour la réalisation de ton moteur de jeu, 15 ans de travail pour un résultat inexploitable aujourd'hui.

Ce qui m'interpelle le plus c'est le pourquoi de cet acharnement. Désolé si c'est un peu cru.

Je veux un moteur de jeux qui soit très complet et qui me permettra de créer n'importe quel type de jeux facilement, étant donné que je n'ai pas assez d'expérience pour utiliser un moteur de jeux existant tel que unity ou unreal engine mais que j'ai beaucoup d'expérience en c++ et en opengl, j'ai décidé de créer mon propre moteur de jeux, ça me permet de savoir mieux comment l'utiliser et de ne pas être obligé de lire des pages ou lire des vidéos que je ne comprend absolument pas pour utiliser un moteur de jeux vidéo existant.

On l'a tous rêvé ou du tout moins imaginé le "moteur de jeu complet pour faire n'importe quel jeu facilement". Par essence même, un moteur de jeu complet, est également complexe car il est bourré de fonctionnalité, ce sont de véritables usines à gaz, ce sont les exemples que tu donnes, Unity et Unreal.
Et d'un autre côté, un éditeur simple va être spécialisé, exemple Shmup Creator pour faire des shoot'em up, RPG maker des RPG, Spring Engine pour des RTS. Tu peux pondre un jeu rapidement mais pas n'importe quel jeu.

Il est inimaginable que tu fasses un éditeur, capable de sortir un FPS, un RTS, un Hack'n Slash ou un Minecraft en bossant deux jours sur le jeu.

Parce que là, pour économiser du temps à lire des pages ou des tas de vidéo pour apprendre un seul éditeur, et le maîtriser, tu passes 15 ans à essayer de faire un éditeur. Combien de pages as-tu lu et combien de vidéos visionnées pour réaliser cet éditeur ?

Fixes toi un objectif réalisable. Soit tu veux faire un jeu, et dans ce cas là passes par un éditeur existant (il y en a des dizaines rien que pour C++). Ou focalises toi sur un éditeur avec un objectif précis, un éditeur de jeu de plateforme en 2D par exemple. Ou bien troisième possibilité, ce que font pas mal de gens, fais le pour t'amuser par curiosité, mais inutile de partir dans un recrutement sérieux de toute une équipe.

[Laurent7601]

Bonjour. Au niveau du FPS je ne pense pas pouvoir faire mieux je n'ai pas les connaissances pour j'ai débuté de zéro en programmation graphique car mes études était en informatique de gestion et pas en programmation graphique. J'ai tout essayé pour optimisé mais rien y fait il me semble que la mise à jour des VBO me bouffe trop de FPS au niveau du CPU pourtant à part ça je fais quasi tout au niveau du GPU on dirait que le CPU attend après le GPU pourtant les appels d'opengl sont sensé être assynchrone, bref..., mais c'est surtout en 3D avec le dynamic environement mapping que ça bouffe mais je n'ai pas trouvé d'autre technique expliquée de manière à ce que je comprenne pour le faire donc voilà je laisse le moteur comme ça pour l'instant tant que je n'ai pas d'aide je ne pourrai pas faire mieux. Si il faut que je spécialise le moteur dans un type de jeux bien précis je le ferai surtout pour un mmorpg en 2D iso. Mais ça n'empêche pas que on peut aussi l'utiliser pour créer d'autres types de jeux comme par exemple un FPS en 3D, à la base c'était le but de pouvoir créer n'importe quel type de jeux. Le moteur de jeux est presque terminé en soit, je n'ai plus qu'à coder des jeux avec, corriger les derniers bugs, tester certaines fonctionnalités du moteur que je n'ai pas encore pu tester. L'éditeur est générique et a été fait pour coder n'importe quel type de jeux c'est à dire qu'il n'y a qu'un éditeur de niveau (pour l'instant que des niveaux en 2D, je dois encore coder l'éditeur pour des niveaux en 3D mais ça sera pour plus tard) mais tout le reste doit être codé soi même il n'y a pas de génération de code comme avec unity et unreal engine parce que je ne voulais pas faire un moteur qui fait des clônes de jeux existant ou seul les assets peuvent changer. Je veux laisser plus de liberté au développeur.

J'ai commencé à mettre à jour la documentation, et à faire des tutoriels vidéo sur l'éditeur de niveau. (ODFAEG Creator)
L'interface graphique de l'éditeur de niveau est à améliorer on me l'a déjà fait remarqué mais comme je suis développeur et pas UI Designer je galère à faire quelque chose de beau. (Exemple d'une vidéo sur la création d'animations en 2D)

Je dois encore faire les vidéos sur l'éditeur de niveau :

-La création de particules
-Création des ombres.
-Création de la lumière.
-Définir les collisions.
-Créer des objets définis à l'aide de fichiers c++. (Quêtes, monstres, etc...)

Bref tout ça est déjà codé, mais je dois encore faire les vidéos.

[Laurent7601]

Salut!
J'ai corrigé les exemples de code dans la doc qui ne s'affichaient pas bien, j'ai dû remplacer < par &lt; et > par &gt; et ça & par &amp; dans le code html.

Pour le FPS bas c'est le problème je pense que le GPU à beaucoup de choses à dessiner (même si il n'y a pas beaucoup d'objets sur la scène, je dois la dessiner quand même pas mal de fois) et même si les appels à opengl sont asynchrone, je pense qu'à la méthode display le CPU attend après le GPU pour que la frame courante soit dessinée avant de l'échanger.
Et si je fais le rendu dans un autre thread je pense que ça poserait problème car le personnage avancerait plus vite que ce que les graphismes se remettraient à jour donc ça créerait des incohérences.

Donc je n'ai pas vraiment de solution pour optimiser cela pour l'instant.

[Laurent7601]

Salut! Je pense que j'ai une idée sur le pourquoi du fps si bas mais je n'ai pas encore testé.
En fait je pourrais peut être rendre les ombres, les lumières, la réfraction et la scène avec un thread chacun pour que ça se fasse en parallèle et utiliser une primitive de synchronisation pour synchroniser les déplacements avec le rendu. (Genre attendre que tout les renderers aient fini de dessiner avant de continuer dans la boucle principale)
Ca pourrait peut être augmenter les temps par 4.
Je pense que si le fps est bas c'est parce que je fonctionne encore en monothread hors qu'il y a beaucoup de choses à dessiner. Un membre de ce forum m'avait conseillé de ne pas commencer par le multithreading comme je le faisais avant mais je pense que le temps est venu pour moi de m'y remettre.

EDIT : non en fait j'ai essayé mais ça ne fonctionne pas. C'est pas top les threads avec opengl non seulement il y a des choses qui ne s'affichent pas à l'affichage mais en plus le FPS ne monte pas donc...

[Mat.M]

EDIT : non en fait j'ai essayé mais ça ne fonctionne pas. C'est pas top les threads avec opengl non seulement il y a des choses qui ne s'affichent pas à l'affichage mais en plus le FPS ne monte pas donc...

dans le SDK de Direct X 11 il y a des exemples qui montrent comment faire des threads avec.
Mais je suppose que ça doit être possible aussi avec Vulkan...
d'une manière ou d'une autre avant d'activer la grosse artillerie du multithreading vous devriez vous concentrer sur les fonctionnalités de base d'un moteur 3d
*pouvoir charger des meshes 3d au format obj, fbx etc
*pouvoir créer des lumières dans la scène et gérer l'illumination
*pouvoir créer des entités animées donc au besoin développer un module de key framer
*pouvoir créer des objets 2d comme les billboards
*pouvoir créer des terrains dans la scène donc créer un éditeur de terrains.
*gérer l'optimisation spatiale avec au besoin en utilisant la technique de l'occlusion culling
....
Cela fait beaucoup donc au final oui ça serait peut-être mieux de prendre le Unreal Engine toutes ces fonctionnalités sont déjà câblées

[LittleWhite]

Pareil que Mat.M.
Juste pour être sûr que vous le savez : OpenGL n'est pas conçu pour une utilisation en parallèle. Et ce n'est pas juste moi qui le dit : https://stackoverflow.com/questions/...ring-on-opengl
Et Vulkan, en effet, vise à apporter la possibilité de multihread le rendu (entre autre).

Mais cela ne veut pas dire que vous ayez besoin de migrer vers Vulkan. J'imagine que comme vous parlez de performances, vous vous appuyez sur des logiciels dédiés pour les performances graphiques (C++ chrono, les appels OpenGL pour obtenir des informations depuis le GPU/le pilote, ou encore, RenderDoc). Sinon, jamais vous ne saurez ce qui se passe. Et commencez par juste afficher un cube 3D, qui tourne (ou qui ne tourne pas) et voir si ça se passe bien côté performance (Extra note au cas ou : un cube 3D qui tourne n'a pas besoin de mettre à jour les tampons de sommets (vertex buffer, index buffer)). D'ailleurs, un moment, l'objectif des développeurs, c'était de réduire tous les transferts CPU -> GPU, ou autrement dit, on évite de mettre à jour les tampons de ces objets 200 fois par seconde.

[Laurent7601]

Ok j'ai fait une optimisation, j'ai laissé tombé les threads parce que on ne m'a pas conseillé de les utiliser avec opengl et ça crée des problèmes d'affichage. Mais j'ai utilisé des mutex et ça règle certains problèmes d'affichage que j'avais avant et mon FPS à doublé (je suis passé de 15 à 30) mais c'est encore trop peu.

Le soucis je pense sont les transferts CPU=>GPU que je vais essayer de réduire.

Mat.M : je fais déjà tout ça...

[Laurent7601]

Salut! J'en ai parlé à mon frère à propos de la lenteur il me dit que c'est parce que ma carte graphique elle est trop ancienne j'ai une gtx 1660 super et maintenant c'est les rtx ma carte graphique elle date de 5 ans et il m'a dit que lui il a une carte graphique de 2 ans et le dernier assassin's creed il ne tounerait pas dessus parce que maintenant c'est du raytracing et sa tour ne serait pas assez rapide et la mienne non plus n'est pas assez rapide pour du raytracing. (En effet je tourne à du 1 FPS en raytracing avec compute shader)

[Laurent7601]

Salut! On m'a donné quelque conseils pour essayer d'optimiser. Déjà je vais essayer une autre technique que le dynamic environment mapping car :
-Ca fait baisser beaucoup le FPS.
-Ca ne donne pas de bon résultats en 2D.
Je vais essayer du displacement mapping mais simple comme l'exemple basic sur le site nvidia.

Je vais essayer de précharger les vbos pour éviter de les remettre à jour à chaque frame par contre me faudra mettre à jour les indices des objets visibles à chaque frame. :/

On m'a dit de mettre les infos relatives aux mesh dans un SSBO plutôt que un VBO..., seulement pas d'index buffer pour un SSBO donc remise à jour à chaque frame pour avoir le bonne gl_InstanceID ?

[Laurent7601]

Salut! J'ai trouvé une idée pour optimisé le temps de rendu!!!
Mais je n'ai pas encore testé j'ai eu cette idée en parlant avec dragonjoker sur discord. (le créateur du moteur de rendu castor3D)

Apparemment les transferts CPU=>GPU coûte cher donc j'ai décidé de les réduire aux maximum.

Voici comment je compte faire :

-Mettre chaque donnée de sommet dans un SSBO et chaque donné des matériaux dans un autre SSBO.
-Créer un VBO par entité mais à la place de lui passer les positions de sommets je vais lui passer l'ID de l'entité et l'ID du matériel.
-Trier les entité par type de primitive et dessiner tout en multiDrawIndirect.
-Récupérer les données dans le SSBO du shader grâce à l'ID de l'entité et l'ID du matériau et glDrawID et glInstanceID.

Il n'y a que les entités dynamiques ou je devrais remettre à jour les sommets ou le matériel dans les SSBO. Pour tout le reste plus de transfert.
En fait je pensais que les draw calls étaient gourmand donc je les ai réduits au max mais dragonjoker m'a dit que ce sont les transferts CPU=>GPU qui sont le plus gourmand donc voilà pourquoi j'ai mal codé le moteur.

[Laurent7601]

Bon j'ai essayé une technique qu'utilise le moteur de rendu Castor3D pour réduire les transferts CPU=>GPU (le vertex pulling) mais c'est moins performant sans doute parce que je fais un draw par mesh même si je le fais en multiDrawIndirect.

Donc le problème de lenteur ne vient peut être pas des transferts CPU=>GPU mais peut être d'ailleurs mais je ne sais pas de ou. (Surtout pour le dessin sur la cubemap j'ai l'impression que le driver ou la CG est lente même avec un seul objet réflectable!)

Ce que je vais faire c'est mettre les données des mesh et matériaux dans un SSBO plutôt que de les passé en attribut de sommet comme dragonjoker m'a conseillé de le faire.

En parlant de lui on ne le voit plus trop sur développez.

[LittleWhite]

Donc le problème de lenteur ne vient peut être pas des transferts CPU=>GPU mais peut être d'ailleurs mais je ne sais pas de ou.

Je le dis encore une fois, utilisez un profileur, utilisez les outils de débogages, utilisez les fonctionnalités de débogage d'OpenGL.

[Laurent7601]

Salut j'ai déjà utilisé un profiler mais je ne vois pas comment optimisé les fonctions les plus gourmandes. Les push_back sont assez gourmand mais lorsque j'essaye de les remplacé par des resize ça n'optimise pas non plus. J'ai essayé faire du vertex pulling mais ça n'optimise pas non plus. Rien de ce que je fais n'optimise je commence à croire que c'est le matos le problème ou le driver mais pas mon code...

[Laurent7601]

Salut! J'ai commencé à mettre les données des matériaux et des mesh dans un SSBO plutôt que dans un VBO pour réduire la consommation en mémoire.

Ensuite je vais nettoyé le code (retirer tout le code que je n'utilise plus) et passer un bon coup de profiler pour voir ou ça coince au niveau des perfs.

Et enfin je pourrai entamer la gestion des animations squeletique.

[Laurent7601]

Salut! J'ai fini de mettre à jour les renders pour qu'il consomment moins de VRAM. Je dois nettoyer le code que je n'utilise plus maintenant et essayé d'améliorer les perfs et si j'y arrive je commencerai à gérer les animations squelettique.

[Laurent7601]

Salut!

Après de nombreuses réflexions j'ai décidé de continuer l'implémentation Vulkan de mon moteur de jeux. En effet, les moteurs de jeux vidéos populaire utilisent vulkan donc si je veux avoir une chance que mon moteur de jeux devienne populaire je dois utiliser des apis modernes.

J'ai commencé à implémenter les per-pixel-linked-list avec vulkan, ça fonctionne mais je dois encore optimiser parce que c'est trop lent. (Faire un std::vector des différents pipelines graphiques et des descriptors et choisir le bon en fonction d'un id au lieu de les recréer à chaque draw call)

Je garde néanmoins la compatibilité avec openGL même si je crois que cette api va disparaitre à petit feu...

[Laurent7601]

Salut! J'ai corrigé plusieurs bugs du à l'implémentation Vulkan, et j'ai fais en sorte que la compilation du moteur en mode shared fonctionne.

Les per-pixels-linked-lists fonctionnent avec vulkan mais je n'ai pas encore fini d'implémenter toute les méthodes draw de ce renderer.

Par contre je n'ai toujours pas trouvé le problème de lenteur avec opengl peut être que avec vulkan en mode multi-thread ça résoudra ce problème mais personnellement je pense que non...

Il y a du changement avec la classe Application, désormais elle est template et j'utilise CRTP, il faut lui passer le type de l'application dérivée et le type pour le cache de ressources.

Grâce à la classe application vous n'avez pas à vous soucier de l'ordre de destruction des objets vulkan. (parce que les ressources ne peuvent être détruites avant la destruction du device)

[Laurent7601]

Salut, j'ai amélioré les performances avec mon renderer vulkan : Au lieu de recréer les buffers et mettre à jour les descripteurs sets à chaque draw call je ne le fait que si la taille des données à mettre à jour est plus grande que la taille actuelle des buffers.

Je ne sais pas si je vais mettre à jour le code openGL par contre. Ca me fait plus de code à maintenir pour une appli qui va probablement disparaitre.

[Laurent7601]

Salut!
Je suis repassé sous opengl (sous vulkan, j'ai que des soucis : notamment imageAtomicExchange qui met des valeurs qui sont toujours null dans mon image 3D mais pas de problème pour les images 2D, je n'ai pas ce problème avec opengl).
J'ai trouvé ce qui ralenti : le calcul des normales, je ne le fait que quand c'est nécessaire et plus à chaque frame je suis passé de 15-20 FPS à entre 30 et 90 FPS. (ça dépend si je me déplace ou pas)

J'ai besoin de rendre mon moteur multi-thread, surtout pour la recherche des entités visible à l'écran...