Discussion :

[Laurent7601]

ODFAEG est un moteur de jeux générique et complexe. (Sérialisation boost-like (pour sauvegarder/lire mes scènes), compteur compile-time, delegates générique, dispatchers, un BHV extensible dynamique (pour l'optimisation) avec possibilité de les passer dans des buffers GPU, GameObjects hirérachiques avec héritage pour les objets du moteur et système ECS pour les jeux plus complexe, système de réflexibilité pour la gui, système de chargements de ressources multiples, système de gestions de states. Et ça, s'est juste la base du moteur. A cela il faut rajouter tout ce que le moteur rend : particules, animations (skinning/morphing), objets statiques, lumières/ombres et réflexion/réfraction. (Je suis entrain de migrer tout ça vers mon pipeline hybride pour un rendu physiquement plus correct parce que avec le rasterizer je ne fais que de tricher) Et encore je n'ai pas encore écris de code pour le fog volumétrique. Au niveau technique tout fonctionne, ce qui prend du temps c'est le branchement de toutes ces features dans la version finale du moteur et surtout le réfractor de la gui! Je vais abandonner les features disproportionnées, genre faire mon propre edi, je vais juste faire un système de hot reload pour placer des breakspoints sur scripts édité avec VS. (Comme unity)

[Laurent7601]

Salut! Je vais arrêter de parler architecture technique, ça fait fuir, ici je suis entrain d'améliorer mon pipeline RT pour l'afficher de l'éclairage/ombres et des reflets. (Comme on me l'avais demandé) Je vais juste présenter des rendus donc ici, plus parler architecture.

[LittleWhite]

Bonjour,

Vous pouvez parler architecture si vous le souhaitez, simplement, je tiens à porter à votre attention les points suivants :

• vous faites plus souvent une liste de points ou vous dites "j'ai implémenté telle ou telle truc" que vraiment parler d'architecture. Le public ici étant plutôt avancé techniquement, vous pouvez être plus détaillé dans les descriptions de vos implémentations ;
• vos choix ne sont pas à discuter (et rarement avec une argumentation de pourquoi vous faites ci ou ça), par conséquent, il n'y a pas de place où répondre (donner notre avis) ;
• les captures de rendu c'est bien, mais sachant que cela fait plusieurs mois que l'on voit les mêmes captures de boîtes en bois, qui n'ont toujours pas d'ombres, chose que j'avais discuté alors et de rendu bizarre pour la voiture + la scène bistrot..., c'est dur de vraiment juger si vous avancez ou non. Les changements d'architecture devraient apporter des choses concrètes, généralement, on les estime avec des benchmarks (performance, mémoire...). Du coup, cela ressemble beaucoup à : j'ai changé d'architecture, mon moteur supporte ces N fonctionnalités, mais rien de visible et rien de concret, sur lequel on pourrait discuter.

Mais vous faites comme bon vous semble

[Laurent7601]

Bonjour,

Vous pouvez parler architecture si vous le souhaitez, simplement, je tiens à porter à votre attention les points suivants :
vous faites plus souvent une liste de points ou vous dites "j'ai implémenté telle ou telle truc" que vraiment parler d'architecture. Le public ici étant plutôt avancé techniquement, vous pouvez être plus détaillé dans les descriptions de vos implémentations ;
vos choix ne sont pas à discuter (et rarement avec une argumentation de pourquoi vous faites ci ou ça), par conséquent, il n'y a pas de place où répondre (donner notre avis) ;
les captures de rendu c'est bien, mais sachant que cela fait plusieurs mois que l'on voit les mêmes captures de boîtes en bois, qui n'ont toujours pas d'ombres, chose que j'avais discuté alors et de rendu bizarre pour la voiture + la scène bistrot..., c'est dur de vraiment juger si vous avancez ou non. Les changements d'architecture devraient apporter des choses concrètes, généralement, on les estime avec des benchmarks (performance, mémoire...). Du coup, cela ressemble beaucoup à : j'ai changé d'architecture, mon moteur supporte ces N fonctionnalités, mais rien de visible et rien de concret, sur lequel on pourrait discuter.


Mais vous faites comme bon vous semble

Salut! Hé bien c'est justement ce que je suis entrain de faire!!! Débuguer la voiture et les ombres!

J'ai corrigé un bug dans mon shader pour les ombres pour mon push_constant pour la vue je m'étais trompé j'avais déclaré un int au lieu d'un mat4 et vulkan a laissé passé!

Voici ce que ça donne (Cascaded shadow mapping et point light) :


La prochaine étape sera d'ajouter et débuguer mon rendu PBR.

Et pour la voiture :

Le 8 est à gauche donc c'est bien dans le bon sens cette fois!

[Laurent7601]

J'ai écris un début de code de mesh shader, pour optimiser mon rendu qui est encore trop lent avec les mesh shaders, suite au grand nombre de meshlets et la limite des mesh-shader qui ne peuvent générer qu'un petit nombre de sommets/primitives par invocation. J'ai repris ma grille extensible de la version précédente du moteur, et chaque cellule à son octree de clusters. Je n'ai pas encore compilé le code mais, dans le compute shader qui génère mes commandes de dessins ça donne ceci : (J'ai pas mit tout le code, juste la fonction intéressante)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
void setMeshletsFromBox(AABB frustrum, int lod, Object object, SubMesh sm, inout TaskData taskData) {   
    uint stack[32]; 
    uint sp = 0;    
    uint tmpX = frustrum.center.x - frustrum.size.x * 0.5;
    uint tmpY = frustrum.center.y - frustrum.size.y * 0.5;
    uint tmpZ = frustrum.center.z - frustrum.size.z * 0.5;
    for (uint i = tmpX; i < (frustrum.center.x - frustrum.size.x*0.5) + frusturm.size.x; i+= pc.gridCellSize.x) {
        for (uint j = tmpY; j < (frustrum.center.y - frustrum.size.y*0.5) + frusturm.size.y; j+= pc.gridCellSize.y) {
            for (uint k = tmpZ; k < (frustrum.center.z - frustrum.size.z*0.5) + frusturm.size.z; k+= pc.gridCellSize.z) {
                //Root.
                uint cellId = (tmpX / pc.gridCellSize.x) + (tmpY / pc.gridCellSize.y) * pc.nbCellsPerRow.x + (tmpZ / pc.gridCellSize.z) * pc.nbCellsPerRow.y;
                stack[sp++] = inputClustersBuffer.clusters[inputGridBuffer.grid[cellId].clusterId].id;
 
                while (sp > 0) {
                    uint id = stack[sp--];
                    Cluster n = nodes[id];
                    if (!intersects(frustrum, c.globalBounds)) {
                        continue;
                    }
                    if (n.leaf && n.lod == lod && n.id ==  sm.clusterId) {
                        taskData.meshDrawCommand.y++;
                        taskData.meshDrawCommand.z = 8;
                        taskData.meshletCount = n.meshletCount;
                        atomicAdd(offsetsData[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].offsets.clusterOffest, 1);                        
                        outputClusters[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].clusters[meshletOffset] = cluster;  
                        //Height visible : on génère.
                        if (object.renderType == 1) {                                                
                            outputClusters[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].clusters[meshletOffset] = cluster;  
                            for (uint i = 0; i < 4; i++) {
                                uint offset = atomicAdd(offsetsData[primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].offsets.heightOffset, 1); 
                                heights[offset] = inputHeightsData.heights[sm.vertexOffset+i];
                                taskData.heightCount++;
                            } 
                        }                            
                    } 
                }
            }
        }
    }
}

Faut encore que je finisse de coder le côté CPU pour envoyer toutes les infos au GPU avant de faire un benchmark. J'espère que ça sera plus rapide ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
TaskData taskData = taskDatas[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].taskData[payload.taskId];
 
        SubMesh subMesh = SubMeshDatas[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].subMeshData[payload.taskId];
        Cluster cluster = clusterDatas.clusters[taskDatas[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].taskData[payload.taskId].clusterOffset+gl_WorkGroupID.y];
        uint id = gl_WorkGroupID.z;
        if (id >= cluster.meshletCount) {
            return;
        }
        //Instance id = taskId (base instance) + workGroupId.x (instance id).
        uint instanceId = taskDatas[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].taskData[payload.taskId].baseInstance + gl_WorkGroupID.x;
        //debugPrintfEXT("Instance id : %i", gl_WorkGroupID.x); 
        mat4 modelMatrix = modelDataBuffer[pc.primitiveType*MAX_FRAMES_IN_FLIGHT+pc.currentFrame].modelData[instanceId].modelMatrix;
 
        MeshLet meshlet = meshletDatas.meshlet[cluster.meshletOffset+id];
        /*if (gl_WorkGroupID.y >= lodLevelData.lodLevel[subMesh.lodOffset+subMesh.lodLevel].meshletCount)
            debugPrintfEXT("meshlet offets : %i, %i", lodLevelData.lodLevel[subMesh.lodOffset+subMesh.lodLevel].meshletCount, gl_WorkGroupID.y);*/
        uint firstIndex = subMesh.indexOffset + lodLevelData.lodLevel[subMesh.lodOffset+subMesh.lodLevel].index_offset + meshlet.indexOffset;
        //debugPrintfEXT("First index : %i,%i", firstIndex, meshlet.vertexOffset);
        //3 = Triangles.
        uint maxVerts = 255u;
        uint maxPrims = 85u;
        uint vertexCount   = min(meshlet.nbVertices, maxVerts);
        uint primitiveCount = min(meshlet.nbIndexes / 3u, maxPrims);
        /*if (vertexCount > 0)
            debugPrintfEXT("submesh vertex count : %i, %i", meshlet.nbVertices, meshlet.nbIndexes);*/
 
 
        SetMeshOutputsEXT(vertexCount, primitiveCount);
        for (uint i = 0; i < vertexCount; i++) {
            uint v = subMesh.vertexOffset + meshlet.vertexOffset + i;
            gl_MeshVerticesEXT[i].gl_Position = pc.projMatrix * pc.viewMatrix * modelMatrix * vec4(vertexData[pc.primitiveType].vertices[v].position, 1.0);
            fragColor[i] = unpackColor(vertexData[pc.primitiveType].vertices[v].color);
            fragTexCoord[i] = vertexData[pc.primitiveType].vertices[v].texCoords;
            normal[i] = mat3(transpose(inverse(modelMatrix))) * vertexData[pc.primitiveType].vertices[v].normal;
            materialID[i] = subMesh.materialId;
            primitiveType[i] = pc.primitiveType;
            currentFrame[i] = pc.currentFrame;
            //debugPrintfEXT("position : %i",  i);
        }
        for (uint tri = 0; tri < primitiveCount; tri++) {
            //debugPrintfEXT("gen tri : %i", tri);
            uint g0 = indexData[pc.primitiveType].indexes[firstIndex + tri * 3 + 0];
            uint g1 = indexData[pc.primitiveType].indexes[firstIndex + tri * 3 + 1];
            uint g2 = indexData[pc.primitiveType].indexes[firstIndex + tri * 3 + 2];   
            uint i0 = g0 - meshlet.vertexOffset;
            uint i1 = g1 - meshlet.vertexOffset;
            uint i2 = g2 - meshlet.vertexOffset;  
            /*if ((i0 >= vertexCount || i1 >= vertexCount || i2 >= vertexCount) && pc.currentFrame == 1)
                debugPrintfEXT("meshlet : %i,%i, %i, %i, %i, %i, %i",lodLevelData.lodLevel[subMesh.lodOffset+subMesh.lodLevel].meshletCount, subMesh.meshletOffset, subMesh.indexOffset, meshlet.nbIndexes, meshlet.nbVertices, meshlet.indexOffset, meshlet.vertexOffset);*/  
            gl_PrimitiveTriangleIndicesEXT[tri] = uvec3(i0, i1, i2);            
 
    }
}

[Laurent7601]

J'ai réfléchi sur les avantages et inconvénients des différents types de pipeline vulkan pour le rendu. L'idéal aurait été d'envoyer les gros meshes des meshes shaders au vertex shader, qui lui est plus rapide pour les "gros btachs" mais devient vite un enfer pour les batchs séparés (lorsque le nombre de draw commands sature). Mais les pipelines sont mutuellement exclusifs. Le rasterizer est plus rapide que le rt mais donne des résultats incohérents lorsqu'il faut suivre un rayon et les pipelines vulkans sont mutuellements exlusif. Alors j'en suis arrivé à cette conclusion => faire un rendu en 3 grandes passes :

✔ 1. Passe Vertex Shader
Pour les batches contigus :

gros meshes opaques

objets statiques

amortissement maximal

génération du depth buffer

génération du Hi‑Z

✔ 2. Passe Mesh Shader
Pour les clusters dispersés :

meshlets

LOD GPU

culling GPU

occlusion Hi‑Z

shadow maps

lighting clusters

passes secondaires

✔ 3. Passe Ray Tracing
Pour les translucides :

verre

eau

refractions

ombres RT

Avec bein sûr le compute pipeline pour faire le culling, mettre à jour les animations/particules, ainsi que le raymarching.

[Laurent7601]

Salut! J'ai beaucoup de code encore à test/déboguer au niveau du rendu. Un peu d'aide aurait été bien. Là j'ai presque terminé de réécrire mon code pour l'optimisation de mon compute shader de culling pour le mesh shading pipeline. Il me reste plus qu'à mettre à jour les descripteurs. Mais je dois encore tester/débugé cette partie + la mise à jour de mon code pour le raytracing. Et aussi le rendu PBR que je n'ai pas encore eu le temps de débuguer non plus. J'ai remarqué un problème potentiel de culling pour le rendu des ombres. Bref pas mal de bug à corriger, mais une fois çà de fait la réécriture du pipeline graphique sera presque terminée, il ne me restera plus que le post-processing (fog volumétrique) et reprendre le code précédent pour le rendu de la skybox et pour l'outlining.

[Laurent7601]

Le problème des moteurs de jeux vidéos existant AAA, c'est que même si on pense qu'ils sont gratuits, ils ne le sont pas entièrement, si tu veux utiliser tout le moteur il faut payer un abonnement mensuel, tu paies avant même d'avoir sorti le jeux. J'ai donc décidé de réalisé ce moteur de jeux AAA qui est gratuit. Je n'ai plus qu'à debug l'affichage et faire les effets "post-processing" et le module graphique sera terminé. Le reste, ce ne sera pratiquement que du recopiage de code depuis l'ancienne version. La documentation sera remise à jour également. Mais il n'y a pas vraiment de nouvelles features à part le piepline raytracing qui vient compléter le rendu déjà existant et le mesh-shading pour l'optimisation. C'est surtout une release d'optimisation, de correction de bugs. Dans cette release entre autre il y a :

-Une architecture GPU-Driven et un rendu de meilleure qualité.
-Clustered rendering.

Vous ne savez pas si j'avance ou pas car mes rendus sont très similaire, mais avec la version précédente du moteur, l'affichage de la voiture tournerais à 1 FPS, tellement c'était lent, maintenant le rendu est très fluide (je ne me rappelle plus du FPS exact mais au moins 1000) donc, même si je n'ai pas vraiment implémenté de nouvelles features, même si j'ai dû pratiquement tout réécrire le module graphique, j'ai vraiment l'impression que j'avance, et normalement, si tout va bien, d'ici fin de l'année, la release finale de cette version avec la gui devrait paraître, juste parce que je peux me permettre de coder jour/nuit maintenant et donc j'avance très vite. J'ai vraiment dû apprendre et me spécilaiser à la création de moteur, mes études étant en informatique de gestion, je n'ai aucun diplôme en création de jeux vidéos. Et ça n'a pas été simple.

Bistro (j'ai pas encore déplacé la caméra avec les inputs pour voir si elle se rend correctement maintenant), tourne maintenant à +/- 500 FPS, en vertex shader. Avant ça tournait à < 1FPS avec l'ancienne version, donc oui, j'avance!!! Le plus chiant c'est de faire les bugs d'affichage parce que les modèles que je prend du net n'ont pas les même convention (pour les uvs, pour l'andleness et donc pour le culling raster, si je ne transforme pas bien, et si le culling ou les uvs sont dans le mauvais sens ça créé des bugs d'affichage et c'est très chiant) Je dois encore faire des benchmark avec ma nouvelle implémentation cluster pour voir si ça augmente les perfs. Mais les MS sont plus performant pour générer de la géométrie. (là ou le batching et vertex shader serait trop lent, problème que j'avais avec opengl pleins de tiles et le batching CPU lent, car pas de mesh shaders ni de gpu driven)

[PixelJuice]

Le problème des moteurs de jeux vidéos existant AAA, c'est que même si on pense qu'ils sont gratuits, ils ne le sont pas entièrement, si tu veux utiliser tout le moteur il faut payer un abonnement mensuel, tu paies avant même d'avoir sorti le jeux.

C'est complètement faux.

- Unity & Unreal ont juste un plafond (très généreux) qu'il ne faut pas dépasser sinon il te faudra payer des royalties et / ou des licences. On parle là de plusieurs centaines de milliers d'euros, donc si tu dégages de tels sommes, je pense pas que les frais soient un réel problème. Unity avait encore des limites comme un splash screen obligatoire assez moche et un thème dark, mais maintenant, même plus besoin d'avoir une licence payante pour ça non plus.
- Godot c'est encore plus simple, il n'y a strictement aucun frais / limites.

Donc c'est totalement faux en plus d'être anachronique. Quand tu as commencé ton moteur, les moteurs (la version publique) que je cite étaient balbutiants. Donc même si c'était vrai, ce n'est même pas une excuse valable. Tu fais du révisionnisme sur l'histoire de ton propre moteur, c'est pas vraiment très cool de ta part.

Quid aussi des 99.99% autres développeurs qui ont fait leur jeu au lieu de faire leur propre moteur aussi ?

Vous ne savez pas si j'avance ou pas car mes rendus sont très similaire

A qui la faute ? On ne peut juger que sur ce que tu montres, personne ne fera l'effort de setup ton moteur pour tester de lui-même, surtout quand le dit moteur est réécrit quasiment chaque semaine. On voit les sempiternels mêmes cubes de bois dans la même petite fenêtre 300x300. Savoir présenter c'est aussi une compétence.

---

La vraie raison pour laquelle tu n'as pas fait un jeu vidéo c'est que tu ne sais pas faire de jeu vidéo. Inconsciemment ou pas d'ailleurs, mais tu fais un blocage là dessus et plus vite tu t'en rendra compte et mieux ce sera pour toi. Surtout que si tu fais un jeu avec ton moteur, tu vas immédiatement voir si ton moteur est viable ou non. Et si ce n'était pas le cas ? Je comprends que tu puisses avoir la trouille, mais il aurait fallu faire ça le + tôt possible.

C'est pour ça qu'on est tous ici à te rabâcher sans cesse qu'il faut que tu fasses un jeu au plus vite, avec ton moteur ou non :

- C'est ton but premier (je le rappel)
- Tu verras si ton moteur marche ou non (ça le rendra bien meilleur quoi qu'il arrive)
- Ca te changera les idées
- Tu apprendras de nouvelles compétences
- Tu auras enfin une vitrine pour ton moteur (la majorité des gens choisissent un moteur uniquement car ils ont vu les jeux qui ont été fait par celui-ci)

Et évidemment, un petit jeu sympa pour commencer, car tu n'es pas un développeur de JV (pas encore !). Je ne te conseille pas de faire un concept trop simple comme un Flappy Bird ou un clone de Tétris. Mais plutôt viser un concept de jeu simple mais très gratifiant. Pas d'histoire, pas de trucs fancy, juste du pur gameplay jouissif. Simple mais expansif, ou tu pourras ajouter tes propres idées petits à petits, te former au game design, etc ...

Pour les assets, fais du minimal, des cubes qui tire des petits cubes et c'est tout. Tu n'es pas un artiste, et ça tombe bien, la majorité des devs ne le sont pas. Tu pourras toujours remplacer les assets plus tard. Si c'est fun avec des cubes moches sans textures, ça le sera encore + avec des jolis modèles 3D.

Fais un concept qui te prendra juste 2 semaines et basta. Ca te fera un petit défi, ça ne change rien sur la roadmap de ton moteur (vu sa taille initiale gigantesque), tous les intervenants ici et moi-même seront ravis de t'aider dans tes aventures de développeur de jeu vidéo.

[Laurent7601]

Salut! C'est une très bonne idée! C'est ce que j'essaie de faire depuis, des années, malheureusement, quand j'ai avancé dans le jeux, y'avais toujours quelque chose qui n'allait pas :

-Soit les performances je ne pouvais faire que de la 2D. Ou des bugs d'affichage ou un plantage du jeu lors du stress test (depuis le passage à vulkan). (Mais ça va mieux de ce côté là maintenant depuis que j'ai eu l'aide de l'IA) La nouvelles version est plus propre, j'ai moins de code CPU, grace au GPU driven, et

Sinon j'ai développé un système de combat en temps réel, en réseau, qui fonctionne bien avec opengl (à 60 FPS sur ma gtx en 2D iso, pas fou, mais cétait suffisant). (J'ai test en réseau local)

Le problème : Je suis très perfectionniste, tout doit être parfait, l'utilisation du moteur doit être la plus simple et générique possible pour que je puisse créér le jeux. Le moteur évolue chaque semaine parce que, je me rend compte que voilà, ça, je n'aime pas, je veux changer, ou alors, tiens j'ai une nouvelle idée, je voudrais expérimenter. Mais je suis arrivé à un stade ou, je n'ai plus vraiment grand chose à expérimenter, l'ui (pour l'éditeur de map principalement) je devrais juste l'intégrer dans cette nouvelle version et la finir pour moi pouvoir créé mon premier jeux. Le modules physique et réseau et audio, le système d'overlay, je n'ai qu'à reprendre le code de l'ancienne version et l'intégré, y'a rien à réfractoré, ça va aller très vite, le plus long, c'était le module graphique qui est, un vrai challenge. Mais ici je n'ai plus qu'à débogué, éventuellement ajouté du post processing, la seule chose qui me manque encore vraiment. Donc ne t'en fait pas, au pire d'ici 2017 => je peux commencer à créer mon premier jeux avec mon moteur. Mais comme tu dis si bien, je ressens une sensation de "trouille", j'ai peur que ça crash, que j'ai des bugs d'affichage, que je doive débuguer. Mais l'architecture est très importante, car, si tu veux faire évolué ton jeux, il faut que tu puisses faire des mises à jour sans casser le code. Et stabilité et performance de mon moteur n'ont pas été chose facile. Surtout qu'au départ, je n'y connissais rien, j'ai du apprendre vulkan seul, avec des codes ou de la doc sur Internet, et l'aide de l'IA. Ca m'a prit, plus d'un an!!! C'est vraiment du bas niveau, vulkan ne fait pratiquement rien à part communiquer avec le GPU, toute la logique tu dois l'écrire toi même. Faut faire la génération de mip-maps soit même avec commande de blit (filtrage linéaire) ou un compute shader, l'anti-alisasing ne se fait pas non plus aussi simplement qu'avec opengl tu dois faire le résolve toi même également avec une commande ou un attachment, tu dois gérer la synchronisation GPU/CPU toi même, ainsi que les layouts transitions. Vulkan est très verbeux tu dois tout décrire les ressources que tu utilises dans les shaders. Bref la grande majorité du pipeline tu dois le programmer toi même. Pour les pipelines tu dois les créés et les binds y'a plus de changement d'états. C'est une api complètement différente de opengl que j'utilisais avec l'ancienne version du moteur, mais vulkan m'est devenu indispensable pour mon futur jeux. Opengl ne suffisait plus.

