Can anyone please tell me, does the GLTF 2 standard provide for multiple bin files for one GLTF? I want to have one GLTF file with many bin files for each model on scene. Those models will be very complex and I need to load some of them on scene. And then load another bin files with models by necessity. I want to use this behavior in my three.js script.
From a spec perspective, multiple bins are allowed. I’ll let @donmccurdy reply if three.js loader will handle this. If it doesn’t, you can try using the glTF loader from Babylon.js also.
Can you use multiple gltf/glb assets for different models?
The glTF format, and the three.js loader implementation, do support any number
.bin files for a single glTF. By default three.js will load all of the
.bin resources it needs to render the scene, and doesn’t do anything particularly fancy about lazy-loading them. But you can customize the loading pattern if you want to grab specific meshes first.
I created a simple authoring example here, in the “partition” command. For example:
gltf-transform partition input.glb output.gltf --meshes Table,Chair,Bench
… will put the vertex data for each of the three named meshes into a separate
.bin file for the output glTF, giving four total files:
Thank you a lot! I tried to use gLTF-transform with the partition command, but the effect I wanted was not. One .bin file was created. Maybe because I’m using Yarn instead of npm… Does this command work for you, is .bin being split into several parts? Can you, if not difficult, send a screenshot with the worked out command and files, please?
I want to try different paths for loading models. And I don’t know yet how best to do it in my case. I will have one scene and up to 100 complex models that can be included and excluded from the scene. Therefore, I need a way to quickly load models on demand. GLB format stores in addition to the model data about the scene, light, camera and other things
The command I shared above is the correct one. It works in both Yarn and NPM. It does require the names of each mesh you want to split as arguments, if you don’t know these you will have to find them with
gltf-transform inspect model.glb. It also requires that the output be a
.gltf and not a
.glb. If you’re having trouble splitting a particular model you may need to share the model or file a bug.
I want to try different paths for loading models. And I don’t know yet how best to do it in my case. I will have one scene and up to 100 complex models that can be included and excluded from the scene.
A common way to handle this would be to have a list of
.glb files (JSON or plaintext, perhaps?) and metadata about when to load them. Your application can load as many
.glb files as it needs to, whenever it chooses.
Hello again! Thanks a lot for last answers.
I have got another question. If I split model in editor for two gLTF with their .bin. Is it possible to create the one gLTF with those two .bin’s and add information in gLTF about two .bin. How can this be done validly? And another question. Will there be any performance gain if using one gltf and many bin for many complex models. And use lazy loading in GLTFLoader. Or store one scene in gLTF and load models in GLB format (and materials with textures) if necessary?
Yes, similar to the
gltf-transform partition command above, there is a
gltf-transform merge command that will keep the original buffer structure if you include the
--partition flag. The structure of the buffer files will change a bit, but the contents of the two scenes remains separate. For example:
gltf-transform merge a.gltf b.gltf output.gltf --partition
Will there be any performance gain if using one gltf and many bin for many complex models. And use lazy loading in GLTFLoader.
There could be additional network latency when making more requests, but this is worth it if it allows you to wait and only download large files when you need them. So it depends on your needs.
Or store one scene in gLTF and load models in GLB format (and materials with textures) if necessary?
I don’t think I understand this last question, sorry!