Three.js: GLTF2Loader doit charger les dépendances de haut en bas.

Créé le 11 août 2017  ·  3Commentaires  ·  Source: mrdoob/three.js

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:

  • L'extension (brouillon) KHR_draco_mesh_compression permet à un actif d'inclure un fichier Draco .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.
  • L'extension (ébauche) MSFT_lod a essentiellement le même problème.
  • Il est déjà valable, bien que je n'aie pas vu d'exemples, de déclarer à la fois des matériaux rugueux et brillants sur le même maillage. Le chargeur peut choisir lequel utiliser, en fonction des performances et de la prise en charge des fonctionnalités, mais vous ne le faites certainement pas. Je ne veux pas demander les textures pour les deux. Actuellement, c'est exactement ce que ferait GLTF2Loader.

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

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.

Tous les 3 commentaires

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.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Bandit picture Bandit  ·  3Commentaires

makc picture makc  ·  3Commentaires

Horray picture Horray  ·  3Commentaires

akshaysrin picture akshaysrin  ·  3Commentaires

zsitro picture zsitro  ·  3Commentaires