PS : Et je dois aussi suivre avec les messages du forum, par exemple, si on me demande à combien je peux afficher une scène comme bistro, très chiante car elle n'utilise pas le même culling order que celui de mon moteur. C'est là que je me suis rendu compte que j'avais eu des soucis de performance et que j'ai du réécrire pratiquement tout le module graphique.

[Laurent7601]

Beaucoup de débutant pense que les jeux font la réussite d'un moteur de jeux, mais c'est faux, ce qui fait la réussite d'un moteur de jeux, c'est faire un moteur avec une architecture pensée de telle sorte qu'il ne faïlle pas réécrire le moteur, pour faire évoluer un jeux que ça soit graphiquement (passage de la 2D à la 3D) ou au niveau du gameplay et de l'IA. Réécrire le moins possible, faire un architecture indépendante de l'API utilisée et portable, tout en étant stable et performante. Coder un tel moteur de jeux ça ne se fait pas en 1 an. J'ai mis 10 ans + 2 ans pour le backend vulkan en + du backend opengl. Mais ça me permet d'avoir une architecture qui, me permet, de durer. Je ne fais pas un moteur pour le show, et il ne faut pas forcément faire un jeux complet pour que quelqu'un d'autre puisse faire un jeux avec le moteur ou encore montrer que le moteur est capable de faire un jeu, complet. Créer un jeux c'est de l'ajout de contenu, ça n'a rien à voir avec le moteur, mon moteur est totalement indépendant du type de jeux que je veux créer, je peux tout aussi bien créer des jeux en 2D ou 2D iso, en 3D ou en voxel style minecraft, en single ou multi-player, avec mon moteur je sais que je peux le faire même si je n'ai jamais créé un jeu complet avec. Juste des prototypes de jeux. Genre un joueur qui tape sur un ennemi avec synchronisation en réseau local. Ou encore, un clône de pong. Mais c'était y'a longtemps, je n'y ai plus touché depuis l'intégration du backend vulkan et le codage de l'UI. ODFAEG est totatllement indépendant du jeux que je veux créé contrairement à beaucoup de moteur de jeux débutant. Je parle de moteurs utilisant la SFML, sans backend vulkan donc, c'est bien de créé des jeux en 2D pour la switch, les plateforme webs ou je ne sais quel autre platforme. Mais quel intérêt pour le futur et la migration ? Ce que j'ai toujours voulu c'est intégrer un backend vulkan, comme le moteur de rendu castor 3D que je n'ai pas repris parce que y'a pas de doc, donc je ne sais pas comment l'intégrer à mon moteur de jeux, et y'a pas de support pour le raytracing pour ma RTX et je ne sais pas comment l'intégrer à Castor3D. Sinon ça aurait été plus vite d'utiliser Castor3D pour créer un jeu plus rapidement. (Avec le clustered lightning et toutes ses features avancées, même si Castor3D et encore assez lent comme le dit son créateur.)

