Merci pour ton commentaire. Je vais essayer de répondre à plusieurs de tes remarques.
Concernant les limitations dont tu fais part au sujet de la 3D, on est un peu dans la situation du serpent qui se mord la queue : jusqu'à la version 2.1, la plupart des utilisateurs intéressés par la 3D (ça doit représenter 10-15% des utilisateurs, mais ça augmente) se plaignent de la faible qualité du renderer 3D de Godot, donc peu de monde l'utilise. Et comme peu de monde l'utilise, nous avons très peu de retours de bugs, donc peu de modifications, donc peu d'utilisateurs (mais c'est en train de changer).
Pire, au sein même de l'équipe de développement (dans laquelle j'inclus les documenters dont je fais partie, et aussi le Bugsquad), très peu utilisent la partie 3D du moteur. On se retrouve donc dans la situation que tu décris, avec des utilisateurs expérimentés qui remontent des bugs, mais derrière bien peu de monde qui en comprend la subtilité. Et surtout, pas assez de développeurs suffisamment expérimentés pour attaquer des features orientées 3D, ce qui explique le retard sur le bug du normal mapping dans l'éditeur.
En ce qui concerne l'exportateur Better Collada, c'est une création de Juan 'reduz' Linietsky qui a depuis longtemps souhaité l'inclure dans Blender pour remplacer l'exportateur Collada actuel qui ne fonctionne pas, ce qui lui a été refusé et je n'ai pas très bien capté la raison (a priori, le core-dev de Blender est réticent, mais c'est un peu politique) : tu peux lire la discussion sur le sujet ici https://developer.blender.org/D1787 .
Pour répondre au besoin de performance, d'autres solutions existent et doivent être envisagées par l'utilisateur :
- soit développer un module en C++ pour effectuer la partie posant problème afin d'améliorer les performances ;
- soit utiliser l'extension PLScript, qui permettra d'accéder facilement à des librairies externes en GDScript ;
- soit éventuellement passer à C#, mais on ne connaît pas encore les performances pour ce langage ;
- soit, si les performances sont VRAIMENT un problème globalisé, envisager de développer le jeu directement en C++ en se servant de l'API Godot (l'éditeur Godot est développé de cette manière).
Des benchmarks ont déjà été effectués par le passé, mais tout le monde sera d'accord pour dire qu'ils sont largement insuffisants. Il existe aussi une probabilité importante pour que les projets ayant des soucis de performances soient tout simplement mal pensés (avec tout le respect, ça ne s'applique pas à tout le monde, mais on a déjà vu des utilisateurs qui veulent instancier 2000+ meshes sans aucune optimisation ou LOD).
Quelques remarques par-ci par-là :
- Le forum n'est pas officiel. Il est géré par la communauté, mais absolument pas maintenu par l'équipe de développement. Le Q&A, lui, est officiel.
- L'aspect "changeant" que tu relates est un effet causé par le développement de Godot 3.0. Il a été rappelé plusieurs fois que dès le moment où le développement de la branche 3.0 commençait, alors il faut s'attendre à une instabilité très importante. De plus, il est assumé que les versions 2.x et 3.x seront partiellement incompatibles, ceci à cause de nombreux bugs qui n'ont pas été résolus avant 3.0, justement pour ne pas casser la compatibilité dans la branche 2.x.
- Par contre je ne vois pas bien où le cadre d'utilisation de Godot est changeant. Chaque utilisateur en fait ce qu'il veut, que ça soit 2D ou 3D.
[^] # Re: Woot
Posté par StraToN . En réponse à la dépêche Rencontre avec les développeurs du moteur de jeu libre Godot Engine @ Mozilla Space Paris. Évalué à 3. Dernière modification le 03 avril 2017 à 16:27.
Merci pour ton commentaire. Je vais essayer de répondre à plusieurs de tes remarques.
Concernant les limitations dont tu fais part au sujet de la 3D, on est un peu dans la situation du serpent qui se mord la queue : jusqu'à la version 2.1, la plupart des utilisateurs intéressés par la 3D (ça doit représenter 10-15% des utilisateurs, mais ça augmente) se plaignent de la faible qualité du renderer 3D de Godot, donc peu de monde l'utilise. Et comme peu de monde l'utilise, nous avons très peu de retours de bugs, donc peu de modifications, donc peu d'utilisateurs (mais c'est en train de changer).
Pire, au sein même de l'équipe de développement (dans laquelle j'inclus les documenters dont je fais partie, et aussi le Bugsquad), très peu utilisent la partie 3D du moteur. On se retrouve donc dans la situation que tu décris, avec des utilisateurs expérimentés qui remontent des bugs, mais derrière bien peu de monde qui en comprend la subtilité. Et surtout, pas assez de développeurs suffisamment expérimentés pour attaquer des features orientées 3D, ce qui explique le retard sur le bug du normal mapping dans l'éditeur.
En ce qui concerne l'exportateur Better Collada, c'est une création de Juan 'reduz' Linietsky qui a depuis longtemps souhaité l'inclure dans Blender pour remplacer l'exportateur Collada actuel qui ne fonctionne pas, ce qui lui a été refusé et je n'ai pas très bien capté la raison (a priori, le core-dev de Blender est réticent, mais c'est un peu politique) : tu peux lire la discussion sur le sujet ici https://developer.blender.org/D1787 .
Au sujet des performances, et notamment de GDScript, c'est un sujet récurrent. GDScript est le choix qui a été fait pour répondre au plus grand nombre de cas d'utilisation (http://docs.godotengine.org/en/stable/reference/faq.html#i-don-t-believe-you-what-are-the-technical-reasons-for-the-item-above). Beaucoup aiment, beaucoup détestent (c'est d'ailleurs une des raisons pour laquelle C# est incorporé), mais il suffit largement dans les cas classiques.
Pour répondre au besoin de performance, d'autres solutions existent et doivent être envisagées par l'utilisateur :
- soit développer un module en C++ pour effectuer la partie posant problème afin d'améliorer les performances ;
- soit utiliser l'extension PLScript, qui permettra d'accéder facilement à des librairies externes en GDScript ;
- soit éventuellement passer à C#, mais on ne connaît pas encore les performances pour ce langage ;
- soit, si les performances sont VRAIMENT un problème globalisé, envisager de développer le jeu directement en C++ en se servant de l'API Godot (l'éditeur Godot est développé de cette manière).
Des benchmarks ont déjà été effectués par le passé, mais tout le monde sera d'accord pour dire qu'ils sont largement insuffisants. Il existe aussi une probabilité importante pour que les projets ayant des soucis de performances soient tout simplement mal pensés (avec tout le respect, ça ne s'applique pas à tout le monde, mais on a déjà vu des utilisateurs qui veulent instancier 2000+ meshes sans aucune optimisation ou LOD).
Quelques remarques par-ci par-là :
- Le forum n'est pas officiel. Il est géré par la communauté, mais absolument pas maintenu par l'équipe de développement. Le Q&A, lui, est officiel.
- L'aspect "changeant" que tu relates est un effet causé par le développement de Godot 3.0. Il a été rappelé plusieurs fois que dès le moment où le développement de la branche 3.0 commençait, alors il faut s'attendre à une instabilité très importante. De plus, il est assumé que les versions 2.x et 3.x seront partiellement incompatibles, ceci à cause de nombreux bugs qui n'ont pas été résolus avant 3.0, justement pour ne pas casser la compatibilité dans la branche 2.x.
- Par contre je ne vois pas bien où le cadre d'utilisation de Godot est changeant. Chaque utilisateur en fait ce qu'il veut, que ça soit 2D ou 3D.