Docs: Update DRACOLoader documentation to recommend reusing a loader instance #20973
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: --
Description
I've gotten into the habit of creating a new
Loader
(GLTF, OBJ, DAE, etc) for every model I want to load because once you've started to load a model you can't modify the options. However when working on the 3DTilesRenderer project I noticed that every time a tile with DRACO compression was being loaded it would download and create a new DRACO decoder instance resulting in extremely slow parsing and out of memory errors. I fixed this by reusing a single DRACOLoader instance which I think is outside of the typical use for loaders so I thought it should be documented. I expected that once the first DRACOLoader downloaded an instance of the decoder data it would not need to try again to load it from the same url but that doesn't seem to be the case.You can see the behavior in this jsfiddle that creates a new DRACOLoader to load a DRACO GLTF file and 1 second later does the same thing. In the Network tab you can see it downloads the WASM and JS wrapper twice:
https://jsfiddle.net/qe85wdmu/
cc @donmccurdy