DRACOLoader: use decoder from gstatic by default

[JL-Vidinoti]

Description

The DRACOLoader requires to set the decoder path using setDecoderPath.
The documentation gives the following usage example:

const loader = new DRACOLoader();

// Specify path to a folder containing WASM/JS decoding libraries.
loader.setDecoderPath( '/examples/jsm/libs/draco/' );

However, it is not always very convenient to provide the decoder path because the decoder files need to be hosted somewhere. Providing explicitly the decoder path may be optional.

Solution

The draco team recommends using the decoders hosted on www.gstatic.com (see README file at https://github.com/google/draco/tree/master).
For instance, the current draco decoders are available at https://www.gstatic.com/draco/versioned/decoders/1.5.6/

I suggest that the DRACOLoader uses this URL by default if a decoder path is not explicitly set using setDecoderPath.

Alternatives

As a three.js developer, we can simply set the decoder path using dracoLoader.setDecoderPath( "https://www.gstatic.com/draco/versioned/decoders/1.5.6/");
But it is hard to keep track of the draco version when updating three.js to a new version.

Additional context

No response

[mrdoob]

Considering that we're slowly introducing examples that import directly from https://unpkg.com/... makes sense to also load the daco library from gstatic.

@donmccurdy What do you think?

[donmccurdy]

I am OK with doing this for examples.

Personally though, I would not recommend relying on CDNs for production software – I don't agree with the Draco team's advice about that. Gstatic is more reliable than Unpkg, yes, but even on Gstatic, updates sometimes break: google/draco#751. If reliability is important, it is better to deploy the decoders with your application, so that you know when updates are happening and have the opportunity to test them.

[donmccurdy]

I don't feel strongly that action is needed here. I do have some misgivings about loading WASM resources from third-party CDNs as a default behavior, which our users would need to discover and opt-out if they don't want. Closing for now, but willing to discuss more if others disagree.