Three.js: GLTF2Loader sollte Abhängigkeiten von oben nach unten laden.

Erstellt am 11. Aug. 2017  ·  3Kommentare  ·  Quelle: mrdoob/three.js

Das aktuelle Muster in GLTF2Loader sieht etwa so aus:

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;

    } );

  }

  // ...
}

Als Ergebnis werden alle Accessoren (die wiederum von allen .bin Pufferdateien abhängen) geladen, bevor Meshes erstellt werden können. Dies führt zu einem Problem, wenn nicht alle Puffer tatsächlich benötigt werden. Zum Beispiel:

  • Die (Entwurf) KHR_draco_mesh_compression- Erweiterung ermöglicht es, dass ein Asset eine Draco .bin Datei und eine unkomprimierte .bin -Datei enthält, sodass Clients, die Draco nicht unterstützen, dennoch auf die nicht optimierte Version zurückgreifen können. In beiden Fällen möchten wir nur einen der Puffer laden.
  • Die (Entwurf) MSFT_lod- Erweiterung hat im Wesentlichen das gleiche Problem.
  • Es ist bereits gültig, obwohl ich keine Beispiele gesehen habe, sowohl metallraue als auch glänzende Materialien auf demselben Netz zu deklarieren. Der Lader kann je nach Leistung und Funktionsunterstützung auswählen, was er verwenden soll, aber Sie tun dies sicherlich nicht. Ich möchte nicht die Texturen für beide anfordern. Derzeit würde GLTF2Loader genau dies tun.

Daher denke ich, dass es notwendig sein könnte, GLTF2Loader umzustrukturieren, um Abhängigkeiten von oben nach unten anzufordern. Die vorgeschlagene Syntax (es sei denn, es gibt gute vorhandene Beispiele zum Nachahmen) wäre etwa so:

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;

     } );

  }

  // ...
}

^Verwenden von ES6 aus Gründen der Prägnanz, obwohl das vermutlich nicht wirklich in example/js eingecheckt werden kann.

Bevor ich mich auf die Reise des Refactoring begebe, gibt es irgendwelche starken Präferenzen, wie dies funktionieren soll? Ich hoffe, muss aber überprüfen, dass diese Änderung schrittweise erfolgen kann.

/cc @takahirox

Hilfreichster Kommentar

Ich denke, es ist in Ordnung, den Internet Explorer zu verlassen, um überschaubaren Code zum Laden von gltf zu erhalten 👌

Also Promise s sind cool. ES6... hängt von der Funktion und der Browserkompatibilität ab.

Alle 3 Kommentare

Ich stimme der Umgestaltung zu.
IMO ist die Kombination von _withDependencies und _each etwas komplex.

Übrigens , Promise und ES6 zu verwenden?

Ich denke, es ist in Ordnung, den Internet Explorer zu verlassen, um überschaubaren Code zum Laden von gltf zu erhalten 👌

Also Promise s sind cool. ES6... hängt von der Funktion und der Browserkompatibilität ab.

Danke @takahirox für das Refactoring!

Ich denke, das kann geschlossen werden. Einige Teile sind nicht streng von oben nach unten – für ein Modell mit mehreren Szenen möchten wir vielleicht eines Tages keine Knoten oder Zugriffselemente über getMultiDependencies() abrufen. Aber bei allen Beispielmodellen, die ich bisher gesehen habe, sieht die aktuelle Struktur viel besser aus.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen