Après la fusion de ce PR https://github.com/mrdoob/three.js/pull/6052, je suggère d'essayer l'exportateur de la branche dev. Il a 2 options de position de pose différentes pour POSE et REST . Définissez votre armature sur l'un ou l'autre, puis pendant l'exportation, assurez-vous que la propriété Skeletal animation correspond. Essayez les deux et voyez si l'un ou l'autre aide. Pour certaines personnes, POSE fonctionne, et d'autres c'est REST .

hmm donc exporté en utilisant le repos d'animation squelettique et en mode pose ...

ce sont mes fichiers http://we.tl/CNM5qEmBMs
y compris la finale originale et les deux exportations ...

Mode repos = pas de mouvement du tout
Mode pose = distorsions étranges

Vous avez dit: "Il a 2 options de position de pose différentes pour POSE et REST. Réglez votre armature sur l'une ou l'autre" ... Je ne sais pas comment configurer mon amature pour qu'elle pose ou se repose ... je veux utiliser le mélangeur uniquement comme un traducteur de mixamo à threejs ... désolé si ma question est à noob

vouliez-vous dire les modes d'édition pose et mode d'édition pour les objets?

Ok Pose mode --- mêmes distorsions
Modifier en mode le journal des erreurs suivant:

Je ne peux pas recréer cette erreur mais j'ai remarqué qu'en regardant les numéros de ligne dans le retraçage, vous n'êtes peut-être pas sur la même (dernière) version trouvée dans dev . Assurez-vous également de ne pas effectuer une exportation Scene avec cet élément. Pour le moment, faites simplement des exportations de géométrie unique (car ObjectLoader ne fonctionne pas encore avec les maillages skinned).

En ce qui concerne les animations cassées; Je peux recréer à la fois l'animation cassée et le problème d'animation manquant. Il y a des gens qui obtiennent un exportateur d'animations fonctionnel (exemple https://github.com/mrdoob/three.js/issues/5582#issuecomment-73444737), donc je soupçonne qu'il y a des problèmes avec le processus d'importation FBX. Il est très difficile de déterminer s'il s'agit de l'exportateur ou de l'importation FBX. Je me suis demandé s'il y avait des transformations à appliquer aux os, mais je ne sais pas encore.

Hé mec, merci beaucoup pour votre temps et votre perspicacité!

vous n'êtes peut-être pas sur la même (dernière) version trouvée dans dev.

Je pense que je travaille avec la dernière version car je peux sélectionner la pose et le repos:
"L'option d'animation est maintenant une énumération qui oblige un utilisateur à choisir entre POSE et REST"

car ObjectLoader ne fonctionne pas encore avec les maillages skinned

D'après mon expérience, ce n'est pas plus fou ... j'ai chargé des géométries et des scènes avec objectloader dans threejs. L'erreur suivante est créée avec Objectloader et donne le même résultat que les exportations Geometrie précédentes.

Je peux recréer à la fois l'animation cassée et le problème d'animation manquant.

Ce serait vraiment intéressant si vous n'êtes PAS capable de recréer le problème ...
Par conséquent, voyez-vous une possibilité d'exporter le modèle vers threejs ...

Son intéressant en général car c'est un modèle exporté par mixamo. Si ce modèle fonctionne - chaque modèle mixamo fonctionnerait. (en théorie ;))

de toute façon merci pour y regarder.

Avec la version actuelle de Blender et uniquement des géométries et aucune exportation de scène, je suis en mode pose:

et en mode repos

je ne peux exporter la géométrie que si j'exporte la scène de perçage

ok je pense que je l'ai trouvé ... c'est un bug dans la référence entre les sommets de la géométrie et les os animés ... le maillage et le squelette sont désactivés

Après avoir manuellement mis à l'échelle et fait pivoter le maillage vers le squelette comme ceci

for (var i = 0; i < geometry.children[0].geometry.vertices.length; i++) {
                vector = geometry.children[0].geometry.vertices[i];
                var axis = new THREE.Vector3(0, 1, 0);
                var angle = Math.PI / 2;
                geometry.children[0].geometry.vertices[i].applyAxisAngle(axis, angle);
                geometry.children[0].geometry.vertices[i].multiplyScalar(0.01);
 }

j'ai obtenu un résultat assez correct.

Alors tout d'abord - pourquoi ai-je besoin de faire pivoter le maillage ... je me souviens lors de l'importation dans mixamo que je devais faire pivoter mon modèle exactement de 90 degrés ... c'est à cause de la direction -z
Pourquoi évoluer? aucune idée...

