Discussion :

[Mikmacer]

Salut à tous!

J'aimerais vous présenter le projet sur lequel je travaille depuis plusieurs mois déjà : La création du EscapeNgine, un moteur de jeux 3D sous XNA. La programmation avec ce moteur permettra la création de jeux sur Xbox 360, PC et éventuellement Zune HD. D'ici quelques mois, le moteur va sortir Open Source(Licence pas encore décidée) et gratuit.

Pour l'instant, voici les features du moteur:

Rendu Graphique

• Programmation du pipeline de rendu à l'aide d'un langage en XML
• Gestion des Materials en xml( un fichier XML par matériel, permet de définir un shader, les textures, et les contextes de rendu relatif au pipeline
• Gestion des lumière de type : Point Light, Directional Light, et Spot Light
• Gestion du rendu des lumières de type Foward Lighting, et Light Pre-pass(Wolfgang Engel)
• Plusieurs effets (Parallax mapping, HDR, DoF, SSAO, God rays, etc..)
• Rendu spécial pour déboguer
• Moteur de particules, facilement extensible
• Ombrage à l'aide de shadow maps

Gestion des ressources :

• Chargement des scène complètes de type Collada
• Possibilité de Charger/Enregistrer les scène et mesh 3D au format binaire propre au moteur
• Les formats de textures PNG, JPG, TGA, DDS(DXT1, DXT3, DXT5)

Gestion des animations :

• "Skeletal Animation" à partir des fichiers collada.
• Animation Blending, entre chacun des frames, et entre les animations
• Hardware (En software éventuellement....)

Détection de collision :

• Partitionnement BSP(Pour les triangles)
• Partitionnement Octree, et Quadtree pour les objets dynamiques
• 4 types de volumes de collision : Sphere, AABB, OBB, BSPVolume(Pour la détection par triangle)
• Détection segment-triangle segment-volume optimisé par les partitionnements

Gestion Des scènes

• Implémentation d'un "Scene Graph", noeud avec transformation hiéarchique

Interface :

• Image
• Bouton
• Texte
• Autre...
• Intégration du moteur à Winforms

Le moteur est extrêmement modulaire, et chacun des modules est indépendant, ce qui permet de FACILEMENT extendre le moteur en ajoutant, par exemple, son propre moteur de rendu, son propre moteur Physique, son propre gestionnaire de scène, etc.. Le création de jeu se fait en C#, et le SDK XNA sera requis. Avec ce moteur, je vais essayer d'atteindre autant les débutants en programmation 3D, avec des fonctions fixés facile d'utilisation, et les plus avancés qui pourront exploiter les fonctions avancés du moteur pour pouvoir implémenter n'importe quels effets avec le système de pipeline. Je ne veux pas limiter le moteur à la programmation de jeux, mais aussi à la visualisation 3D sous Winforms.

Je n'ai présentement pas de site web, ni de bloque sur le moteur. Pour l'instant, je situe mes efforts sur la finalisation de la première version du projet, mais je compte travailler sur un site web avec de la documentation, et tutoriels éventuellement. Je suis présentement en phase "Implémenter les dernières petites features", optimisation et refactoring, mais le gros est déjà fait!

Finalement, je crois que le point fort du moteur, sera la possibilité de rapidement développer un produits 3D sur Xbox 360, PC et Zune HD en même temps. Le projet est développé seulement par moi-même pour le moment et je compte en faire le plus gros moteur basé sur XNA. Et voilà, je me demande si le projet semble intéressant? J'attends commentaire et suggestions!

Je vous laisse sur quelques images de l'ancêtre du moteur, et quelques travaux que j'ai effectué :






Sans/Avec SSAO:

[bafman]

projet intéressant, par contre, ton SSAO me semble pourri
On voit que les faces des cubes sont ombré alors que ça ne devrait pas être le cas...

Par contre, est ce que tu compte en faire uniquement un moteur 3D, on alors un moteur de jeu plus complet (avec le son, le réseau et autres) ?

[Mikmacer]

Pour le SSAO, tu as raison, j'y ai été un peu vite, et j'ai posté une vieille version de ce que j'ai fait il y a pas mal de temps. Il comportait un peu de self-occlusion, voici une image plus récente du shader que j'ai développé en GLSL (Il ne me reste plus qu'à le traduire en HLSL ) :
http://img49.imageshack.us/img49/4896/ssaoni7.png
(http://horde3d.org/forums/viewtopic.php?f=4&t=618 , pour plus de détails)

Pour le moteur, je compte rester indépendant à chacune des plateformes, alors pour le réseau je ne suis pas encore certain. Pour le son, il y a XACT fourni avec XNA, c'est un moteur de son déjà assez complet, et je me demande si je devrais en faire une surcouche. Pour le moment, je compte me concentrer sur la partie 3D.

[yodaime]

Salut !

Alors moi je dit chapeau ! Déjà pour développer un moteur 3D il faut du courage, pour arriver a le finir il faut de la persévérance.

Par contre un conseil, ne lance pas ton moteur sans rien. Je t'avoue qu'il m'a donné très envie de l'essayer mais il me donnera encore plus envie si tu le fournit avec des tutos et encore plus si il y a des exemples de fonctionnalités.

En tout cas bravo et bonne finalisation !

[Mikmacer]

Alors moi je dit chapeau ! Déjà pour développer un moteur 3D il faut du courage, pour arriver a le finir il faut de la persévérance.

En effet, le moteur a a environ 200H-300H de travail que j'ai effectué dans mes temps libres depuis un an!

Par contre un conseil, ne lance pas ton moteur sans rien. Je t'avoue qu'il m'a donné très envie de l'essayer mais il me donnera encore plus envie si tu le fournit avec des tutos et encore plus si il y a des exemples de fonctionnalités.

Content qu'il y a déjà un intéressé! Et je suis d'accord, la documentation est presque plus importante pour un système que ses fonctionnalités, puisque ce n'est jamais très encourageant d'utiliser un système mal documenté. Je compte faire une série de tutoriels faciles à suivre.

[QUOTE=yodaime;4648115]En tout cas bravo et bonne finalisation ![/QUOTE
Merci!

J'aimerais ajouter que je compte faire évoluer énormément le projet après sa sortie, et y ajouter des modules intéressants comme la gestion de terrain grande envergure, un moteur de simulation physique(J'ai déjà commencé la base avec le moteur de détection de collision qui sera fourni avec le EscapeNgine), système d'illumination global en temps réel, plusieurs effets de shaders, un éditeur sous winforms(Déjà commencé), etc...

[yodaime]

un moteur de simulation physique(J'ai déjà commencé la base avec le moteur de détection de collision qui sera fourni avec le EscapeNgine)

Pourquoi ne pas prévoir un système pour faciliter l'intégration d'un moteur physique déjà existant ?

A moins que tu veuille juste rester dans des cas de collisions "basique", je ne vois pas trop l'intérêt d'un tel module. Il existe déjà de très bon moteur physique et pouvoir les intégré facilement avec ton moteur 3D pourrait être une bonne idée.

[Mikmacer]

Pourquoi ne pas prévoir un système pour faciliter l'intégration d'un moteur physique déjà existant ?

A moins que tu veuille juste rester dans des cas de collisions "basique", je ne vois pas trop l'intérêt d'un tel module. Il existe déjà de très bon moteur physique et pouvoir les intégré facilement avec ton moteur 3D pourrait être une bonne idée.

Salut!

Si mon propre moteur de détection de collision est déjà intégré au moteur 3D, ça ne veut pas dire qu'il n'est pas possible d'avoir un autre moteur qui gère les collisions. Et justement, je n'oblige pas à utiliser le moteur de détection de collision qui va venir avec le moteur, il sera tout à fait possible d'intégrer, assez facilement, n'importe quel moteur physique existant sous .NET au EscapeNgine. Pour le moment, il n'y a qu'un moteur intéressant pour la phyisque 3D compatible Xbox 360, et probablement Zune, alors que les port .NET des gros moteur tel que ODE, ou Bullet ne le sont pas. Je vais peut-être implémenter ce moteur en tant que plug-in, mais j'ai le projet d'éventuellement créer mon propre moteur physique, défi personnel.

[yodaime]

Si mon propre moteur de détection de collision est déjà intégré au moteur 3D, ça ne veut pas dire qu'il n'est pas possible d'avoir un autre moteur qui gère les collisions. Et justement, je n'oblige pas à utiliser le moteur de détection de collision qui va venir avec le moteur, il sera tout à fait possible d'intégrer, assez facilement, n'importe quel moteur physique existant sous .NET au EscapeNgine.

Tant mieux ! Ton moteur 3D n'en sera que plus intéressant.

Pour le moment, il n'y a qu'un moteur intéressant pour la phyisque 3D compatible Xbox 360

Lequel est ce ?

j'ai le projet d'éventuellement créer mon propre moteur physique, défi personnel.

Et ben ! Toi au moins tu a pas froid aux yeux ! Après le moteur 3D le moteur physique. T'es pas un peu maso ?

[Bakura]

Joli projet, le rendu est assez impressionnant. Par curiosité, tu utilises quelle technique pour le subsurface scattering ?

[Mikmacer]

@yodaime:
Le moteur s'appel JigLibX

@Bakura:
La technique est assez simple, je fais un rendu de la profondeur des back face et ensuite des front face. Je calcule la différence entre la profondeur de tout les pixel, dans un pixel shader, normalisé entre 0 et 1, et avec ce nombre je vais chercher la couleur du texel dans une texture. Ensuite je calcule la lumière spéculaire. J'ai lu cette technique dans un vieux paper de NVidia, je ne sais plus trop si je l'ai encore.

[Mikmacer]

Salut!

Je viens donner des nouvelles de mon projet. En fait, j'aurais aimé sortir le projet plus tôt, sauf que je ne peux pas m'empêcher d'ajouter pleins de features.

Premièrement, je viens de modifier le moteur de rendu pour le rendre hybride "Forward Lighting" et "Light Pre Pass" pour le rendu de la lumière. Ce qui permet un nombre incroyable de rendu de lumière tout en permettant de facilement gérer la transparence!

Voici une image de mon test pour le renderer, la scène compte un rendu de 25 lumières dynamiques, et ça roule à 25-70 FPS(Relatif au nombres de pixels shadé par la lumière) sur mon portable en 1280X720 :


Le pipeline de rendu sera très flexible, puisqu'il est contenu dans un fichier XML scriptable. Donc on peut extendre le pipeline à profusion, et ajouter tout les types d'effets qu'on veut (HDR, SSAO, Depth of field, etc.). Aussi, tout en étant très puissant, le pipeline de rendu de base sera compatible avec une relativement vaste game de hardware. Le Shader Model 2.0 sera requit.

Sinon, j'ai refactorisé le moteur pour le rendre multithread. Pour l'instant, seulement la détection de collision est sur un thread différent. Le tout va rester transparent pour l'utilisateur. Je compte éventuellement mettre la logique du jeu dans un thread différent, et ne garder que le calcul du rendu sur le main thread.

De plus j'ai refactorisé le système d'animation par bones. On peut maintenant bloquer un des bones afin de leurs donner une transformation différente de l'animation, utile pour, par exemple, implémenter un système ou la tête d'un personnage regarde à un endroit voulu, et ce, sans avoir à créer l'animation. Aussi, on peut séparer les hiérarchies de bones afin de pouvoir jouer plusieurs animations sur un mesh skinné en même temps, et gérer le blending d'animation entre chacune des hiérarchie. C'est très utile pour, par exemple, faire jouer une animation de salut sur le haut du corps d'un personnage, alors qu'il marche, ça évite de créer inutilement trop d'animations.

Bon, à la vitesse que ça avance, je compte sortir une version Alpha du moteur dans environ deux mois. À ce moment, le support pour les formats binaire des ressources ne sera pas disponible, ce qui viendra éventuellement. Avant la sortie, il me reste 7 trucs à faire:

- Finaliser le système de GUI
- Refactoriser le système gérant la logique du jeu pour le rendre dans un thread différent.
-Créer une documentation globale du moteur
- Refactoriser l'ensemble du moteur
- Créer quelques exemples d'utilisations
- Créer le site du projet
- Implémenter une extension threadé pour la physique, basé sur JigLibX

[Kromagg]

Bonjour Mikmacer

Quelle librairie xml utilises-tu ? De mon côté j'utilise libxml++ mais c'est plein de dépendences (glib, libxml, glibmm...) et c'est assez embêtant car du coup j'ai plein de dll à fournir avec mon exe. Bon le bon côté c'est une super librairie, pleine de fonctionnalités, très facile à utiliser et relativement performante

Kromagg

[Bakura]

Kromagg > Regarde du côté de RapidXML . Aucune dépendance, très simple à utiliser et très performante .

[yodaime]

Quelle librairie xml utilises-tu ?

C'est un moteur XNA. XNA gère le XML nativement. Je pense qu'il a juste créé un ContentTypeReader adapter pour son propre format de fichier XML.

Mikmacer, corrige moi si je me trompe.

[Mikmacer]

@Yodaime:
En fait, ce n'est pas XNA qui gère le XML, mais le framework .NET. Au fait, je n'utilise pas le système de Content Pipeline de XNA à cause de certaines limitations, surtout au niveau des performances.

[Kromagg]

Petite parenthèse qui ne concerne pas le projet

Kromagg > Regarde du côté de RapidXML . Aucune dépendance, très simple à utiliser et très performante .

J'ai regardé du côté de RapidXml, c'est une bonne lib très sympa à utiliser. J'ai une question : pourquoi n'y a-t-il pas de .lib et de .dll fourni avec la librairie ?
Comment le compilateur peut dans ce cas connaître le code qu'il y a derrière ?

Kromagg

[yodaime]

@Yodaime:
je n'utilise pas le système de Content Pipeline de XNA

Tu utilises quoi à la place ?

[Bakura]

J'ai regardé du côté de RapidXml, c'est une bonne lib très sympa à utiliser. J'ai une question : pourquoi n'y a-t-il pas de .lib et de .dll fourni avec la librairie ?
Comment le compilateur peut dans ce cas connaître le code qu'il y a derrière ?

Si je me souviens bien, le code source est fourni, et intégré directement dans le .hpp. Il se suffit donc à lui même .

[Mikmacer]

Tu utilises quoi à la place ?

J'utilise mes propres loader pour charger les ressources.

[deadalnix]

Joli !

Tu pourrait nous en dire un peu plus sur ton « pipeline xml » ? Ça m'a l'air d'être un des gros points forts du moteur.