Discussion :

[LittleWhite]

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)

Hum, ..., les normales... ça ne se recalcule pas (sauf si le modèle 3D change de forme, peut être).

[Laurent7601]

Salut! Oui je ne les change pas.

Par contre le bug vulkan c'est parce que mon image3D n'est pas complètement effacée lorsque le shader la lit, même avec une barrière...

[Laurent7601]

Salut, j'ai reporté le bug sur le forum de nvidia avec un code minimal, en attendant que ça soit réglé, je vais continuer avec opengl..., la prochaine étape ce sont les animations squelettique...

[LittleWhite]

J'espère qu'ils pourront vous aider .

[Laurent7601]

Salut, j'ai fini d'implémenter les "bones animations" mais je dois encore améliorer les perfs parce que ça consomme pas mal côté CPU...

[Laurent7601]

Salut! Je viens d'améliorer encore les performances du moteur grâce au multi-threading.

Dommage que j'ai ce bug avec vulkan sinon j'aurai aussi pu faire un thread pour enregistrer les commandes de rendu.

[Laurent7601]

Et voilà ma première animation 3D. (Le fps est bas parce que je suis en mode debug)

[Laurent7601]

Salut! Je suis entrain d'attaquer la 3D avec l'éditeur parce que j'ai envie de m'amuser un peu. J'ai commencé à générer un sol en 3D et l'éditer (modifier la hauteur à l'aide de la molette de la souris), j'ai également implémenté le chargement de modèles 3D et corrigé un bug avec l'outline qui ne s'affichait pas bien. Je dois encore implémenter le système de guizmos en 3D pour transformer les objets et ça sera déjà bien...

Après la 3D fini je m'attaquerai à l'amélioration de l'éditeur de scripts et je pourrai enfin commencer à créer des jeux!!! (Bien que mon moteur gère la 3D je pense commencer en 2D iso...)

EDIT : J'ai implémenté un rectangle de sélection pour sélectionner les tiles du sol en 3D et ça marche plutôt bien.

[Laurent7601]

Salut, voilà ce qui explique les problèmes que j'ai eu avec std::bind et comment mon moteur m'a permit de les résoudre :

https://copilot.microsoft.com/chats/...cNaYp3mutZ5wBN

D'après l'IA c'est une implémentation en béton que les ingénieurs du c++ moderne et de la méta-programmation font.

[Laurent7601]

Salut! J'arrive petit à petit à corriger les bugs vulkan. J'avais passé une mauvaise taille à l'image donc le shader lisait à un endroit "vide".

Je pense donc continuer l'implémentation vulkan. Par contre j'ai une chute du FPS quand je suis passé de opengl à vulkan..., peut être trop de waitForIdle..., sinon les pipelines je les crée au début et je sélectionne le bon au rendu et je fais très peu de mise à jour de descriptors sets...

Mais bon j'ai ma texture de réfraction qui s'affiche correctement (enfin) et mes per pixel linked list fonctionnent, je n'ai plus qu'à implémenter le renderer des ombres et des lumières. (Ce que j'aime le moins comparé à opengl c'est qu'il faut paramétrer tout les descripteurs à chaque fois...)

Bref vulkan c'est plus barbant, que difficile finalement.

[Laurent7601]

Salut, je dois utiliser la SDL2 avec vulkan plutôt que glfw pour le portage androïd, mais tout faire seul ça commence à être lourd, alors j'aimerais trouver des dévs ne fuses que pour faire des petites choses...

Je dois finir l'implémentation vulkan, optimiser l'implémentation vulkan, faire la gestion des scripts avec l'éditeur, améliorer l'éditeur (l'interface graphique de l'éditeur, les composants guis, etc...), bref j'ai encore pleins de choses à faire, et je crois bien que j'en ai pour toute une vie..., ça fait déjà 10 ans que je suis sur le projet, et j'ai l'impression que je suis null part, car en plus :

Les choses ce modernises, le nombre de plateformes à gérer se multiplie, etc...

Par contre je ne pourrai plus maintenir à la fois le code opengl et vulkan, comme je ne peux pas maintenir le système ECS (avec entt) et le système Entity et fonctions virtuelles, donc le système ECS ne sera plus à jour j'ai besoin des fonctions virtuelles pour les plugins avec l'éditeur. La version opengl ne sera plus non plus remise à jour... (enfin si j'arrive à avoir de meilleurs perfs avec vulkan surtout pour le portage, et si j'arrive à avoir le même rendu que avec opengl c'est à dire 60 FPS au moins en 3D avec les lumières, les ombres, la réfraction/réflection, les per pixels linked list et les animations squelettique)
Et encore j'ai une CG veille de plus de 5 ans, une gtx 1660 super et pas une rtx..., sur une rtx le FPS devrait encore être meilleur.
Quand mon PC sera foutu et si le moteur marche bien je pense racheter un PC un plus puissant et faire du raytracing.

[dragonjoker59]

peut être trop de waitForIdle...

Tu ne devrais pas en avoir un seul...
Si, un seul, à la fermeture de l'appli, avant de cleanup tous les objets Vulkan

[PixelJuice]

mais tout faire seul ça commence à être lourd

Il s'agirait aussi de tirer des conclusions un jour ou l'autre. Déjà que trouver des collaborateurs pour des projets palpitants c'est compliqué, alors pour un moteur maison un peu chimérique, j'imagine pas la difficulté. Tu n'as jamais eu l'occasion d'en trouver un seul en 10 ans ?

... je crois bien que j'en ai pour toute une vie..., ça fait déjà 10 ans que je suis sur le projet

Là aussi, il faudra en tirer des conclusions. On te voit chaque semaine passer du coq à l'âne :

- Pas Vulkan
- Finalement si Vulkan
- Finalement non pas possible Vulkan
- En fait bon si Vulkan

Il faudrait que tu murissent mieux tes décisions, surtout quand elles impliquent des milliers de lignes de codes au bas mot.

Mais à la base, tu ne voulais pas faire un jeu ? Comme tu le disais dans ton premier post, ou dans ce post plus récent :

Après la 3D fini je m'attaquerai à l'amélioration de l'éditeur de scripts et je pourrai enfin commencer à créer des jeux!!!.

Je ne sais pas si tu as déjà fait un jeu ou ne serait-ce qu'un concept, mais c'est un métier complètement différent. Rien que le Game Design, c'est un sacré morceau. Et je ne parlerai même pas des assets bien évidemment.

D'ailleurs pour moi, la meilleure option que tu aurais du choisir aurait été de faire un jeu (voir des jeux) en parallèle de ton moteur. Ou chaque élément dont tu as besoin deviendrait une fonctionnalité dans le moteur. C'est d'ailleurs comme ça que les premiers moteurs ont vu le jour, enrichis de fonctionnalités aux travers des nouveaux jeux créer par les développeurs. Faire un moteur de A à Z dans un but purement fonctionnel requiert une sacré expérience de base dans le Game Dev.

Tu remarqueras d'ailleurs que Unity n'a jamais fait de jeu, et que l'Unreal Engine était un moteur maison interne à la base. On voit bien là, 2 façons de faire bien distinctes.

... et si le moteur marche bien je pense racheter un PC un plus puissant et faire du raytracing.

Quel sera le modèle commercial de ton moteur d'ailleurs ? License unique ? Souscription ? Royalties ?

---

Je tiens d'ailleurs à dire que je suis contre l'hégémonie des gros moteurs commerciaux et qu'il faudrait beaucoup + de choix de nos jours, et donc que j'encourage les moteurs comme le tien. C'est d'ailleurs un crève-cœur de voir certains gros studios abandonner leurs moteurs maison et je pense qu'on va droit dans le mur. Mais la bonne volonté ne suffit pas, il faut aussi proposer quelque chose qui serait, ne serait-ce que fonctionnel.

Au moins déjà que tu réfléchisses à ce que tu veux être vraiment : Un développeur de moteur ou un développeur de jeu vidéo ?

[LittleWhite]

Je tiens d'ailleurs à dire que je suis contre l'hégémonie des gros moteurs commerciaux et qu'il faudrait beaucoup + de choix de nos jours, et donc que j'encourage les moteurs comme le tien. C'est d'ailleurs un crève-cœur de voir certains gros studios abandonner leurs moteurs maison et je pense qu'on va droit dans le mur. Mais la bonne volonté ne suffit pas, il faut aussi proposer quelque chose qui serait, ne serait-ce que fonctionnel.

J'aime beaucoup cet opinion (et globalement, je suis d'accord par rapport à l'hégémonie). Par contre, avez-vous vu, il y a plein de moteur de jeux disponibles, notamment sur Github, plus ou moins abouti. Et il y a des moteurs pour presque chaque langage de programmation aussi , avec en tête le C++ et le C#. Donc, je ne suis pas certain qu'il y a hégémonie.

[Laurent7601]

Le problème c'est faire un jeux seul avec mon moteur, j'ai déjà essayé, mais je me suis rendu compte que sans équipe ne fuse que pour le gameplay et la création de niveau et les graphismes, c'est compliqué, c'est plus simple de faire un moteur pour commencer. Et après je verrai, je commence à maîtriser vulkan et le multiplateforme et ça me plait bien donc, ça va bien.

Par contre j'ai décidé de retirer la dépendance de la SFML, je vais juste utiliser la SDL pour le fenêtrage avec vulkan pour le multiplateforme, l'implémentation opengl du moteur va devenir dépréciée d'ailleurs ça m'embête de devoir passer à openglES et une autre version d'opengl pour juste passer à androïd.

J'ai décidé d'améliorer mon moteur donc, pour avoir quelque chose d'utilisable pour créer un jeux, j'ai commencé à améliorer aussi les classe mathématique avec une seule classe pour les vecteurs 2D, 3D et 4D et je vais faire pareille pour les matrices.

Il y a des moteurs qui ont 5 ans et qui développent déjà des jeux pour desktop et androïd, il faut vraiment que j'arrive à ce niveau là.

[Laurent7601]

Salut! J'ai fait des classes plus génériques pour les matrices et vecteurs de n'importe quel taille, j'ai retiré les waitForIdle et rajouté des sémaphores, j'ai également retirer la dépendance SFML mais j'ai un soucis avec le son...

[Laurent7601]

Salut! Depuis que j'utilise des std::array pour vecteur et matrices, l'affichage avec opengl foire. (Ecran noir), hors que vulkan transfert bien mes std::array dans mes buffers, même des std::array à 2 dimentions (mes matrices) hors que avec opengl non.

Donc faut faire des conversions pour avoir des tableaux classique et les passer aux buffers.

Bref je trouve que opengl finallement n'est vraiment pas pratique comparé à vulkan (le multithreading foire, quand j'utilise des std::array et que je les passe aux buffers ça foire hors que ça marche bien avec vulkan même avec des std::array à plusieurs dimensions, faut utiliser un geometry shader en plus pour dessiner sur les 6 faces d'une cubemap hors que avec vulkan ce n'est pas nécessaire grâce à multiview, vulkan est plus explicite donc moins de bugs hazardeux suites aux glBind et grâce à renderdocs facile pour débuguer car avec opengl renderdocs ne supporte pas certaines de mes fonctions opengl donc pas de capture de frames, debugPrintf aussi qui simplifie le débugage grâce à renderdoc j'ai pu voir ce que contenait mes buffers et j'ai pu voir que mes matrices n'était pas initialisées correctement donc j'ai pu corrigé un bug d'affichage.)

Bref je vais devoir changer tout le reste du code de mon moteur, et un petit peu le code de mes projets utilisant le moteur je pense que cette perte de temps sera un gain au final.

Donc l'implémentation opengl ne fonctionne plus et ne sera plus mit à jour...

[Laurent7601]

Bonjour après une longue pause j'apporte quelque nouvelles : finalement j'ai décidé de faire 2 versions, une pour opengl et une pour vulkan, malgré mes essais d'optimisation avec vulkan (multi-threading, double buffering, etc...), vulkan reste plus lent qu'opengl sur ma GTX 1660 super. De plus j'ai un bug graphique avec vulkan pour dessiner les outline avec le stencil buffer même si tout est paramétré correctement j'ai vérifié avec renderdoc pour voir si j'avais bien les bonnes valeurs dans le stencil buffer et l'ordre des draw calls et j'ai bien des 1 à l'emplacement du modèle 3D mais malgré cela, l'outline s'affiche toujours au dessus de mon modèle 3D comme si il ignorait le paramètre not_equal du stencil buffer. (Driver bug?) Pourtant ça marche parfaitement bien avec opengl l'outline. Ici je vais finir le portage vers vulkan mais après je repasse sous opengl pour finir l'éditeur...

[Laurent7601]

Mes revenus ayant diminué à cause de l'endettement publique dans mon pays, je vais devoir compenser par autre chose, j'ai décidé donc de faire une version pro utilisant vulkan payante et une version gratuite utilisant opengl. Pour le moment je suis entrain d'optimiser la version vulkan à l'aide de threads de rendu et je vais aussi faire du double buffering ça devrait me donner un meilleur FPS que la version opengl parce que pour l'instant le FPS avec la version vulkan est encore trop pas. J'ai corrigé un bug aussi avec l'outlining côté vulkan.

Je n'ai plus qu'à optimiser la version vulkan et à porter le code opengl pour la skybox et les animations squelettes et j'en aurai terminé pour le portage vers vulkan. Après je compte continué l'éditeur de niveaux et de script pour la version opengl et je terminerai par le porter à vulkan. Mais ça va être dur à moi tout seul de faire quelque chose qui peut concurrencer les moteurs de jeux existant donc je suis ouvert à tout coup de main. J'ai vraiment envie de faire de ma passion, mon métier.

[dragonjoker59]

Aucun intérêt de faire une version payante, personne ne l'achètera...