vient maintenant le buggy que mon modèle n'avait pas le TPos parfait ... les bras étaient trop bas ... je l'ai gréé dans mixamo et c'était toujours parfait après ... je l'ai vu dans blender ... et c'était parfait pour ... vu au max était parfait aussi.
ALORS l'exportation vers Threejs et le mappage entre les os et le corps se référaient au corps créé à l'origine dans max.

il y a donc un bug mathématique dans le référencement des sommets et des os dans leur matrice de transformation.

Je me demande si c'est en fait un bug ou plutôt une fonctionnalité optionnelle. Cela pourrait très bien résoudre le problème que vous rencontrez, mais interrompre les exportations pour quelqu'un d'autre qui n'a pas à importer d'actifs FBX (ce que j'ai déjà vu avec les animations POSE et REST). La logique utilisée (pour les os et les sommets) est en place depuis un certain temps (copiée de l'ancien exportateur) et je ne dis pas qu'elle est parfaite ou sans défauts, mais si c'était un bogue dans les mathématiques, je pense que nous l'aurions vu plus de problèmes. Vous devez appliquer votre exemple de code dans l'exportateur, puis exécuter de nombreux tests sur de nombreux cas de test (ce qui n'est pas quelque chose que je traîne).

J'ai vu des problèmes similaires dans la production où un actif effectue plusieurs voyages à travers plusieurs programmes et exportateurs. Ajoutez à cet axe d'équation des réorientations et vous avez une recette de manigances certifiables. Si je peux comprendre comment mettre cela en œuvre dans l'exportateur, ce ne sera une option que jusqu'à ce qu'il y ait beaucoup plus de certitude que cela s'applique effectivement à tous les utilisateurs et non aux cas secondaires.

Avec la version actuelle de Blender et uniquement des géométries et aucune exportation de scène, je suis en mode pose:

L'erreur dit spécifiquement "Pas un objet de maillage valide". Les exportations de géométrie sont basées sur la sélection et vous avez très probablement sélectionné l'armature et non le maillage.

hey mec encore merci d'avoir regardé dedans.
je ne voulais pas dire que mon code devrait entrer dans l'exportateur. Ce que je voulais souligner, c'est que dans la chaîne de max à mixamo en passant par blender - tout est attribué comme il se doit. une fois qu'il arrive à threeJs - il y a un simple décalage de transformation qui se produit (dans mon cas, c'était la pourriture et l'échelle) qui causent l'erreur .. cette transformation fait référence au maillage d'origine qui a été créé une fois (où jamais) et est ignoré dans blender et mixamo ... mais relancé lors de l'exportation.

Malheureusement, je dois admettre que je ne suis pas un magicien de la matrice - sinon, j'aimerais beaucoup vous aider car vous travaillez très dur. Nous vous remercions de votre point de vue.

Je n'ai jamais utilisé de mixamo. Utilise-t-il Y-up? Ce que je me demande, c'est que si maximo est Y-up, alors l'importation FBX devrait réorienter l'actif vers Z-up, puis l'exportateur se réoriente à nouveau pour Y-up jusqu'à three . Je me demande si les transformations de l'actif devraient être appliquées dans Blender lors de l'importation si cela s'exporterait ensuite correctement vers three .

Traduire les plates-formes d'une plate-forme / format à un autre devient moche après plus de quelques itérations. Même dans certains des pipelines et des outils les plus avancés avec lesquels j'ai jamais travaillé, il y avait toujours des limites à ce qu'un actif truqué pouvait être soumis. Il existe peut-être une solution qui fonctionne pour vous et pour tout le monde, mais ce n'est certainement pas immédiatement clair de quoi il s'agit.

je ne voulais pas dire que mon code devrait entrer dans l'exportateur.

Et je faisais plus généralement référence à quelque chose qui tenterait d'appliquer des angles d'axe aux positions des sommets.

vector = geometry.children[0].geometry.vertices[i];
var axis = new THREE.Vector3(0, 1, 0);
var angle = Math.PI / 2;
geometry.children[0].geometry.vertices[i].applyAxisAngle(axis, angle); <-- would need something like this as well

mais je saisis aussi un peu, et peut-être que cela essaie de faire en sorte que l'exportateur gère trop de variables

Commentaire intéressant ici concernant FBX
https://github.com/mrdoob/three.js/issues/2803#issuecomment -11458920

Avez-vous appliqué la rotation que vous avez probablement faite à votre modèle et l'armature à l'intérieur du fichier du mélangeur? Vous savez, avec ctrl + A> Rotation et échelle, en mode objet. J'ai vu des choses très similaires se produire parce que je ne le fais pas. @princemio

