Discussion :

[funkydata]

Bonjour,

j'ai pas mal réfléchi au futur du projet et j'aimerais que vous me donniez votre avis sur deux-trois points de réflexion avant de fixer définitivement les futurs orientations du moteur.

Le premier de ces points concerne le multiplateforme.
Une première question "globale" : Pensez-vous que cela soit important ?

En effet, un support conjoint de DirectX et OpenGL apportera à n'en pas douter son lot de limitations et une légère mais réelle perte de performances du fait d'une couche d'abstraction suplémentaire sur toute la partie graphique.

Seconde question sur ce point, s'adressant plus au Linuxiens :
Quelles sont les performances de Mono ? Ses limitations... ?

Il est en effet envisageable que dans un futur proche un support d'OpenGL soit réalisé. Mais si Mono ne permet pas, une exécution relativement rapide, ou qu'il s'avère être trop limité, l'intérêt en deviendra trés faible.

Second point, les plugins. J'ai réalisé avec succés quelques tests sur les plugins permettant d'envisager un large panel d'ajouts de fonctionalités au moteur sous forme de DLL.
Est-ce que cette fonctionalité vous intéresse ?
Comptez vous développez des plugins si elle est présente ou préférez vous utiliser par "confort" les plugins existants ?

Dernier point enfin, concernant le nxEdit. Je cherche 1 ou 2 collaborateurs sur cet outil afin d'alléger le travail de chacun et de permettre une mise à disposition de l'outil plus rapidement que si j'étais seul à le développer.
Ce/Ces collaborateur(s) devront avoir une bonne connaissance de C# et des notions sur la programmation 3D temps réel.
Le but étant à terme de développer un frontend complet pour le nxEngine.

Je rappelle que je recherche toujours un infographiste titulaire pour le projet. Son travail servira notamment pour les démos techniques, les présentations (screenshots, vidéos...) et plus si motivé...

Voilà

[lakitrid]

Je retraite par point :
- Multiplateforme :
Pour la partie Moteur graphique il est vrai que ca peut être intéressant qu'il soit multiplateforme. Mais si le prix a payer est trop lourd ...
Il ne faut pas oublier que la linux bien que pouvant faire tourner des jeu est assez peu utiliser par le commun des mortels. Et les gamers de base.
Pour mono, le site dis clairement ce qui est supporté ! Et apparement des logiciel 3d ont été fait avec.

- plugins :
Je ne suis pas assez accés moteur 3d pour te répondre

- nxEdit : même réponse qu'au dessus (et faut que je boss sur l'éditeur de niveau déjà )

[bafman]

Le premier de ces points concerne le multiplateforme.
Une première question "globale" : Pensez-vous que cela soit important ?

En effet, un support conjoint de DirectX et OpenGL apportera à n'en pas douter son lot de limitations et une légère mais réelle perte de performances du fait d'une couche d'abstraction suplémentaire sur toute la partie graphique.

je ne parlerait que de ce point pour dire que ce serait (de mon point de vue) un erreure de chercher à faire du multi plateforme au niveau des API.
en effet, en plus d'obliger à une couche d'abstraction suplementaire, il y a aussi un problème de designe du moteur. On ne designe pas un moteur 3D de la même façon en OpenGL et en D3D, il y a forcement un moment ou on doit favoriser une API ou une autre, et la, on se retrouve dans une situation ou on a introduit une couche d'abstraction qui ralentit le code pour supporter une API, mais de façon non optimal.
pour resumer, on ralentit l'API du designe original pour utiliser une autre API qui sera intrinsequement plus lente (et ceci est vrai quelque soit l'API d'origine )
Il suffit de voir comment ca fonctionne pour Ogre : le moteur a été prevu à la base pour D3D, il supporte OpenGL, mais il est étrangement lent en OpenGL
bref, le multi api pour un moteur 3D, c'est le mal , et si l'objectif etait de faire du multi plateforme au niveau OS, il aurait fallut commencer par faire de l'OpenGL

[Laurent Gomila]

Pensez-vous que cela soit important ?

Pareil que bafman. J'ajoute aussi que je n'ai aucune idée de la proportion de gens qui utilisent Mono et des moteurs 3D sous Linux, mais ça ne doit pas casser trois pattes à un canard.
Et puis tant qu'à utiliser un truc qui émule .NET, pourquoi ne pas utiliser un truc qui émule aussi DirectX ?

Est-ce que cette fonctionalité vous intéresse ?
Comptez vous développez des plugins si elle est présente ou préférez vous utiliser par "confort" les plugins existants ?

