From: Antoche <an...@al...> - 2001-06-20 20:53:52
|
>ça me semble vraiment bourin comme algo, pour deux raison : >- deja, c'est pas suffisant de prendre "les deux premiers bones". pour que l'effet de >simplification soit pas trop visible, il faut prendre les bones avec les plus grand >poids, puis rescaler les poids pour que la somme fasse 1. J'ai dis que cet algo était valable que pour 2 bones max, et donc que ca foirerait pour + de 2. Que l'on prenne ceux de plus grand poids ou non, le résultat sera faux de toutes façon (d'où l'algo plus "général", mais qui risque de pas marcher avec l'extension si l'implémentation ne supporte pas). De plus la somme n'a pas besoin d'être 1 (cf la description de l'extension). >- ensuite, il se peux que les vertex d'une meme face ne soient pas attaché au même >bones. Là oui c chiant. Mais si une face a un vertex qui dépend des bones A et B, et un autre qui dépend des bones B et C (ce que tu décris), et bien on sera forcément obligé d'utiliser 3 matrices en même temps, quelle que soit la méthode (on peut pas changer la matrice pendant un dessin de primitive). Celle que j'ai proposée optimise simplement dans le fait que ca diminue le nombre de chargement de matrices (et encore ca dépend comment c implémenté), mais sinon c la même chose que de gérer des paires (ou nuplets) de bones associés à des liste de vertex. Peut-être qu'il y a une solution plus optimisée que celle-là (j'en vois pas sur le coup), mais ca n'empêche qu'il va falloir aussi implémenter le vertex blending à la main, d'abord parce que il n'est géré qu'à partir d'opengl 1.2 et donc ca ne marchera pas partout, et ensuite si on veux gérer les cas particuliers comme celui-ci ou si on veut avoir plus de matrices. >- enfin, il faudra faire gaffe au fait qu'un vertex dupliqué (à cause des normales ou >des coordonnees de texture) ait les meme bones et poids. Ca c déjà géré (cf mail du 19/06 15:51) >bon, j'ai pas trop le tmps d'y réfléchir, mais j'y penserais ce soir dans le train ! bon voyage >a+ > >gabriel Antoche >Messsage du 20/06/2001 11:32 >De : <ori...@li...> >A : <ori...@li...> >Copie à : >Objet : RE: re : [Orion3d-dev] nouvelles du front > > j'ai pensé à un algo tout con mais qui marche sans pb en théorie, partant du > principe que chaque node a au plus un père : > 1) pour chaque bone, tu choppes d'abord tous les vertex qui n'utilisent que > ce bone (weight=1) > 2) ensuite, tu prends tous les vertex qui ont un poids sur ce bone et un > poids sur le père du bones > 3) et enfin, comme c'est des faces, tu prend les vertex qui appartiennent > aux faces utilisant les vertex du (2) (sinon le père aura des faces avec des > verts dépendant de ce bone) > Voilà, idem pour les faces, et ainsi pour chaque bone tu as les vertex liés > à ce bone et(ou) à son père, donc 2 poids à chaque fois ! > Bon évidemment si les vertex ont plus de 2 bones ben ca prendra que les 2 > premiers. > Idée : pour nBones>2, prendre que les vertex n'utilisant aucun autre bone > que le bone actuel, le père et le grand-père, avec le même algo. Au rendu, > gérer une sorte de "pile" de bones, où la modelview0 est le bone, la > modelview1 est le père, la modelview2 est le grand-père, etc... Je pense que > ca marche. > > Antoche > -----Message d'origine----- > De : ori...@li... > [mailto:ori...@li...]De la part de Gabriel > Peyré > Envoyé : mercredi 20 juin 2001 10:16 > À : ori...@li... > Objet : RE: re : [Orion3d-dev] nouvelles du front > > > coooool, tu as devancé mes intentions ... > de toute façon, je vais imprimer la doc > > gab, qui du coup va s'ennuyer dans son train > > > > >Messsage du 20/06/2001 01:38 > >De : <ori...@li...> > >A : <ori...@li...> > >Copie à : > >Objet : RE: re : [Orion3d-dev] nouvelles du front > > > > Je viens de checker l'opengl extension registery, et c comme ca que ca > > fonctionne en effet, mis à part que le nombre de bones (ie de matrices) > maxi > > est fixé par l'implémentation (C le nombre de vertex units de la carte 3D, > > ca doit être qq chose comme 2 sur les cartes actuelles). Et le poids est > > définit par glWeight{}ARB(), appelable entre glBegin/glEnd, et aussi > > spécifiable sous forme de vertex array. > > > > Antoche > > > > >je pense que le hardware ne travaille que sur 2 matrices, et comme en > > >général on n'en utilise pas plus, c pas forcément nécessaire. De plus, il > > >faut essayer de voir comment tout ca va se goupiller. J'ai pas regardé > > >comment l'extension fonctionnait, mais même en "software" (en faisant le > > >blending à la main), il faut changer la matrice à chaque vertex. Or on ne > > >peut pas faire ca pendant le dessin des primitives (entre un > > glBegin/glEnd), > > >donc je suppose que l'extension fourni une nouvelle fonction glVertex (et > > >toutes les autres fonction dans le genre) avec un param weight > > >supplémentaire pour interpoler entre les deux matrices que tu lui as > > >fournies. Donc si ca se passe comme ca on peut pas dessiner tout le mesh > > >d'un coup (à moins qu'il n'ait que 2 bones), et donc il faudra splitter > le > > >mesh en parties contenant chacune les vertex utilisant une même paire de > > >bones. En gros, reproduire la hiérarche du squelette sur le mesh... Tu > vois > > >ce que je veux dire ? > > > > Antoche > > > > > > _______________________________________________ > > Orion3d-dev mailing list > > Ori...@li... > > http://lists.sourceforge.net/lists/listinfo/orion3d-dev > > > > > > _______________________________________________ > > Orion3d-dev mailing list > > Ori...@li... > > http://lists.sourceforge.net/lists/listinfo/orion3d-dev > > > > > _______________________________________________ > Orion3d-dev mailing list > Ori...@li... > http://lists.sourceforge.net/lists/listinfo/orion3d-dev > > > _______________________________________________ > Orion3d-dev mailing list > Ori...@li... > http://lists.sourceforge.net/lists/listinfo/orion3d-dev > _______________________________________________ Orion3d-dev mailing list Ori...@li... http://lists.sourceforge.net/lists/listinfo/orion3d-dev |