Mon maillage sort constamment déformé ou j'obtiens des erreurs et je ne peux pas exporter plusieurs animations. Revenir à l'exportateur r69 qui semble bien fonctionner même dans Blender 2.73a

@ s'il vous plaît-attendez ... non en fait je ne l'ai pas fait ... mais peut-être du mixamo au blender ...
@kimasendorf avez-vous essayé de recréer manuellement le maillage en threejs?

Le maillage a été modélisé dans Blender. Même s'il s'agit d'un caractère low poly, il est certainement trop complexe de recréer manuellement le maillage en trois js. Et comment cela pourrait-il aider?

dans mon cas, le maillage et les os n'étaient pas alignés les uns avec les autres ... d'où le modèle se plie en essayant de s'adapter aux os ... si vous n'avez pas d'os, cela n'a rien à voir avec cela ...

btw ... je ne veux pas dire "recréer" lol ... je suis désolé j'ai essayé d'écrire "réaligner" le modèle ...

J'ai eu des problèmes similaires avec chaque squelette plus complexe que j'ai essayé jusqu'à présent. Y compris le marine inclus dans le repo three.js et présenté dans les exemples. Voici ce que j'obtiens avec cela en utilisant le commutateur de pose:

Marine en pose:
https://antont.github.io/three.js/examples/webgl_animation_skinning.html

Cette exportation est en:
https://github.com/antont/three.js/blob/blenderexport_buggy_marineskinning/examples/models/skinned/marine/marine_anims-pose.json

L'exemple minimal des tests d'exportateur fonctionne. L'assistant squelette correspond au modèle lors de l'utilisation du mode pose là-bas.

