I’ve invested several days time to learn and build blender scripts to convert *.obj files to *.glb because we will be passing them around online for use by three.js applications and want to minimize bandwidth usage. The obvious assumption is that the glb format would be more compact.
However, one of the first files I’ve used for testing grows larger when converted to .glb (25,146,576 bytes), and even larger as gltf (33,529,922 bytes). The original obj is 11,055,741 bytes; it contains 149,677 vertices and 299,350 faces. That’s it; no animations or materials, just a mesh. And the mesh is all I need to store in the file because we just color and light it later.
In blender, I clear everything with bpy.ops.wm.read_factory_settings(use_empty=True) to get rid of its camera, cube, lighting, etc. Then I import the object file and export as gltf or glb. The gltf file contains a single scene, but seems to have created a material, and has 3 accessors into the buffer: 10,776,600 bytes of 898,050 VEC3s, another 10,776,600 bytes of 898,050 VEC3s, and 3,592,200 bytes of SCALARs.
Is there anything I can do to reduce this bloat? It would be much more efficient for me to stick with .OBJ files, which is counter-intuitive since everything I read makes me believe gltf was designed for this purpose.
Could you share an example of such a file (.obj or .blend)?
Using .glb will certainly be more efficient than using a .gltf with resources embedded in it. A .gltf with separated resources in external files is comparable to .glb.
It would also be useful to know the number of vertices in the OBJ before vs. the glTF after. There are various things that can cause the number of vertices to increase with a roundtrip through a tool.
Uploading obj files does not appear to be allowed in this forum, only known image formats. So I put them online where anyone can download them, but the forum won’t allow me to insert links either. If you look at my profile, and click the link to “my website”, you can download the files I’ve been playing with. All have the same name with different extensions, so it should be self explanatory which is .obj, .glb, gltf, etc. If I’m allowed to use the link function in the future, I’ll add links to this thread.
It does appear that the mesh went from ~150k vertices to ~900k, but I could easily be making unwarranted assumptions in my reading of the xml.
When I export the scene back out as obj, I get a 25,535,773 byte file with 149,677 vertices, 299,258 vertex normals (that were not in the original), and 299,350 faces. So it does not seem to have added vertices, but it did save out more information it had calculated about them.
The import/export libraries for blender’s gltf support offer many options to tailor the output file. I was only using defaults at the time of asking the question, but I tested the following options today:
bpy.ops.export_scene.gltf(…, export_colors=False) does not affect the file size. bpy.ops.export_scene.gltf(…, export_materials=False) does not affect the file size. bpy.ops.export_scene.gltf(…, export_normals=False) greatly affects the file size.
So one of the buffers I was able to get rid of was normals. I am setting all three of the above exports to False because I don’t need any of their data. This creates a 14,369,604 byte .glb file, which is the smallest gltf size so far, but still not an improvement on the original .obj.
It does appear that the mesh went from ~150k vertices to ~900k, but I could easily be making unwarranted assumptions in my reading of the xml.
Yes, that’s correct. This is not necessarily a bug, but it can happen when exporting models with hard normals. If you have the model open in Blender, and are seeing the 900K vertices there, you can fix it:
Select the mesh in Blender, Tab to enter Edit mode.
F3 then search Merge by distance. Should reduce back to 150K vertices.
F3 then search Shade Smooth.
Export to GLB with Normals enabled for a smooth mesh, or disabled for hard edges.
With those steps I get an export of 5.4 MB for GLB, compared to 11MB for OBJ. Running the model through gltfpack brings it down a bit further to 4.8 MB for GLB. Running the model through Draco compression with glTF-Pipeline brings it down further to just 0.5 MB. With the Draco option you would need to configure THREE.GLTFLoader a bit differently, as described in the three.js docs.