Je pense que la gestion des plugins est extrêmement importante, surtout si tu souhaites que les utilisateurs puissant contribuer à l'évolution du moteur. Pour Ogre je ne sais pas s'il y en a tant que ça (j'en ai vu 3 ou 4 assez "connus"), mais regarde par exemple Code::Blocks : pratiquement toutes ses fonctionnalités sont maintenant des plugins.
Et puis même si personne n'en fais, rien que pour toi au niveau flexibilité c'est plutôt sympathique.

[lougne]

Le premier de ces points concerne le multiplateforme.
Une première question "globale" : Pensez-vous que cela soit important ?

Toi funky tu veux attirer la colére des dieux dans ce forum
Bon pour moi, non pour le moment. Cela ne ferait que ralentir l'avancement du moteur et je ne pense pas qu'il soit assez mature pour ce permettre des dérives. Ma philosophie: finir l'objectif premier ensuite rajouter des choses sur demande.

Seconde question sur ce point, s'adressant plus au Linuxiens :
Quelles sont les performances de Mono ? Ses limitations... ?

j'en sais rien mais il y a ce projet UNITY qui prête à croire que les perfs sont bonnes. Il ny a qu'à aller dans la section unity 2.0

Second point, les plugins. J'ai réalisé avec succés quelques tests sur les plugins permettant d'envisager un large panel d'ajouts de fonctionalités au moteur sous forme de DLL.
Est-ce que cette fonctionalité vous intéresse ?
Comptez vous développez des plugins si elle est présente ou préférez vous utiliser par "confort" les plugins existants ?

Touche pas à ça!! C'est le truc le plus intérréssant aprés le rendu de ton moteur, cherche à l'améliorer plutôt pour permettre un réalisation aisée des plugins par les autres programmeurs. C'est cette partie qui va augmenter l'intérêt du moteur.

Dernier point enfin, concernant le nxEdit. Je cherche 1 ou 2 collaborateurs sur cet outil afin d'alléger le travail de chacun et de permettre une mise à disposition de l'outil plus rapidement que si j'étais seul à le développer.
Ce/Ces collaborateur(s) devront avoir une bonne connaissance de C# et des notions sur la programmation 3D temps réel.
Le but étant à terme de développer un frontend complet pour le nxEngine.

Connaissance en C# je pense ne pas être trop loin de la demande, mais 3D temps réel je m'y atelle, cela ne fais que 1 ans et des poussiéres que je touches à MDX. Mais j'ai cassé la tirelire pour m'acheter une bonne dizaine de bouquin genre collection ShaderX, une série de bouquin sur agile design et le design patterns, Level of Detail for 3D Graphics, 3D Math Primer for Graphics and Game Development, sans compter les premiers bouquins de mon apprentissage, bref je fais tout pour y arriver Sans compter les gamedev et autres comme gamasutra qui sont des sauveurs.

[MoDDiB]

-Multiplateforme :
si le jeu en vaut la chandelle un linuxien n'aura aucun problème à émuler DirectX ou tout simplement booter sur windows...

-Concernant les plugs-in : avant de créer un plug in je regarderais forcément si un existant ne fais pas déjà ce que je souhaite et dans ce cas je pourrais éventuellement faire un plug-in dans la mesure où il s'agirait de quelque chose d'intéressant pour la communauté et non que pour mon propre usage.
Maintenant je ne pense pas que ca soit prioritaire puisque le moteur se veut open source, l'on pourra imaginer greffer directement les manques aux moteurs : comme le souligne Loulou même en permettant les plugs-in Ogre n'en dispose pas de beaucoup et c'est d'ailleurs génant en tant qu'utilisateur que le Paging Landscape Scene Manager soit un plug in et non intégré directement au moteur...(Ok on gagne au chargement 10 millisecondes lorsqu'on ne l'utilise pas .. et encore)

-Concernant l'éditeur je bosse pour le moment sur un jeu qui me prends tout mon temps et pour lequel je réalise déjà un éditeur donc pour le moment je ne pourrais pas spécialement t'aider.

[DiOxy]

Salut !

Multiplateforme ? Hé bien...

Ogre3D, Irrlicht, OpenSceneGraph et j'en passe sont multi-plateforme.
La plupart offrent la possibilité de choisir entre OpenGl et Directx.

S'il n'y a pas d'émulations a proprement parler de DirectX sur linux c'est parce que DirectX est "Propriétaire" alors que OpenGl est "Libre". Mais l'intérêt récent de Microsoft pour Linux me laisse penser que l'on pourrais voir arriver un DirectX 10 pour linux dans les années qui viennent.

Perso, j'utilise Windows par obligation (Mon job), et je m'efforce de m'en servir un maximum, mais je ne vous cache pas que je préfère (et de loin) GNU/Linux.

Mon avis est le suivant : Essaye de trouver un moyen de proposer le choix DES LE DEPART, en préparant le terrain. Essayer d'ajouter l'OpenGl après coup consistera en fait a ajouter une rustine et ça fonctionnera mal.

Concernant mono, on obtient des performances tout a fait bonnes et je n'ai aucun problème de compilation avec irrlicht .Net CP (Un Wrapper d'irrlicht)