Je vais essayer (certaines de) ces astuces de cet autre problème déjà fermé (# 4660) ensuite:

1. Vous aurez besoin d'images clés sur chaque os que vous souhaitez exporter.
2. Le maillage doit être dans la pose en T. Voici deux façons de procéder: a. Avoir une action T-pose. Cette action a besoin d'un cadre où tous les os ont des transformations effacées. Il doit s'agir du cadre actuel lorsque l'exportateur est sélectionné. b. Supprimez le modificateur Armature du maillage juste avant l'exportation. Une fois le fichier exporté, annulez la dernière action pour récupérer le modificateur.

et:

Je n'ai pu le faire fonctionner que lorsque j'ai conservé le modificateur Armature, mais désactivé les groupes de sommets et les enveloppes osseuses (puis réactivé après l'exportation). Dans mon cas, la suppression du modificateur n'a pas aidé.

peut-être aussi:

Avez-vous appliqué la rotation que vous avez probablement faite à votre modèle et l'armature à l'intérieur du fichier du mélangeur? Vous savez, avec ctrl + A> Rotation et échelle, en mode objet.

Si quelqu'un me bat pour obtenir une exportation fonctionnelle à partir de cet exemple de mélange et me dit ce qui était nécessaire ... merci beaucoup! :) J'utilise ce mélange: https://github.com/mrdoob/three.js/blob/master/examples/models/skinned/marine/marine_anims.blend

Ok, ça fonctionne maintenant, mis à jour https://antont.github.io/three.js/examples/webgl_animation_skinning.html (si quelqu'un a vu la version boguée plus tôt, assurez-vous de ne pas l'obtenir du cache maintenant)

J'ai essayé beaucoup de choses d'avant en arrière, vérifié que tous les os étaient clavetés, les options de repos et de pose, etc., mais à la fin, il semble que c'était juste que quand j'avais apply modifiers sur la déformation étrange. Cela a du sens car le modificateur d'armature a été appliqué au geom de base lors de l'exportation, puis déformé par le skel anim dans three.js.

Il y a donc une exportation fonctionnelle du mélange marin non modifié avec le nouvel exportateur à: https://github.com/antont/three.js/blob/example_skinning/examples/models/skinned/marine/marine_anims.json

Je pense qu'il n'a qu'une seule des animations, il faut ensuite savoir comment exporter toutes les animations avec la nouvelle exportation.

Capture d'écran des options utilisées:

@antont merci pour cette recherche!

le cerf de realxtend / chesapeake bay fonctionne aussi :)

mêmes options.

démo: https://antont.github.io/three.js/examples/webgl_animation_skinning-deer.html
exportation: https://github.com/antont/three.js/tree/example_skinning_deer/examples/models/skinned/deer
source: https://github.com/realXtend/chesapeakebay/blob/master/objects/White_Tailed_Deer/White_Tail_Deer_all.blend

J'ai configuré un canal d'équipe Slack pour three.js, principalement pour travailler sur des problèmes d'animation, mais il peut être utilisé pour tout ce qui est lié à trois. Il s'agit d'un canal d'équipe privé, les utilisateurs ne peuvent donc le rejoindre que sur invitation. Je cherche:

• les gens qui connaissent Python
• des personnes ayant une solide compréhension du rigging dans Blender
• personnes ayant des expériences d'animation _et_ scènes disposées à partager

Ce n'est pas une chose élitiste. Je suis limité dans le temps et je n'ai pas de bande passante pour enseigner à quelqu'un Python ou Blender, donc je m'excuse si cela ne semble pas convivial pour les débutants (c'est à cela que sert IRC). C'est pour ceux qui veulent vraiment étouffer cela dans le cul et qui ont des compétences utiles à contribuer. IRC m'ennuie et même les threads github ne sont pas mon endroit préféré pour la collaboration. J'utilise Slack avec d'autres groupes et ça a été génial.

Envoyez-moi un e-mail (et notez également votre pseudo github) pour une invitation
ed [point] caspersen [at] gmail [point] com

Je pense qu'un changement dans les dernières API de Blender a cassé la méthode utilisée par l'exportateur pour sélectionner l'action sur le maillage.

Le comportement que je vois (pas complètement confirmé) est que l'exportateur exporte:

1. L'action qui est sélectionnée sur l'armature qui est le parent du maillage sélectionné ...
2. Tentative d'exporter les autres animations non sélectionnées, et échec lors de la tentative de définition de l'animation sur l'armature, afin de parcourir les images clés des actions. Le résultat est que l'animation de l'étape 1 est exportée à plusieurs reprises sous les différents noms d'action ... La durée semble cependant correcte parmi les différentes actions.

Je pense qu'un changement récent dans Blender nécessite maintenant que l'armature soit l'objet sélectionné dans la vue 3D pour que le changement d'action prenne réellement effet.

Cela pourrait être résolu en modifiant l'exportateur pour exiger que l'armature soit sélectionnée pour l'exportation, au lieu du maillage, et le changement d'action effectué dans le script peut fonctionner.

Faites-moi savoir si vous voulez plus d'aide avec l'exportateur de blender. J'ai une bonne expérience dans le script pour la version antérieure à 2.6 ..

Autre problème, je devais avoir la bonne combinaison de "repos" sélectionnée à la fois dans les paramètres du script et sur l'armature. Cela semble fragile.

Un autre problème est le "Appliquer les modificateurs" ...
D'après ce que je peux dire, dans les circonstances normales d'exportation d'un maillage skinné, cela ne devrait jamais être le cas, et devrait être désactivé par défaut ou avoir une bascule séparée pour exclure les maillages skinned.
En appliquant des modificateurs, l'armature transforme le maillage en n'importe quelle image sur laquelle il est actuellement défini.
Cela flexible la liaison pour le maillage et démontre les problèmes montrés ailleurs dans ce fil.

Ce serait bien de trouver un moyen de rationaliser ces étapes.

J'ai juste fait quelques tests et confirmé que l'exportateur exportait les images de la même animation pour chaque animation exportée ...

Donc depuis que j'ai exporté mon maillage avec l'action "marcher" sélectionnée ...
Toutes les animations du fichier sont des copies de l'animation "promenade" sous différents noms et avec des longueurs différentes.

Je suis surpris que l'exportateur ne plante pas complètement dans le cas où vous avez une action avec plus d'images que les autres animations du fichier.

Une description succincte de ce bogue:

Toutes les images clés des animations exportées sont celles de l'animation sélectionnée au lieu de leurs propres images clés.

J'ai trouvé au moins une solution partielle pour cela ...

Dans "io_three \ exporter \ api \ animation.py"

au début de "parse_pose_action" (autour de la ligne 183)

insérer:

context.scene.objects.active = armature

Avec ce changement, j'exporte maintenant des animations uniques ...

Salut, merci pour ce commentaire + correction. J'ai fait le changement recommandé et exporté avec "Pose" et "Apply modifier" = off et cela fonctionne très bien !!
Merci

context.scene.objects.active = armature

J'ai hate d'essayer ça.

Eu les mêmes problèmes que j'ai soulevés dans:

https://github.com/mrdoob/three.js/issues/7165

Le travail a fonctionné pour moi, heureux de pouvoir créer plusieurs animations. Merci pour ça!

Génial! Heureux d'avoir pu aider!

J'ai lié quelques autres bogues qui peuvent être des manifestations de ceci, de retour à ce fil.

@manthrax (avec votre correction partielle) cela fonctionne bien pour moi en exportant 'Animations squelettiques: Pose' et en désélectionnant 'Utiliser le modificateur pendant le rendu' dans le modificateur d'armature.

Une démo d'un personnage avec 3 animations fonctionnelles> http://unboring.net/lab/6326/hero_72/

Pensez-vous qu'il serait possible / facile d'exporter et d'exécuter correctement les animations avec le «mode repos»?
Parce que dans ce cas, l'exportateur n'écrit que les images clés, pas toutes les images, et le fichier json passe de 873 Ko à 174 Ko

Envoyé des invitations Slack. Je ne sais pas quel genre de temps j'aurai demain mais je devrais avoir quelques heures dimanche.

@arturitu Je peux examiner cela ... Quel est le comportement actuel de la pose rest_mode qui est incorrecte?
Cela semble-t-il être le même problème?

@repsac :

L'exportation prend actuellement beaucoup de temps sur ma machine pour les grandes animations ...

Il s'avère que la grande majorité du temps est due à la journalisation du spam ...

Et le simple fait d'éteindre l'enregistreur ne résoudra probablement pas ce problème. J'ai eu ce problème avec les scripts python dans le passé ... Même si la sortie de journalisation est désactivée, la construction de la chaîne a toujours lieu dans les instructions de journalisation.
Le script devra être réécrit pour faire quelque chose comme "if (logging) log.debug (" blah ");" sur toutes les instructions de journalisation, afin de ne pas entraîner la surcharge de formatage de tous les messages.

Le simple fait de commenter les messages de journalisation que j'ai vus lors de l'exportation des animations / images clés a fait passer mon temps d'exportation de 2 minutes à environ 5 secondes.

@arturitu J'ai essayé l'exportation rest_pose ... J'ai eu un fichier plus petit, mais les liaisons squelettes sont foirées lors de la tentative de lecture ... Des idées?

Je teste avec le fichier de fusion marine, lié à un maillage différent ...

Animations squelettiques: repos

Animations squelettiques: pose

@manthrax Je pense que dans Rest a un problème avec la partie os sur JSON, car beaucoup d'entre eux ont beaucoup de "parent": null, tandis que dans Pose, les os ont la valeur parent correcto. Et le nombre d'os est différent (dans mon cas en Pose écrivez 38 et en repos seulement 28)

Mais je ne sais pas s'il faudrait un autre type de BlendCharacter.js pour afficher une animation correcte

Le script devra être réécrit pour faire quelque chose comme "if (logging) log.debug (" blah ");" sur toutes les instructions de journalisation, afin de ne pas entraîner la surcharge de formatage de tous les messages.

Probablement pas, cela peut être adressable dans le module de journalisation lui-même. Regarde ça maintenant

Autre problème, je devais avoir la bonne combinaison de "repos" sélectionnée à la fois dans les paramètres du script et sur l'armature. Cela semble fragile.

C'est le cas, et j'avais tenté de résoudre ce problème dans le passé. Il y a des sections commentées avec

armature.data.pose_position =

partout. En l'essayant dans le shell de Blender, cela fonctionnait, mais ce n'était pas le cas lors de l'exportation. Je n'ai pas essayé dans les versions récentes de Blender, donc peut-être que cela a été corrigé (jusqu'à ce qu'il soit à nouveau cassé).

Avec ce changement, j'exporte maintenant des animations uniques ...

Bonne prise. La conscience contextuelle de Blender dont il a besoin est si implicite parfois qu'elle devient exaspérante à gérer.

La désactivation du journal était facile. Étant donné que le repo à trois est trop volumineux, j'ai créé un repo temporaire qui ne concernera que l'exportateur, tout finira par être fusionné.
https://github.com/repsac/io_three

D'après ce que je peux dire, dans les circonstances normales d'exportation d'un maillage skinné, cela ne devrait jamais être le cas, et devrait être désactivé par défaut ou avoir une bascule séparée pour exclure les maillages skinned.

Si on ne peut pas expliquer pourquoi il devrait rester actif, je choisirais de le définir sur False si les animations sont activées. Le seul problème peut être dans les exportations de scènes, ce que je suis sur la clôture si les exportations de scènes doivent de toute façon prendre en charge les animations. J'ai eu des problèmes avec la façon dont Blender gère les actions sous le capot, ce qui le rend très fragile.

@repsac Je voulais juste dire ... L'exportateur est génial. J'espère qu'aucun de mes commentaires ne sera considéré comme une critique ... J'ai écrit beaucoup plus d'exportateurs de mélangeurs primitifs dans le passé ... mais rien avec la portée de celui-ci, il n'est donc pas exagéré de dire que c'est une grande réussite.

Concernant la journalisation: je ne suis toujours pas sûr de la manière dont la surcharge du formatage des messages de journal est éliminée en désactivant simplement la sortie dans le cadre de journalisation, mais peut-être que je ne comprends pas les nuances du cadre.

D'après ce que je peux dire, toute journalisation de la forme "someLoggingFunction (" formatted text: xyz ")" entraînera TOUJOURS la conversion de texte / formatage du message, même si la fonction n'émet pas le texte en interne

Pour une journalisation sans surcharge, les choses devraient prendre la forme de "Logger.log (function () {return SomeFormattedText;}), où la fonction transmise n'est appelée que si la journalisation est activée.

. Dans un langage vraiment compilé et optimisé, le compilateur pourrait être capable de détecter que la fonction est un no-op et sklp les appels de mise en forme, mais même dans ce cas, les appels de mise en forme pourraient avoir des effets secondaires pour le reste du programme, donc généralement ils serait toujours inclus.

re: Exportations de scène prenant en charge l'animation ...
Je suis d'accord, qu'à court terme, il est probablement trop tôt pour s'engager dans cette voie, MAIS, si nous en arrivons au point où cela pourrait fonctionner ... ce serait assez incroyable de pouvoir créer des niveaux entiers avec animation et exporter WYSIWYG à three.js Les moulins à vent tourneraient ... les rivières et les chutes d'eau pourraient s'animer aux UV .. les plates-formes pourraient voler ... le tout sans écrire de code. Un jour ...: D

D'après ce que je peux dire, toute journalisation de la forme "someLoggingFunction (" formatted text: xyz ")" entraînera TOUJOURS la conversion de texte / formatage du message, même si la fonction n'émet pas le texte en interne

Eh bien, tout appel de journalisation doit être formaté comme tel:

logger.info("foo bar %s", arg)

Ainsi, la chaîne n'est pas formatée tant que l'API de journalisation n'est pas passée *args sous le capot. J'ai changé la logique de journalisation en

https://github.com/repsac/io_three/blob/master/addons/io_three/exporter/__init__.py

        level = options.get(constants.LOGGING, constants.DISABLED)
        version = options.get('addon_version')
        if level != constants.DISABLED:
            logger.init('io_three.export.log', level=level)

https://github.com/repsac/io_three/blob/master/addons/io_three/logger.py

def _logger(func):

    def inner(*args):
        if LOGGER is not None:
            func(*args)

    return inner


<strong i="18">@_logger</strong>
def info(*args):
    LOGGER.info(*args)


<strong i="19">@_logger</strong>
def debug(*args):
    LOGGER.debug(*args)


<strong i="20">@_logger</strong>
def warning(*args):
    LOGGER.warning(*args)


<strong i="21">@_logger</strong>
def error(*args):
    LOGGER.error(*args)


<strong i="22">@_logger</strong>
def critical(*args):
    LOGGER.critical(*args)

Aucun message ne doit être formaté. Je n'ai pas de grandes scènes donc je ne peux pas tester cela, mais en théorie, cela devrait, et si ce n'est pas le cas, cela devient la raison # 4576 pour laquelle je déteste la programmation.

J'espère qu'aucun de mes commentaires ne sera considéré comme une critique

Pas à peine, entre les entreprises de technologie pleines de bro-grammers ici à SF (y compris la Silicon Valley) et l'industrie VFX, j'ai eu waaaaaaay pire m'a dit dans des interviews.

Je passe actuellement en revue tout ce fil et essaye de dresser une liste à puces de ce qui doit être fait spécifiquement. Je le publierai quand j'aurai quelque chose pour que vous puissiez voir s'il est proche.

Oh excellent! On dirait que vous avez couvert la journalisation. Mon python était un peu faible pour comprendre les nuances de votre solution.

Petit monde, je suis aussi à SF!

Très cool ... pour autant que je puisse glaner dans ce fil, c'est principalement le correctif d'une ligne, puis résoudre l'ambiguïté du mode "repos" ... Je ne suis toujours pas sûr du mode de repos du cas d'utilisation .. si vous en connaissez un, je vous serais reconnaissant de le comprendre ...

Il faudrait que je fouille tous les anciens problèmes pour vous donner des liens spécifiques, mais pour une réponse rapide, voici une ventilation:

• autour de r66, il y avait un commit qui a changé les exportations de l'utilisation de REST à l'utilisation du mode POSE
• J'avais commencé ma propre version de l'exportateur à cette époque, qui est devenue celle dont nous parlons maintenant, et basé ma logique d'origine sur la logique REST
• à la mine R70 était l'exportateur de remplacement, c'est à ce moment-là que tout s'est déchaîné
• J'ai remplacé la logique par le support POSE, qui a ensuite interrompu les exportations pour les autres utilisateurs
• Je ne pouvais pas comprendre ce qui se passait alors j'ai implémenté la bascule entre les 2

Jusqu'à présent, il semble y avoir 2 éléments à traiter:

1) Définition du contexte actif sur l'armature

context.scene.objects.active = armature

2) N'appliquez pas de modificateurs aux maillages skinned

