Le modèle actuel dans GLTF2Loader ressemble à ceci :
class GLTF2Parser {
loadMeshes () {
return this._withDependencies( [
'materials',
'accessors'
] ).then( ( dependencies ) => {
_each( json.meshes, ( meshDef ) => {
var geometry = /* ... */;
var material = dependencies.materials[ meshDef.material ];
var mesh = new THREE.Mesh( geometry, material );
// ...
return mesh;
} );
// ...
return meshes;
} );
}
// ...
}
En conséquence, tous les accesseurs (qui dépendent à leur tour de tous les fichiers tampons .bin
) seront chargés avant que des maillages puissent être créés. Cela introduit un problème, si tous les tampons ne sont pas réellement nécessaires. Par exemple:
.bin
et un .bin
non compressé, de sorte que les clients ne prenant pas en charge Draco puissent toujours se rabattre sur la version non optimisée. Dans les deux cas, nous voulons charger un seul des tampons.Donc, je pense qu'il pourrait être nécessaire de restructurer GLTF2Loader pour demander des dépendances de haut en bas. La syntaxe proposée (à moins qu'il n'y ait de bons exemples existants à imiter) ressemblerait à ceci :
class GLTF2Parser {
loadMesh ( meshDef ) {
return Promise.all( [
this.loadGeometry( meshDef.primitives ),
this.loadMaterial( meshDef.material )
] ).then( ( dependencies ) => {
var [geometry, material] = dependencies;
var mesh new THREE.Mesh( geometry, material );
// ...
return mesh;
} );
}
// ...
}
^ Utiliser ES6 pour plus de concision, bien que cela ne puisse probablement pas être vérifié dans des exemples/js.
Avant de me lancer dans un voyage de refactorisation, des préférences fortes sur la façon dont cela devrait fonctionner ? J'espère, mais je devrai vérifier, que ce changement pourrait se produire progressivement.
/cc @takahirox
Je suis d'accord avec le refactoring.
OMI, la combinaison de _withDependencies
et _each
est un peu complexe.
BTW, @mrdoob nous autorisez-vous à utiliser Promise
et ES6 ?
Je suppose que vous pouvez abandonner Internet Explorer afin d'obtenir un code gérable pour le chargement de gltf 👌
Alors les Promise
sont cool. ES6... dépend de la fonctionnalité et de la compatibilité du navigateur.
Merci @takahirox pour la refactorisation !
Je pense que cela peut être fermé. Certaines parties ne sont pas strictement descendantes — pour un modèle avec plusieurs scènes, nous pourrions un jour vouloir ne pas récupérer les nœuds ou les accesseurs via getMultiDependencies()
. Mais pour tous les exemples de modèles que j'ai vus jusqu'à présent, la structure actuelle est bien meilleure.
Commentaire le plus utile
Je suppose que vous pouvez abandonner Internet Explorer afin d'obtenir un code gérable pour le chargement de gltf 👌
Alors les
Promise
sont cool. ES6... dépend de la fonctionnalité et de la compatibilité du navigateur.