Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"options.loadLinkedResources: true" Doesn't work in new Tileset3D. #2740

Open
IDONKN opened this issue Oct 26, 2023 · 4 comments
Open

"options.loadLinkedResources: true" Doesn't work in new Tileset3D. #2740

IDONKN opened this issue Oct 26, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@IDONKN
Copy link

IDONKN commented Oct 26, 2023

May I kindly inquire about the purpose of this option? Furthermore, could you please provide guidance on how to set this option?

While executing the postProcessGLTF operation, it appears that there is no available method to retain the buffer.arrayBuffer afterwards.

As mentioned in the official website documentation, the following fields will be filled with data from the provided gltf.buffers parameter. It's worth noting that this parameter is populated by the loader by utilizing the options.loadLinkedResources: true configuration:

buffer.arrayBuffer
buffer.byteOffset
buffer.byteLength
Please let me know if there's anything else I can assist you with.

@ibgreen ibgreen added the bug Something isn't working label Oct 26, 2023
@ibgreen
Copy link
Collaborator

ibgreen commented Oct 26, 2023

Firstly, at first blush I think there may be an issue with the documentation not being updated.

  • I can't find any mention of loadLinkedResources in the actual 4.0 code base (master).
  • The GLTFLoader supports options.gltf.loadBuffers and options.glTF.loadImages.
  • I believe these are both true by default so all linked resources should be loaded.

Not sure if it helps, but I think you have also understood that:

  • postProcessGLTF() does not load anything, just works with what the GLTFLoader loaded.

@ibgreen
Copy link
Collaborator

ibgreen commented Oct 26, 2023

t appears that there is no available method to retain the buffer.arrayBuffer afterwards.

What do you mean with retain? Make a copy of the buffer so that your app can hold on to it? Why do you need a method? Can't you just copy the buffer from the returned data structure?

@IDONKN
Copy link
Author

IDONKN commented Oct 26, 2023

Hello, my process is as follows:

I'm learning from the following example - how threejs displays a model through the data returned by @loaders.gl/3d-tiles (Tiles3DLoader).
https://github.com/visgl/loaders.gl/tree/master/examples/experimental/3d-tiles-with-three.js.

The above example contains this piece of code:


export async function loadGltfModelTile(url) {
     const content = await load(url, Tiles3DLoader, {
         '3d-tiles': {
             loadGLTF: true
         },
         gltf: {
         }
     });

     const tile = {};
     tile.glbData = content.gltfArrayBuffer;
     return tile;
}

When using the new Tile3D method to parse files in B3DM and I3DM formats, "gltfArrayBuffer" is included in the returned data. This should be added by the method parse3DTileGLTFViewSync.

But when parsing GLTF and GLB files, there are no parameters, so I'm trying to find similar variables.

Of course, it's possible that I haven't understood the relationship between buffer.arrayBuffer and BufferViews.

@ibgreen
Copy link
Collaborator

ibgreen commented Oct 26, 2023

When you are working with three.js, you don't want loaders.gl to parse the embedded glTF file. You want to pass the embedded binary (glb) or URL to THREE's gltf loader . I believe this is what the example does.

That example was written before 3DTILES 1.1 which allows tiles to be GLBs. I suspect this is the problem you are running into. It may be that some option is needed in the 3D tile loader to preserve the glb buffer for those cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants