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...