GLTFLoader: exposing GLTFParser class and Constants

Currently, GLTFParser and constants in GLTFLoader are scoped and cannot be used in user-land.
However, sometimes it is needed.

Usecases:

  • glTF-ish file may need special parsing using modified(extended) GLTFParser.
  • glTF models may be supplied in JSON or JSONP format from a WebApp API rather than files and need GLTFParser directly.

Also, WEBGL_CONSTANTS and other constants would be useful if available under THREE or somewhere

What I would like to have is:

  • THREE.GLTFParser

and maybe:

  • gltfLoaderInstance.gltfParser
  • THREE.WEBGL_CONSTANTS.FLOAT = 5126 and so on

Author: Fantashit

4 thoughts on “GLTFLoader: exposing GLTFParser class and Constants

  1. One option available now is the loader.parse() method — it accepts JSON or an ArrayBuffer you’ve already downloaded and parses it, which is helpful for cases like the JSONP API you mention.

    We’ve also discussed (#14492) adding a getParser(...) method to GLTFLoader, so you can access a parser instance before content is downloaded. The loader creates a new parser for each asset it loads, to contain caching information etc.

    Between the two, I think that would cover everything you suggest except the constants? Exposing the constants could be OK, and has been suggested before (#11978). Another option would be to put these constants on NPM separately, similar to DefinitelyTyped/DefinitelyTyped#29801.

  2. Wouldn’t be opposed to move GLTFParser outside of the closure and add it to the THREE namespace.

    The module version of the file could eventually export GLTFLoader and GLTFParser.

  3. ^Feel free to open a PR for moving the parser and constants out of the closure if this is still helpful. I would wait on other PRs for the rest.

  4. OK, thanks for clarifying.

    Then, let’s close this issue for now. And let’s reopen or create a new one if you folks encounter a use case the plugin system doesn’t cover.

Comments are closed.