[dragonjoker59]

Beaucoup de débutant pense que les jeux font la réussite d'un moteur de jeux, mais c'est faux

De quel chapeau tu sors ton "c'est faux" ?

UnrealEngine => moteur écrit à la base pour les jeux Unreal et Unreal Tournament.
IdTech => moteur écrit à la base pour Doom et Quake
CryEngine => moteur écrit à la base pour FarCry
Frostbite => moteur écrit à la base pour Battlefield

Unity et Godot sont les deux seuls moteurs que je connaisse qui n'ont pas été initialement créés pour un jeu.

EDIT:

N'oublie pas le tooling... Tu n'as absolument rien, comme outils pour aider à la création d'un jeu, alors que tous ceux que j'ai cités viennent avec leur panoplie.

EDIT 2:

Et arrête de dire que tu as considéré utiliser Castor3D pour ton jeu, c'est complètement faux, et tu le sais très bien, depuis 15 ans que tu bosses sur ton truc.

[Laurent7601]

Bonjour, le tooling ça vient après, quand le moteur est près, j'ai créé un outil de création de cartes je dois juste l'intégrer à la nouvelle version de mon moteur, j'aurais dû penser il y a 15 ans d'intégrer Castor3D, ça aurait été beaucoup plus vite, faire un moteur de rendu surtout avec vulkan c'est très lourd, mais maintenant que j'y pense seulement c'est trop tard, toute la partie vulkan est codée. Je ne peux plus revenir en arrière et perdre du temps à intégré une autre appli externe pour le rendu, surtout si elle n'est pas documentée, pas assistée par copilot IA pour l'utilisation, et surtout, n'intègre pas toutes les features de rendu que je veux. Je vais pas perdre mon temps à discuter de comment utiliser Castor3D avec son créateur maintenant, déjà le faire avec l'IA, ça m'a prit du temps, de poser toutes les questions à propos du langage c++ et de l'utilisation de vulkan pour ma rtx. J'ai l'impression que vous ne suivez vraiment pas l'évolution de mon moteur, ou ne retenez que les messages récents.

