GLTFLoader: exposing GLTFParser class and Constants

[yomotsu]

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

[donmccurdy]

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.

[yomotsu]

Thanks for your suggestions and comments.

I didn't know that the loader can call parse() and It could cover most.
(Sorry, I should have read the doc and code more)

What I wanted to do is inject some function in loader.parse().
getParser() and modifying the parser before parse() could do that as you said. (related to #15418)

But using GLTFParser directly without GLTFLoader can also cover that and helpful. I was wondering if you could consider this too.

Anyway looking forward to getParser() 👍

Regarding the constants, I think ideally it should be in one place, rather than in both GLTFLoader.js and NPM, but it still sounds good!

[mrdoob]

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.

[donmccurdy]

Rather than another top-level object, maybe just GLTFLoader.Parser? Even when using the parser directly users should generally not construct it themselves, but use loader.getParser() when that is implemented. Constants could be something like GLTFLoader.WebGLConstants.FLOAT.

... ideally it should be in one place, rather than in both GLTFLoader.js and NPM...

The idea here would be that there should be official glTF constants on NPM (e.g. maintained by Khronos, not just for three.js), so users can install them in the rare case that they need custom parsing. But threejs examples cannot have dependencies, so the constants will have to be duplicated for GLTFLoader.

[donmccurdy]

^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.

[takahirox]

glTF-ish file may need special parsing using modified(extended) GLTFParser.

Just curious to know what "glTF-ish file" means by.

[takahirox]

Rather than another top-level object, maybe just GLTFLoader.Parser?

Voting for non top-level object.

I think putting under THREE may require better maintenance, for example writing document and keeping compatibility as much as possible. It may be too early for the parser yet. I guess we still optimize/refactor/update the parser.

[yomotsu]

@takahirox GLTFLoader.Parser could be okay for that?

Just curious to know what "glTF-ish file" means by.

I meant VRM and maybe eVRM (can be seen in ニコニ立体), or othrer Web App oriented models.

[takahirox]

Making .getParser() PR. I think I can share soon. We can start with that.

[takahirox]

@yomotsu My understanding is VRM consists of glTF 2.0 core spec with some limitation + VRM custom extension. And parser in user side is necessary for handling the custom extension, correct? "glTF-ish" sounded a bit vague to me so I just want it to be more specific.

[yomotsu]

That's right. VRM is a glTF based extended format, and the Parser may need to handle HumanBones, Facial expression blendings, MToon Materials, and others.

In addition, some Web App like ニコニ立体 may use encrypted VRM like "eVRM" in order to protect user upload models, and injecting user-land function to the parser may be needed as well.

[donmccurdy]

To be clear, we can't guarantee that the parser's API will remain the same over time. Internal methods might be renamed or removed, and extending them may be fragile. If you're really customizing the loader for new formats and extensions, it's very possible you'll want to just fork the loader.

But if you're OK with all that, a PR is still fine with me.

[yomotsu]

Thanks for your suggestions. I understand and getParser would be safer to use.
Even though, having the official Parser class as GLTFLoader.Parser would be great for me.

@takahirox Would it be okay?

[takahirox]

I wanna suggest that we first go with .getParser(). And thinking of the option exposing GLTFLoader.Parser when we realize we really need.

[yomotsu]

Okay, I will wait for it 👍

[donmccurdy]

Do we still need this, with access to the gltf.parser object and the newer extension API?

[yomotsu]

It would be better for me.
@fms-cat What do you think?

[0b5vr]

Yes, exposed parser and the plugin system is working well.

[takahirox]

The plugin system provides the extensibility of the loader. How do you want to use the exposed parser class? In other words, What are the use cases the plugin system still doesn't cover?

[mrdoob]

If I understand @fms-cat correctly, he's saying that this issue can be closed.

[0b5vr]

I mean, the constructor of GLTFParser is okay to not be exposed I think. my bad.

[takahirox]

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.