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.gltfParserTHREE.WEBGL_CONSTANTS.FLOAT = 5126and so on
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.
Wouldn’t be opposed to move
GLTFParseroutside of the closure and add it to theTHREEnamespace.The module version of the file could eventually export
GLTFLoaderandGLTFParser.^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.
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.