[dragonjoker59]

Mais ... J'ai l'impression que tu crois que je veux que tu utilises Castor3D.
Je ne le veux SURTOUT PAS.

[Laurent7601]

Ah, j'ai toujours pensé le contraire en 15 ans, que tu voulais que j'utilise ton moteur de rendu pour mon moteur de jeux. Mais en fait, c'est le contraire tu ne le veux absolument pas. Bref, apparemment je dois créé un jeux pour que les gens de ce forum voient enfin mon vrai potentiel et celui de mon moteur. Faut que je prévois de faire cela pour 2017 au plus tard. Sinon je crois que je vais simplement rester "membre actif" sur ce forum.

[PANORAMIC]

Cela fait 2 fois aujourd'hui que tu nous parles de 2017. On ne vit pas à la même époque ...

Donc ne t'en fait pas, au pire d'ici 2017 => je peux commencer à créer mon premier jeux

C'était ce matin à 2h17. je me suis dit, il doit être fatigué.

Faut que je prévois de faire cela pour 2017 au plus tard.

Mais là, c'était tout à l'heure à 15h24.

[Laurent7601]

2027 pardon!!! (On est déjà en 2026 purée!!!) Avoir coder ce backend vulkan jour et nuit m'a fatigué énormément mais j'ai enfin fini! Reste plus que les derniers bugs d'affichage à corriger!!! Pour faire simple, je fais qu'une seule queue familly pour tout (la queue graphique), la synchronisation inter queue est vraiment trop *** à faire! Et ça m'a créé dans l'ancienne version des comportements instables. Je vais supprimer d'ailleurs la première version vulkan une fois que j'aurai terminé de transférer tout le code, ne laisser que la version avec le backend opengl seulement pour l'intégrer + tard, parce que déjà, la première version de mon backend vulkan elle est instable (UB GPU), mal codée et trop lente, je n'ai fais que de la *** (je l'avoue) lors du premier passage de opengl vers vulkan, cette version est 1000* mieux. Une fois le module graphique entièrement terminé, je vais pouvoir, intégrer les autres modules de la version précédente (physique, réseau et audio), et enfin, réécrire l'outil (la gui), et crééer mon premier jeux. Au niveau du module graphique je n'ai plus que la passe hi-z à coder et quelque passe post-processing. Mais ça, une fois que tu as un pipeline hybride stable et performant, ça devient tellement plus facile qu'avec l'ancienne version instable. Je ne peux pas développer et présenter un moteur ou un jeux en même temps, ça freine le développement mais il y a une solution pour gérer la présentation/communication sans perdre de temps pour le développement, c'est le streaming! Je vais me fixer une deadline, pour 2027 je veux finir le moteur et faire un premier jeux. Je ne fais pas le portage androïd et web tout de suite, je vais me limiter aux versions PC par contre, je n'ai pas de mac pour tester un support MAC. Seulement windows, et linux. Le pipeline vulkan est le pieline principal, les pipelines légacy ça viendra + tard. Je ne vais pas non plus faire de la physique complexe, ce n'est pas le but, le plus important dans un prmier jeux je pense ce sont le graphisme, le gameplay, la performance et la stabilité bien sûr. Mais apparemment ce qui est surtout important c'est la performance et probablement les jeux créé avec le moteur en effet. Si je fais un petit jeux qui est capable d'afficher beaucoup de polys en 3D de manière stable et performante avec mon pipeline hybride (et je pense migré mon jeux vers cela) se sera déjà très bien! Si j'améliore la gui de l'éditeur de maps, ça donnera plus envie. Donc le FPS est bon, les bugs d'affichages c'est presque réglé. Ce sont surtout ces 2 points que je privilégie en premier. Mais avoir commencé un jeux, sans avoir vraiment fini le moteur, c'est pas une perte de temps à partir du moment ou l'architecture du moteur, te permet de ne pas devoir réécrire le code du dit jeux. Donc oui j'aurais pu, commencé à finir le jeux très tôt, mais je suis vraiment tombé amoureux de vulkan donc.

[Laurent7601]

Salut! Voici une petite vidéo sur la première version du moteur (éditeur de scripts + éditeur de maps et démos 2D/3D) ainsi que les problèmes que j'ai rencontré et le pourquoi de cette refonte du module graphique surtout!

https://dai.ly/x9y5gye

Comme vous pouvez le voir à la fin de la vidéo, j'ai un éditeur de maps/scritps et je peux afficher de la 2D et de la 3D et donc je pouvais déjà créér un jeux en 2D ou un en 3D pas très gourmand avec des cubes, mais avec cette ancienne version :

-J'avais des bugs d'affichage et ui de l'éditeur très moche. (Ca ne me dérangais pas pour développer, mais ça ne donne pas envie d'utiliser le moteur)
-C'est lent! FPS et temps de chargement surtout de la démo 3D. (Ca ne donne pas envie d'utiliser le moteur également)