A ce sujet, justement, essaye de contacter Emmanuel Bossière ( http://irrlichtnetcp.sourceforge.net....php/Main_Page )

Au passage, ce dernier est plutôt bon sur les shaders aussi !

[lougne]

Salut !

Au passage, ce dernier est plutôt bon sur les shaders aussi !

Cela m'intéresse

[funkydata]

Merci pour vos avis...

Tout d'abord sur la question de la portabilité, voilà qu'elle était mon opinion avant de lancer ce débat :

Linux est un bon système mais combien de personne utilisent Linux ? Pas beaucoup.
Combien de personnes sur ce faible pourcentage utilisent Linux pour faire de la programmation 3D ? Vraiment mais alors vraiment pas beaucoup
Combien de personnes jouent sous Linux ? Vraiment mais alors vraiment, vraiment pas beaucoup.

La majorité des personnes que je connais et qui utilisent Linux s'en servent à des fins tout autre que la programmation 3D temps réelle. Quelques personnes (sur les forums majoritairement) prône la portabilité. Bien que je sois plutôt d'accord avec ça pour de l'applicatif pur, pour le domaine qui nous concerne, je suis nettement moins convaincu de cette nécessité. En effet comme dit dans vos posts celle ci entraine, en plus d'une perte substancielle de performance, plus de problèmes qu'elle n'en résout.

Pour les Plugins, il seront donc supportés dans la v0.4. Reste à définir quels seront leurs types. Par exemple :

* Scenegraph
* Son
* Physique
* Shaders
* Inputs

Si vous voyez autre chose je prends

Enfin pour l'éditeur vu le peu de ressources dont je dispose, je vais attendre la v0.4 afin d'avancer son développement.

[Yno]

Combien de personnes sur ce faible pourcentage utilisent Linux pour faire de la programmation 3D ? Vraiment mais alors vraiment pas beaucoup

Moi !

Je suis personnellement pour un portage Linux. Je serais curieux de tester ce moteur. Mais si cela entrainerait d'après vous trop de pertes de performance, alors tant pis. Mais pourquoi ne pas prévoir "deux versions" du moteur ? Le choix de l'API graphique se ferait statiquement, mais les performances ne seraient pas touchées.

Enfin, ce n'est qu'une idée, tu es libre de faire comme tu l'entends le mieux

[funkydata]

Moi !

Je suis personnellement pour un portage Linux. Je serais curieux de tester ce moteur. Mais si cela entrainerait d'après vous trop de pertes de performance, alors tant pis. Mais pourquoi ne pas prévoir "deux versions" du moteur ? Le choix de l'API graphique se ferait statiquement, mais les performances ne seraient pas touchées.

Enfin, ce n'est qu'une idée, tu es libre de faire comme tu l'entends le mieux

Comme le dit trés bien bafman, un moteur 3D ne peut pas être trés performant en supportant conjointement OpenGL et DirectX. Il cite notamment le cas de Ogre qui est orienté DirectX et donc qui présente une exécution sous OpenGL bien moins performante. On peut faire la même remarque pour tous les moteurs 3D commerciaux ou libres supportant conjointement DirectX et OpenGL.
Certains seront plus performants sous une API au profit de l'autre.
De plus comme je l'ai dit l'abstraction de l'API graphique ajoute une couche de virtualisation supplémentaire dans ce que l'on pourra appeler le "bas niveau" dans ce cas. Qui dit abstraction dit pertes de performances c'est certain... et vérifiable trés facilement même sans faire de la 3D

Quand à ton idée de 2 versions du moteur cela me semble complétement irréalisable car je n'aurais jamais le temps (ni la patience d'ailleurs) de faire deux versions distinctes. D'autant plus qu'un moteur 3D en DirectX ne se structure pas de la même façon qu'un moteur 3D OpenGL...

