Support GLTFLoaderPlugin::load::loadersGl parameter to load alternative loaders.gl version#2035
Support GLTFLoaderPlugin::load::loadersGl parameter to load alternative loaders.gl version#2035MichalDybizbanskiCreoox wants to merge 1 commit into
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| * @param {Boolean} [params.globalizeObjectIds=false] Indicates whether to globalize each {@link Entity#id} and {@link MetaObject#id}, in case you need to prevent ID clashes with other models. | ||
| * @param {*} [params.parseOptions={}] Options to pass to loaders.gl parse method, eg. ````{ gltf: { excludeExtensions: { "KHR_texture_transform": false } } }````. | ||
| * @param {Boolean} [params.entityPerMesh=false] Create an entity for each mesh, instead of grouping leaf meshes under their common entity. | ||
| * @param {*} [params.loadersGl={core,gltf}] Alternative user-provided loaders.gl library. |
There was a problem hiding this comment.
To decide what to do when someone inputs here the version not compatible with the one we currently support. Or once we will upgrade the version internally, but someone still loads the alternative version which was compatible at first, but would no longer be compatible after an upgrade.
There was a problem hiding this comment.
I think we have to hope for loader.gl's interface not to change, and for the users to check compatibility at their discretion.
We plan to implement at some point an alternative gltf loader that doesn't depend on loaders.gl.
There was a problem hiding this comment.
Looking at these logs: https://loaders.gl/docs/upgrade-guide I'm not sure if we can hope for lack of breaking changes.
Problem is such additional ability (ability to load alternative loaders.gl version) for me it suggests you can plug any version there and it will work (any existing version from the past and any version which will appear in the future), but is it true?
There was a problem hiding this comment.
I don't think there is any practical way to reliably manage compatibility tests of custom loaders.gl versions passed to the GLTFLoaderPlugin.
We'd either end up excluding some valid ones, and/or accepting invalid ones.
Users are free to pass an arbitrary version, but the onus is on them to make sure it's a valid one.
The loadersGl parameter is not a feature required to use - after all we still provide a fallback to the hardcoded loaders.gl version.
Even if we didn't provide a fallback - which me might end up doing in the future - the best we could do would be to name a version (or a number of versions) that we had verified to be cooperative with the plugin.
Preventing users from using a version which we didn't verify, but which could be good enough for the plugin, would be overprotective IMO.
…ve loaders.gl version
MichalDybizbanskiCreoox
force-pushed
the
XEOK-444-user-loaders-gl
branch
from
a53dfff to
73e0fd2
Compare
mmilian
force-pushed
the
master
branch
2 times, most recently
from
7d99334 to
88c5ea1
Compare
3 participants
The PR makes it possible for users to inject their own loaders.gl library of any version to be used by
GLTFLoaderPlugin.The
GLTFLoaderPlugin::load::loadersGlcan be passed as a{ core, gltf }object that contains loader.gl’s core and gltf modules respectively.If
loadersGlobject is provided, theGLTFLoaderPluginwill use it instead of the default v4.3.4 version.