Donc je n'avais vraiment pas envie de continuer. J'ai même abandonné pendant plusieurs mois ce projet.

Ce que la nouvelle version apporte :

-FPS/frametime beaucoup plus élevé (voir mes dernières captures de rendu) donc oui, j'avance.
-Architecture plus stable, plus maintenable, plus propre, plus de crashs, plus de device lost, plus de memory leaks vulkan. (J'ai fais une refonte totale du backend vulkan!)
-Correction des bugs d'affichage.

Et la dernière chose à venir :

-Amélioration de l'ui de l'éditeur. (Je ne vais plus utiliser mon propre système d'ui pour l'éditeur, juste pour le futur jeux ou je plaquerai des textures, maisje vais utiliser i'mgui pour les uis complexes de l'éditeur et les drags and drop et faire des dockable, j'ai pas vraiment envie de m'amuser à faire de belles ui et coder tout ça.

Quand les 2 versions seront fusionnées et que l'ui sera refaite : la première vraie release du moteur sera vraiment terminée.
J'espère pour 2027 je pourrais créé un jeux complet! Mais je sature, j'ai des moments de souffrance, ma solitude et personnalité autistique qui me rend maladroit dans les relations me fait me sentir mal à l'aise. Je développe juste pour ne pas déprimer, c'est tout.

Pour l'éditeur de script je vais utiliser un éditeur externe et juste faire du hot reload pour placer des breakpoints, débuguer et afficher les informations de debugs, je n'ai pas envie de coder mon propre éditeur ça serait irrationnel, ni mon propre language de script, infaisable en solo. La nouveauté c'est mon système de blueprint inversé, non présente dans les moteurs de jeux existant. (Plutôt que de créer des blueprint auxquel je ne comprend rien et qui génère des scripts, se sont les scripts qui mettent à jour mes blueprints et inspecteurs pour créer, modifier et supprimer des objets. Je peux également attaché des scripts à des noeuds de scène comme dans Unity, c'est ce qui définira les comportements.

[Laurent7601]

Unity : appels de callbacks pour chaque game object, c'est lourd!!! 10000 objects = 10 000 callbacks à appeler ? Je me suis dis => non!!!
Unreal : c++ complexe, macros UProperty. Système de blueprint pour générer la logique => non!!! La logique doit rester dans le code.Unreal a voulu faire un système de blue print et langage de programmation visuel pour artiste qui ne connaissent pas la programmation voulant créé des jeux "débutant". Mais ça ne convient pas pour des jeux compelxes : des boîtes et connexions partout c'est pas maintenable! Un artiste n'est pas senser s'occuper de la logique d'un jeux de toute façon.

Godot : pas idéal non plus, propre langage de scripts, propre edi lent : non, trop lourd! Pas de pipeline RT. Pour moi, ce ne sont pas des moteur c++ et vulkan friendly.

ODFAEG fonctionne comme celà :
un système :

✔ programmeur‑first
✔ data‑driven
✔ C++‑friendly
✔ Vulkan‑friendly
✔ GPU‑Driven
✔ modulaire
✔ extensible
✔ lisible
✔ future‑proof
Avec :

✔ un GameObject Global
→ pas de callbacks partout
→ logique centralisée
→ scalable

✔ un behaviour tree propre
→ pas de flux visuel
→ pas de boucles visuelles
→ pas de if visuels
→ pas de spaghetti

✔ signaux/slots (Qt‑style)
→ conditions → actions
→ simple
→ lisible
→ modulaire
→ parfait pour gameplay complexe

✔ blueprint de données, pas de logique
→ constructeurs
→ setters
→ suppression
→ behaviour tree
→ pas de langage visuel

✔ réflexion automatique
→ UI générée automatiquement
→ blueprint mis à jour automatiquement
→ inspector mis à jour automatiquement
→ zéro duplication

✔ scene node tree
→ hiérarchie claire
→ scripts attachés
→ sélection simple

✔ inspector pour transforms, matériaux, collisions
→ comme Unity/Godot
→ mais plus propre

✔ overlay UI via signaux/slots
→ comme Qt
→ simple
→ robuste

[Laurent7601]

Ah oui et ODFAEG n'est pas une plateforme monolithyque comme Unity ou Unreal ou tu es dépendant de l'UI et du format des assets. ODFAEG c'est un kernel, comme l'os linux mais niveau logiciel. (Et donc de haut niveau) Je n'impose aucune UI, ni écosystème, l'utilisateur du moteur pourrait créé la sienne. Il peut aussi créer ses propres formats pour ses assets. Avec Unity/Unreal ou encore godot tu es dépendant de l'UI et du format des assets. (Chose que je ne voulais absolument pas, j'ai donc dû TOUT recréer)