You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TileDatapayload field carries a note that it can either contain the GLB data or an URI.
Functions like glbToI3dm or the (internal) extractGlbBuffers always assume that the payload is an embedded GLB. But this should be generalized. This will include some minor implementations for on-the-fly resolving of the GLB data from the URI and the corresponding error handling. It may also involve extending the CLI. For example, one could consider to offer an option like
... glbToI3dm -i input.glb -o output.i3dm -useUriForGlb
^--- this
at the command line.
The text was updated successfully, but these errors were encountered:
The PR #83 covers most of this: The functions that deal with I3DMs now usually receive an externalGlbResolver, which is a function that takes a URI and returns the Buffer with the data. (There are some degrees of freedom for things like error handling, but the main point is that external GLBs should now be supported more consistently).
The idea of generalizing the glbToI3dm command is now tracked in #84
The
TileData
payload
field carries a note that it can either contain the GLB data or an URI.Functions like
glbToI3dm
or the (internal)extractGlbBuffers
always assume that the payload is an embedded GLB. But this should be generalized. This will include some minor implementations for on-the-fly resolving of the GLB data from the URI and the corresponding error handling. It may also involve extending the CLI. For example, one could consider to offer an option likeat the command line.
The text was updated successfully, but these errors were encountered: