From: <nik...@al...> - 2002-10-29 18:52:07
|
> - Le plus pratique serait peut-être de séparer la déclaration du plug-in et > le plug-in en lui-même, ce que fait le système de plug-ins de 3ds : pour > chaque plug-in tu as un class descriptor qui décrit le plug-in, le nom, > l'auteur, etc, et avec une fonction qui te renvoie une instance du plug-in. > On pourrait faire pareil, genre le plug-in en lui-même, et une autre classe > qui te renvoie la liste des classes à ajouter au class descriptor par > exemple, la version du plug-in, la version d'orion3d pour laquelle a été > compilé le plug-in, etc... ce genre de trucs. Et puis ca risque d'être plus > pratique à modifier si on fait des changements dans le design. je sais pas si c'est ce que tu voulais dire, mais ça me semble plus propre de le faire en vrai orienté objet. genre le plugin doit implémenter une classe qui dérive de OR_Plugin_ABC et qui permet de faire tout ce que tu viens de dire. Comme cette classe est serializable, elle renvoie automatiquement un nom du plugin et peut instancier un plugin en renvoyant un pointeur valide. Le seul truc que je me demandais c'est comment l'utilisateur doit enregistrer le plugin auprès d'o3d. Peut être le mieux c'est de faire (en prenant l'exemple du plugin de surface maths) : // crée un pteur et l'ajoute au gestionaire de plugin d'o3d. // a priori, cette fonction est implémentée une fois pour toute par la classe de base // OR_Plugin_ABC, qui checke avant si le plugin n'est pas déjà register, et si ce n'est // pas le cas, demande à la classe de déclarer toutes les sous-classes du plugin auprès // de la classe factory, et crée un plugin (un pointeur) en utilisant la fonction "Clone" // de serialization. OR_MathSurface_Plugin* pPlugin = OR_MathSurface_Plugin::RegisterPlugin(); plutôt que le truc horrible avec le constructeur de copie que j'avais proposé. Sinon, pdt que j'y pense : je croie qu'on ne va autoriser qu'un type de plugin loadé à la fois, comme ça on met les plugins dans une map nom=>pointeur (un manager, quoi :). > - Comme on reparle de sérialisation, je profite de ce changement assez > radcial du design pour en proposer un au niveau de la sérialisation. Le but > est de pouvoir "gérer" les différentes "versions" et autre incompatibilités, > ce qui est le gros défaut du système actuel. Ca implique un certain nombre > de choses à rajouter mais je pense qu'après ça on a un truc en béton et qui > nous fera plus chier : > * Les serialisables, lorsqu'ils exportent leur données, écrivent en premier > les données de type primitif puis les données de type serialisable ok, c plus ou moins ce qui est fait pour l'instant. > * Chaque serialisable doit pouvoir renvoyer > . La taille des données primitive qu'il écrit (une somme de sizeof quoi) > . Le nombre de serialisable qu'il écrit > . Un numéro de version ok, mais ça risque de prendre de la place pour un serializable qui n'a que peu de chose à mettre dans le fichier. mais bon, ok. > * A l'écriture, on écrit dans le fichier, en plus du nom du serialisables, > ces 3 données supplémentaires ok ok > * A la lecture, on passe en plus à la fonction Serializable::BuildFromFile > le numéro de version inscrit dans le fichier. S'il ne sait pas lire les a priori, c'est le serializable lui même qui lit dans le fichier le numéro de version. pourquoi lui passer alors que c'est lui même qui l'a écrit dans le fichier. C'est plus logique, pour un design de serialization de faire les choses en symétriques : celui qui écrit un truc dans le fichier au moment du BuildTo le récupère et l'analyse dans la fonction BuildFrom > données correspondant à cette version, il renvoie une erreur, et à ce moment > là on saute les données primitives et les "sous-serialisables", et on peut hum, comment faire pour savoir la taille des "sous-serializable" ? Je suppose que tu utilises une fonction "GetMemorySize()" qui calcule de façon récursive la taille d'un sérializable. Ca me semble une très bonne idée, en plus, c'est super utile de pouvoir savoir la taille que prend telle classe, ne serait-ce que pour information. donc je suis ok. > passer au serialisable suivant sans chier une grosse erreur dès qu'on est > tombé sur un petit machin qui déconne. ok, c 100% une bonne idée, que j'implémente avant de faire le design des plugin. Je pense qu'on est d'acodac pour dire que ça, c le design ultime qui tue, et qu'après, on va pouvoir commencer à coder sur de bonne base. >On peut gérer l'erreur par exemple en > créant un objet de base à la place de l'objet mal lu (ou, soyons fou et > imagnions que nous sommes dans une appli réseau, en envoyant un message au > serveur demandant de renvoyer juste l'objet mal lu, ou je ne sais quoi > encore :) ). Tout dépend bien sûr du niveau ou se passe l'erreur. Dans le cadre du hierarchy tree, on cree un gizmo de base (genre un point), voir mieux, on crée un objet "OR_ErrorGizmo" synonyme qu'il y a une une couille, avec toutes les références de la couille stockées dans le gizmo (conflit de version, le nom du programmeur fautif, le numéro de tel. du support d'orion3d, la date, mon signe astrologique ...). > Enfin bref y'a probablement moins bourrin, mais je pense que ca peut être > utile de se pencher sur le problème. moins bourrin, je pense pas, disons que c'est pas économe en terme de place sur disque, mais est-ce important ? Dans la pratique, c'est les vertex des mesh qui prennent de la place, pas qq info en +. Votre avis ? > > D'autres choses, qui ont plus ou moins qq chose à voir : > > - Le pattern Animatable est fait et marche plutôt super bien, je suis > vachement content, mais ca a changé un certain nombre de trucs, notemment au > niveau des "Update()" dont tu parles justement. En effet, avant, les player > reliant les nodes aux animations étaient stockés dans les nodes, et > c'étaient les nodes qui, à chaque update, demandaient aux player de mettre à > jour l'animation. Maintenant, les players sont des classes indépendantes des > animatables, et il existe un AnimationToolkit qui te permet de les gérer > simplement, en reprenant le principe des queues, plus quelques petits trucs > pratiques. Donc au final ce qui se passe : le tookit demande à > l'animationtoolkit d'updater les animations, ce qui va mettre à jour chaque > animatable, puis il appelle update sur la hiérarchie, qui maintenant ne se > contente plus que de mettre à jour la matrice absolue. > Donc peut-être que le plus simple serait simplement de faire un > UpdateBeforeAnim et UpdateAfterAnim pour les plug-ins ? > (au fait la famille animatable contient à l'heure actuelle entre autres les > Nodes, les Objects, les Mesh, les Shaders, et les AnimationBlend :D ) ok ok, je me pencherais sur le code source, enfin, le mieux est qu'on se fasse une réunion après tes exams, moi, j'aurais bouclé les plugins de base. ailleurs, je te propose de coder les portal et bsp sous forme de plugin, c'est typiquement des trucs dont l'utilisateur de base n'a pas forcément besoin, et qui vienne en sur couche. A la limite, il faudrait un design type pour les "plugin de visualisation", style clipping, etc, qui viendrait se plugguer à des endroit spécifique du pipeline de calcul d'o3d. sinon, ça veut dire que tu penses que c'est une bonne idée de juste faire des fonctions d'update, draw, etc (avec plusieurs type d'update) ? quelles sont à ton avis les endroit ou de tels branchements sont nécessaires ? par exemple : - avant Draw() du hierachy tree - après Draw() du hierachy tree - avant Update des matrices d'anim - après Update des matrices d'anim - après Update des matrices de position. > > - L'animation blending aussi marche vachement bien, je sais pas si je vous > en ai fait beaucoup part sur la ml :) yes, c de la bombe :) > > - Le bsp renderer marche aussi nickel et se prête sans problème au design > de plug-in :) je t'ai devancé :) > > - J'attends d'avoir enfin terminé l'animation_test avec des modèles décent > pour mettre tout ça sur le CVS (je l'espère cette semaine) ok, j'espère qu'il n'y aura pas de pbm de commit, faudra etre vigilant. sinon, tu penses que c'est jouable de maintenir une version pour Visual6 ? > > - Je vais en profiter pour y rajouter le wintext_test tant que j'y suis, vu > qu'il s'ennuie tout seul dans son coin et qu'il faudra bien que Sanx le voie > un jour :) oui, il faut que tu fasses un putain de sample pour montrer ce qu'on peut faire avec. sinon, je pensais mettre tous les #include de lib extern sous la forme : #include <lua/lua.h> plutot que #include "../../lua/lua.h" parceque pour l'instant, c super pas pratique, par exemple si je veux utiliser orion3d, il faut obligatoirement que le répertoire de lua soit au bon endroit dans le path. Comme ça, qd qq'un veut compiler o3d, il ajoute le path de là ou il a checkouté le CVS dans les paths d'include de visual. ciao gabriel > > - Je sais pas si vous avez remarqué mais j'ai remis le reply-to sur la ml : > si vous répondez à un post envoyé à la ml, vous répondez à la ml et pas à > l'envoyeur. Tout le monde trouve ça plus pratique mais faites juste gaffe si > vous voulez répondre à une seule personne :) > > Voilà, à part ca, http://www.gala-esiee.com/ ;) > > A+, > Antoche > > -----Message d'origine----- > De : ori...@li... > [mailto:ori...@li...]De la part de Gabriel > Peyré > Envoyé : mardi 29 octobre 2002 11:38 > À : ori...@li... > Objet : [Orion3d-dev] orion3d_plugins.txt > > > Voici des propositions dans le but de cleaner un peu orion3d. > Le but est d'en faire un moteur légé, avec un mécanisme de plugins pour > pouvoir l'enrichir simplement. > > Dites-moi ce que vous en pensez. > > Gabriel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Orion3d-dev mailing list > Ori...@li... > https://lists.sourceforge.net/lists/listinfo/orion3d-dev |