Je vais tester à nouveau le changement de pose automatisé. Quelqu'un a dit une fois qu'il avait compris cela à partir d'un script différent, mais que cette sauce secrète n'a pas été introduite dans l'exportateur.

@manthrax Pouvez-vous
https://github.com/repsac/three.js/tree/anim_fix

Cela fonctionne bien pour les animations en mode pose tant que votre première image clé a l'armature configurée exactement de la même manière que votre maillage. Si vous essayez d'ajouter des transformations loc / rot / scale, en mode pose, et de les affecter comme première image clé, le modèle est alors déformé.

J'ai également rencontré le problème REST / POSE (branche de développement à jour). Le modèle a plus de 40 os et 7 actions. POSE fonctionne bien, mais le fichier exporté est énorme. REST a des animations totalement déformées.

Le problème semble se trouver dans le tableau exporté _skinIndices_. Que ce soit en mode POSE ou REST, le tableau _skinIndices_ est identique, mais l'ordre et donc les indices dans le tableau _bones_ exporté sont complètement différents. Je pense que c'est parce que __rest_bones () _ utilise _armature.data.bones_ pour indexer les os et __pose_bones_ utilise _armature.pose.bones_ (api / mesh.py). Plus tard, __skinning_data () _ utilise toujours _armature.pose.bones_ quel que soit le paramètre REST / POSE. Un test rapide semble le confirmer. Utiliser _armature.data.bones_ dans __skinning_data () _ exporte correctement mon modèle et mes animations en mode REST.