Bref, un portage Linux n'est, en l'état actuel des choses pas envisagé pour les raisons citées plus haut. De plus, j'ai fait une stat rapide : sur 124 questions, demandes et/ou requetes de fonctionalités, seulement 3 d'entre- elles se rapportaient à la demande d'un portage Linux (4 avec toi).
Soit 3.22%, ce qui est selon moi bien trop peu pour me lancer dans une telle entreprise.

[clemsye]

La majorité des personnes que je connais et qui utilisent Linux s'en servent à des fins tout autre que la programmation 3D temps réelle. Quelques personnes (sur les forums majoritairement) prône la portabilité. Bien que je sois plutôt d'accord avec ça pour de l'applicatif pur, pour le domaine qui nous concerne, je suis nettement moins convaincu de cette nécessité. En effet comme dit dans vos posts celle ci entraine, en plus d'une perte substancielle de performance, plus de problèmes qu'elle n'en résout.

Heu, j'utilise Axiom sous linux,donc si j'ai un conseil, porte le moteur sous linux...

[Janitrix]

Heu, j'utilise Axiom sous linux,donc si j'ai un conseil, porte le moteur sous linux...

Comme il l'a dit, cela représente une perte de performances non négligeable ou un boulot monstre. Vu la qualité de son travail et le temps qu'il a passé pour en arriver là, je ne pense pas qu'on soit en mesure de lui en demander plus.
Et pour le problème de portabilité, ce n'est de tout façon pas sur lui qu'il faut taper mais sur les plus haut placés. Croyez moi, il en souffre autant que vous, alors soyez plus respectueux, merci.

En tout cas, merci de ton boulot funkydata, c'est très bien, bonne continuation .

[DiOxy]

Bah, tu posais la question et j'ai répondu en mon âme et conscience. De toutes façon c'est déjà bien avancé donc ce serait trop dur d'ajouter OpenGl.

Concernant Ogre, il n'est pas a la base orienté Directx, en fait. Perso je compile les sources sous linux et j'obtiens de bien meilleures performances en OpenGl qu'avec directx windows. Mais là c'est un démarrage de troll et j'en ai pas envie

Donc, continue sur ta lancée.
Tu as toute ma considération pour ton superbe travail.

[funkydata]

Je pense en effet que chacun à ses goûts et ses préférences et à le droit de les exprimer... cela me semble normal et c'est même necessaire.

Je ne relancerais pas le débat Linux/Windows et OpenGL/DirectX car je pense que c'est une discussion sans interêt dans la mesure ou justement, dans notre cas, cela représente plus une histoire de goût et/ou d'habitude qu'autre chose.

Chacunes de ses technos à ses avantages et ses inconvénients, ses points forts et ses points faibles.
Pour ma part je préfère Windows car je déteste me prendre la tête avec mon OS et surtout, que je suis sûrement, par habitude, bien plus à l'aise et plus productif sous Windows. Je préfère DirectX également par habitude et pour quelques autres raisons que je ne citerais pas ici afin d'éviter justement le type de débats : OpenGL c'est mieux !! Non c'est DirectX, Non c'est OpenGL... etc... etc

