Break down GLB to reuse material

Questions
1

Currently working on an online 3D web editor, allowing users to save and upload directly through the browser.

While evaluating server efficiency and user experience, we’re considering two options:

1. Users can upload a GLB file to the server and download assets as needed. If a small change is made, a new GLB file would be uploaded. For instance, if a user downloads “tree.glb” from the server, makes edits, and saves, we would then have a “newTree.glb” on the server.

2. When a user wants to save their project, we could break down all GLB files, checking if the “material of the tree” has already been uploaded to the server. Subsequently, the entire project’s JSON, transformed from GLB but excluding any duplicated materials, would be sent to the server.

We’re facing a bit of debate between these two options. The first might lead to extensive DB storage usage. The second could make the system more complex and, by transporting non-binary files like GLTF or using Json.stringify(babylon.object), it might also increase network load.

Would breaking down .glb files to reuse materials be efficient, or could it worsen network performance and negatively impact the user experience? Any insights or suggestions for a saving logic in an online 3D web editor would be greatly appreciated.

2

I’m not sure how complex you want to get, but maybe you can store loose glTF files instead of a GLB? Or store GLBs with references to separate textures. The original purpose of a GLB is to reduce one additional request by combining the JSON with the geometry bin so that they can be zipped together on the server. Textures (jpg/png) should not be zipped since they are already compressed and would cost time for no benefit. Doing it this way has the benefit of not having to change the glTF loader at all since it already allows this type of referencing from a GLB.

1 Like
4

Ah, I see. I now understand that managing individual .png (material) files separately might not be very effective. Given that, which would you recommend: saving customized GLTF as a JSON with the Babylon.js object type, or sticking to the standard GLTF or GLB format?

Or, are there any custom GLTF loader that can hadle these things easily?

5

I’m not sure what you mean by this. What kind of custom things do you need besides what’s in the glTF?

The glTF loader has many extensibility points that allows changes to existing behavior or add additional behavior (e.g., support a new glTF extension). Here is an article I wrote a while back about it. Depending on what you want to do, this might work?

6

I want textures to be linked to S3 buckets, textures inside projects will overlapped. It may reduce my S3 storage right?

It may be the solution if I find a right solution in gltf extensions.:thinking:

Thanks for answer! I think I’ll need time to digging on it

7

I don’t know what S3 buckets are. It looks like they are AWS things. Anyways, generally speaking, if you point to the same url for the same texture, it should reduce storage.

I’m not sure what glTF extension you are looking for and I’m not sure you need one. What are you trying to do with a custom glTF extension? (Note that there is a difference between a glTF extension and a Babylon.js glTF loader extension.)

8

does gltf load image file from server, just adding url?
I mean, in GLTF file,

images: {
“https://myImage.server.image1.png”
“https://myImage.server.image2.png”
}

Now, I built my own custom GLTF loader, which reads image files url and fetch it from server. It works! and also I succeed in saving 3D asset storage, but, it looks messy… so now, I’m trying to simplifying system. I thought one could be GLTF extensions