Je ne connais pas assez bien three.js pour répondre à cela et soumettre un correctif, mais lequel est en fait faux _skinIndices_ ou la commande de _bones_? L'ordre des _bones_ dans REST semble être identique aux indices des groupes de vertex Blender, ce qui est probablement une bonne chose.

Bonjour, ce numéro n'a pas été clos ni conclu sur ce qui est maintenant? J'ai donc une autre préoccupation à ce sujet: est-ce que quelqu'un a expérimenté la lecture simultanée de 2 animations? Mes essais ne fonctionnent pas mais je ne suis pas sûr de la qualité de mon objet 3D. D'un autre côté de ce que j'ai lu ci-dessus, je me demande si cela est réellement possible?

pour compléter la préoccupation: l'exportateur de mélangeur autorise-t-il NLA?

@Derived oui le mélange et la lecture d'animations multiples fonctionnent dans le dernier three.js

Nla plus généralement n'est pris en charge que pour les os AFAIK

Salut, merci pour ce commentaire. Oui, je peux exécuter plusieurs animations et il y a un "mélange" des animations; J'utilise v71 mais avec la version mise à jour de Blender Export (comme discuté ci-dessus). Mais permettez-moi cependant de mieux expliquer mon observation:

Mon modèle a 2 animations truquées: (A1) bras de levage et (A2) tourner la tête à gauche.