Maintenant il est certain que si la moitié des personnes interressées par le projet m'avaient demandé un portage Linux/OpenGL, j'y aurais réfléchi sérieusement (d'ailleurs ce post était aussi là pour ça ). En l'occurence, la demande est bien trop faible par rapport à la somme de travail et de sacrifices que cela demanderait.

Donc pour les pro-linuxiens, je suis vraiment navré de ne pouvoir satisfaire votre demande, mais je pense que comprendrez ma position, comme je peux comprendre que vous préfériez Linux à Windows.

[DiOxy]

Bah, je ne suis pas vraiment pro-linux, je dit juste que même si linux est au début, après une période d'adaptation plus ou moins il devient .

En fait, pour l'instant linux souffre surtout d'un manque de maturité au niveau marketing. Mais là n'est pas l'objet du débat.

Ton boulot est superbe et j'ai rarement vu un projet aussi bien mené.
Tu est parti pour créer plus qu'un moteur 3D. Tu es en train de concevoir un moteur de jeux. Je suis vraiment curieux de voir jusqu'où tu ira.

Funkydata !

[funkydata]

Salut à tous.

Voici les quelques décisions prises durant la période de réflexion intensive que sont les vacances :

Le nxEngine n'utilisera plus MDX mais une DLL en C++ qui sera chargée de faire le lien entre DirectX et le moteur.
En effet depuis l'avènement de XNA, MDX n'est plus développé par Microsoft et à terme il faudra de toutes façons passer par là pour le support de DX10... alors autant s'y mettre maintenant
Je suis en train d'étudier comment utiliser de façon transparente DX9 ou DX10 sans recoder vos applications utilisant le nxEngine. Je vous tiendrais au courant sur ce point.
Le développement de la partie DX10 de cette DLL se fera au coup par coup. En effet, je ne possède pas de GPU supportant DX10 à temps plein, mais on me prêtera le nécessaire de temps à autre, ce qui me permettra d'avancer la dessus.

La version 0.4 sera nettement moins managée au niveau des shaders afin de gagner en performances. Le moteur intégrera donc quelques shaders précompilés mais il faudra de toutes façons écrire les votres. Je pensais, à un moment, pour les non initiés aux shaders faire un système de script permettant de simplifier au maximum leur écriture mais cela prends trop de temps pour un résultat pas toujours trés convainquant.
Je prévoie donc l'écriture que quelques tutos afin de vous former sur les shaders car à ma connaissance, à part Lougne, aucun des béta testeurs ne connait cette technologie.

Et là je m'adresse à Laurent : developpez.com a-t-il besoin de tutos sur le sujet ?

Dernière chose enfin, j'ai updaté mon SDK avec la version de août donc, les béta testeurs, vous pouvez faire la MAJ également.
(DirectLink sur mon blog)

[Laurent Gomila]

Bien sûr qu'on a besoin de tutoriels, c'est effectivement une bonne idée de te proposer, ça permettra de faire un document qui ne s'adressera pas qu'aux utilisateurs du nxEngine

Contacte moi par MP si tu veux en discuter.

[MoDDiB]

Le nxEngine n'utilisera plus MDX mais une DLL en C++ qui sera chargée de faire le lien entre DirectX et le moteur.

Je trouve ca bien entendu décevant, comme un retour en arrière, une sorte de bataille perdue : "non on ne peut pas faire un moteur 3D en full C#".

Mais soit, j'aimerai savoir en terme de performance quel sera le gain espéré par ce changement ?

[funkydata]

Je trouve ca bien entendu décevant, comme un retour en arrière, une sorte de bataille perdue : "non on ne peut pas faire un moteur 3D en full C#".

Mais soit, j'aimerai savoir en terme de performance quel sera le gain espéré par ce changement ?

Ben déjà certaines parties de MDX ne sont pas codées en C# il me semble. Ensuite je pense que tu seras d'accord avec moi sur le fait que le moteur ne peut plus se baser sur cette technologie dans la mesure ou elle est abandonnée par Microsoft.

Ensuite je me suis reposé la question de l'utilisation de XNA, mais cette lib est vraiment beaucoup trop managée pour moi, et elle impose pas mal de restrictions donc certaines m'agacent enormèment.

Puis, je me suis dis : pourquoi pas faire un Wrapper en C# directement ? Ben franchement, vu la galère que c'est rien qu'avec le moteur physique, je me dis que si tout le moteur est basé sur des Wrappers le débuggage va durer quelques années
Bref d'aprés mon expérience moins tu as de wrappers liant des Dlls COM à ton appli C# mieux tu te portes

Je suis donc arrivé à la conclusion suivante : faire une passerelle assez bas niveau mais pas trop en C++ CLR afin de pouvoir bosser tranquille sur les DLLs DirectX en COM tout en ayant un support objet (appréciable) sur cette même DLL depuis le moteur C#... et pas en direct sur un Wrapper comme je dois le faire pour le moteur physique.

C'est le choix que j'ai fait non pas parceque le C# pouvais pas le faire mais parceque je trouve que c'est le plus propre, le plus pratique et certainement le plus fiable.

Pour terminer, je n'ai pas fait ce choix pour une question de performances même si il est vrai que l'on pourra peut-être gagner un petit quelque chose (mais franchement je doute que ce soit flagrant).

Ceci dit merci de ta remarque pertinente... et tu n'as pas tord de dire que c'est un retour en arrière suivant comment on voit les choses. Il est certain que je ne suis pas enchanté de me replonger dans le C++ (j'avais oublié sa syntaxe si agréable et intuitive ) mais Microsoft pour le coup ne nous laisse pas trop le choix

Trés honnêtement, je ne fais, peut-être, pas le bon choix. Avez-vous une opinion, des suggestions ou des questions sur le sujet ?