Due to the change in some projects I have developed a small local tool for the conversion from .obj to .glb (materials are not considered).
Using THREE.OBJLoader I import an .obj and then export it to a .glb using the THREE.GLTFExporter.
This works fine so far.
But I could see that a ~200KB .obj becomes a ~400KB .glb.
If I convert this .obj with Blender I get a ~100KB .glb.
Unfortunately I cannot always reproduce this behaviour. For the most part the threejs exporter is worse than the one from Blender. I have already played with all options of the THREE.GLTFExporter, but could not find any significant changes.
I have a small starting point, but honestly I lack the experience. When I look at the .glb as a JS object, I can see that there are several ArrayBuffers, including an Int8Array and an int32Array. The int32Array has a much smaller size, but when creating the BLOB object for download the int8Array is apparently used.
The glb-JS object also shows me a bytelength of ~400KB, so I am probably wrong with this approach and just misunderstand.
Does anyone have experience with the exporter, or can help me in any other way?
I’m new to this forum, and hope I didn’t do anything wrong, but if I did, my post may be deleted at any time.
I’ve already found out that most of it is due to the “buffer” attribute in the generated .glbs by the GLTFExporter. Here the content is a so-called “data:application/octet-stream;base64”.
The Blender Exporter produces a size of 147116Bytes, whereas I have 414912 Bytes with Three.
I exported as .glb - so it`s set {binary: true}. Otherwise it would export as an .gltf - In my second post I exported as gltf, to get some human readable.
Not really, since without indices every vrtex is copied as many times as there are triangles using it. 5 triangles sharing the vertex would make (5 - 1) * 8 new numbers for positions + normals + uvs, for example. With index, it is only 4 extra numbers
Do you have an idea, how to fix that?
I already took a look into: https://github.com/mrdoob/three.js/issues/15649
and some magic like BufferGeometryUtils.mergeBufferGeometries - But have not been able to take advantage of it.
Is there any chance to load an .obj without destroying the indices?
The thing is that qute often obj indices are not useable in 3js “as is”, and you need to rebuild the index - so they said, fck it, lets drop the indices. And who can blame them ) If you have tight control ovr your obj files, you could go on and use obj indices any way. But if not - that merge thing is the only way to go.
No, sorry i made this unclear.
In the .glb there is no “data:application/octet-stream;base64” - just when using binary: false.
I just made a test with binary false, to get some human readable in threejs and blender, to compare the differences. Wanted to point out, that the “buffer” attribute is much bigger in the threejs export then the one from blender.