1) Jouez (A1) "lever les bras" puis arrêtez-vous à mi-chemin de l'animation (les bras sont à mi-chemin)
2) jouer (A2) "tourner la tête à gauche" => la tête tourne à gauche MAIS les bras reviennent en position initiale au lieu de rester là où ils sont.
3) Enfin, si je joue les 2 ensemble, la tête tourne à gauche et les bras se lèvent mais pas comme ils devraient le faire mais plutôt comme un mélange de (A1) (soulever) et (A2) (ne pas bouger les bras) avec l'influence des os immobiles de (A1) aux mobiles de (A2) et opposés.
Par conséquent, j'ai regardé dans le fichier json et je peux voir que l'animation décrit les positions des os pour TOUS les os dans chaque animation. Ainsi, pour (A2) "tourner la tête à gauche", l'animation inclut les positions des os pour les bras qui ne changent tout simplement pas (à droite, A2 ils ne bougent pas en A2). Mais comment three.js suppose-t-il que ces positions osseuses ne sont pas significatives et ne devraient pas influencer la course de (A1)?
J'espère que cet exemple est compréhensible.

Perdre mon esprit à cause de ça

Voici mon maillage truqué dans le mélangeur:

Le voici en threejs:

J'ai passé 2 jours d'affilée sur l'exportation seul. Dernier mixeur, trois derniers. Quel est l'état actuel de l'exportateur?

@DelvarWorld Je pense que vous devez utiliser l'exportateur Blender sur la branche DEV pour fonctionner correctement.

@arturitu je suis :(

@DelvarWorld

Quel est l'état actuel de l'exportateur?

je pense que ce

repsac n'a pas été attribué par mrdoob le 30 décembre 2015

pourrait être le problème. Il a évidemment besoin d'un peu d'amour.

Je pourrais peut-être partir à la recherche des différents bugs qui ont été signalés récemment. Pouvez-vous partager un fichier pour reproduire ce problème (le plus simple, le mieux)?

Pour plus de commodité, je posterai ceci ici aussi. J'ai essayé d'exporter un formulaire de modèle de test @DelvarWorld et posté un commentaire et une capture d'écran dans # 8412.

@phfatmonkey
https://github.com/mrdoob/three.js/pull/8412#issuecomment -210675561 celui-ci?

Excellent travail pour résoudre tous ces problèmes: +1:!

Lorsque vous avez terminé la mise à jour des correctifs, pourriez-vous ouvrir un nouveau ticket avec des descriptions ou des liens vers les problèmes d'exportateur restants, nouvellement créés ou découverts?

Il est incroyablement difficile de garder une trace des choses quand elles sont publiées quelque part sur des billets existants.

Idéalement, un par cas (s'il n'existe pas encore) et un maître "Blender Exporter Issues" (ou quelque chose comme ça) les référençant tous.

Ce que je me souviens du sommet de ma tête est

• Les normales manquaient de rotation (fixe)
• Problème d'animation lors de l'exportation d'une hiérarchie de scènes. Ça marche maintenant?
• Ensuite, il y a le reste du problème de pose mentionné dans votre message
• Ensuite, il y a le problème de skinning / keyframes (messages d'erreur?)
• ... (il y en avait plus, je pense)

Bien sûr! C'est une bonne idée. J'essaierai d'y arriver ce week-end,
sinon le lundi quand je rentre au bureau.
Le 15 avril 2016 à 17 h 12, "tschw" [email protected] a écrit:

@phfatmonkey https://github.com/phfatmonkey

8412 (commentaire)

https://github.com/mrdoob/three.js/pull/8412#issuecomment -210675561
celui-là?

Excellent travail pour résoudre tous ces problèmes [image:: +1:]!

Lorsque vous avez terminé le patch, pourriez-vous ouvrir un nouveau ticket
description ou lien vers les éléments restants, nouvellement créés ou découverts
problèmes d'exportateurs?

Il est incroyablement difficile de garder une trace des choses quand elles sont publiées
quelque part sur les billets existants.

Idéalement un par cas (s'il n'existe pas encore) et un maître "Blender Exporter
Problèmes »(ou quelque chose comme ça) les référençant tous.

Ce que je me souviens du sommet de ma tête est

• Les normales manquaient de rotation (fixe)
• Problème d'animation lors de l'exportation d'une hiérarchie de scènes. Ça marche maintenant?
• Ensuite, il y a le reste du problème de pose mentionné dans votre message
• Ensuite, il y a le problème de skinning / keyframes (messages d'erreur?)
• ...

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/mrdoob/three.js/issues/6050#issuecomment -210693332

Qu'en est-il de l'édition d'animation non linéaire telle qu'elle peut être effectuée dans Blender? N'y a-t-il personne intéressé par cette question? J'ai expliqué le point dans un message précédent mais je n'ai reçu aucun commentaire?

@derivou
Quel message?

Lorsqu'il a besoin d'un code personnalisé, quelqu'un devra l'écrire. Une contribution pourrait être la bienvenue ...

Voici le message ci-dessus daté du 5 février, j'ai expliqué le problème lors de la combinaison de plusieurs animations.
Je serais heureux d'aider au développement, mais je pense que cela nécessite d'abord quelques discussions pour partager des idées et discuter de la façon de le mettre en œuvre. J'ai donc ouvert un élément de suggestion "Animation non linéaire" # 7913

C'est un long problème et j'avouerai que je n'ai pas tout lu, mais si le problème est toujours tel que décrit par l'OP (c'est-à-dire que vous avez besoin d'un moyen d'animer un personnage dans Mixamo et de le charger dans three.js), vous pouvez le faire. ceci avec l'exportateur glTF Blender et THREE.GLTFLoader. Voici mon flux de travail: https://medium.com/@donmccurdy/creating -animated-gltf-characters-with-mixamo-and-blender-728dc120e678

Vous pouvez également simplement exporter en tant que FBX depuis Mixamo et charger directement à l'aide du FBXLoader.
Depuis la dernière version (R89), cela devrait fonctionner très bien.