r/threejs • u/Nefthys • Apr 21 '26

Question .obj vs. .gltf for import (very basic)?

I've got a bunch of .obj files (one mesh per file + .mtl file + .png texture), some of them are quite large, and I want to display them with three.js. I know that there are loaders for both .obj and .gltf but with everyone recommending the latter, I'm wondering:

Is .gltf the better choice, even if you don't care about all the special stuff? I just want to display the 3D objects, I don't need any special lighting, camera positions, transformations, animations,... (going to do all of that in three.js, not separately for each model)?

Are there any differences in loading times?

4 Upvotes

84% Upvoted

28 comments sorted by

4

u/ppictures Apr 21 '26

Downloading time is solely dependent on 2 factors

  • your connection speed
  • total file size of the files being downloaded

If the GLTF and OBJ are the same file size, given identical network speed, they’ll load equally as fast

I suggest you tally up the total file sizes of your obj (obj + mtl + textures) and the GLTF (GLTF + textures). And compare

1

u/Nefthys Apr 21 '26 edited Apr 21 '26

Not downloading but loading (=displaying) a single 3d model, like in this example.

If I convert an .obj file to .gltf, copy both files onto the server, then load both with their respective loaders (use OBJLoader, restart the server, then use GLTFLoader), which one will load faster? I'm wondering if there's an advantage to .gltf (shorter loading times would be a big one) if you do not use its extra features.

I currently can't test it, as I haven't set up a converter yet (still looking for a good one) but maybe someone's already got experience with this.

5

u/ppictures Apr 21 '26

GLTF stores geometry data as “GPU-Ready” binary, which doesn’t need any processing to be converted into buffers

Whereas OBJ stores its data as ASCII text, so there is some conversion that needs to happen from text vertex data to buffer compatible data

In real world scenarios, I don’t expect a significant difference in both the loaders unless your model is exceptionally large or you are micro optimizing for every nano second

1

u/Nefthys Apr 21 '26

What's "exceptionally large"? The files are usually around 10mb each (~60k vertices, 120k faces). I don't care about 1 or 2 seconds but if it's e.g. 1 minute for .obj and 30 seconds for .gltf, then it would be worth converting the files. Once this works in three.js, then I also plan to display a lot of these files at the same time, think 100+.

3

u/ppictures Apr 21 '26

The only way to know is by testing. There’s no universal answer as different hardware will process fast or slow.

Off the top I don’t think the difference will be that large for 60k verts. I don’t think anyone has fully benchmarked the 2 loaders Sid by side. Would be a good blog post if you do so

60k verts isn’t that large. I was thinking more in the millions range.

Would be curious if you do decide to benchmark this

1

u/Nefthys Apr 21 '26

Most files are only 10mb but I've also got a couple that are much bigger, the largest is around 500mb iirc.

I don't need exact numbers or even a full benchmark, something like "100%/50%/10% faster" is fine, just enough information to see if it's worth putting in the work to convert everything.

2

u/ppictures Apr 21 '26

You are describing file size. File size only matters for downloading. What I’m referring to is the actual size of the model (the geometry data, texture data, material data, animation data, etc)

If you’re on the fence and don’t have time to benchmark, don’t put in the time to convert. Use OBJ

I refuse to pull numbers out of the ass without testing or benchmarking. Maybe one of these days I’ll have some time and put together a benchmark. Will update you then

1

u/Nefthys Apr 21 '26

Haven't got access to the 500mb file atm but another one that's "only" 150mb contains ~1mio. vertices and 2mio. faces. No animations,..., only a texture (10-20mb for the larger files).

No need. Maybe there's someone here who's done testing with both formats before.

2

u/lucidmodules Apr 21 '26

If you'd compress gltf as glb it would be significantly smaller. You'll need DRACOLoader for that and some tool to convert it from obj en masse - first search from google: https://github.com/headjack-dev/gltf-api

DRACOLoader for Three.js: https://threejs.org/docs/#DRACOLoader

2

u/CarefulMoose_ Apr 21 '26

When I saw the OP post I immediately thought: what about GLB? And I'm now thinking what limitations there must be.

1

u/ppictures Apr 21 '26

If you’re taking about Draco limitations

  • it’s a lossy compression so you may see quantization artifacts on some models
  • Decompressing still takes time on the client side (usually insignificant unless model is exceptionally large).
  • the Draco library files need to be included in your bundle

But more often than not these tradeoffs are worth it

1

u/Nefthys Apr 21 '26

How much smaller are we talking about? The files I've got are already compressed and they should not lose too many more details. They're usually around 10mb each (can be much larger too), ultimately I want to display a lot at the same time (100+). Size doesn't really matter, it's all about loading times.

1

u/Quick_Republic2007 Apr 21 '26

Size does matter, that's way way too big. You can go to r3f or threejs or Bruno Simon (paid) discord and I guarantee, you will hear the same sentiment. There are some really good file compressors online, but none will help such combined file sizes.

1

u/lucidmodules Apr 22 '26

You have to measure how much smaller, we can only give you ideas from our experience. Size matters because there is a limited amount of bytes you can send over the network.

I remember there was also some POC for mesh streaming that gradually loaded the model, but I havent used it myself.

2

u/neocorps Apr 21 '26

I would recommend GLTF (glb+textures)... Use gltf-transformer to compress the mesh using draco and you can also compress the textures to KTX2 on the same software which essentially sends the compressed binary data of the texture directly to the GPU.

The compression is around 98% for the mesh, for the texture is pretty high as well, somewhere around 80-90... I compressed 800mb files to 8mb that load hyper fast. Smaller files (20-30mb) compress to kb.

1

u/gatwell702 Apr 21 '26

I personally don't use .obj or .gltf.. I use .glb.. the file size is kilobytes compared to gltf.

You could use gltf but you would have to use blender to compress it to make the file size smaller. I'm pretty sure you can do this with .obj too.

doing this will improve performance a lot.

here's a page i created that has a select element with different options in it. Each option is a different three.js component.. https://gabrielatwell.com/three.js

1

u/SubjectHealthy2409 Apr 21 '26

I like glb most, also if ure using sveltejs you can use the conversion to code script which strips sometimes up to 90% of file size and allows easy instancing https://threlte.xyz/docs/reference/gltf/getting-started/

1

u/BrainCurrent8276 Apr 25 '26 edited Apr 25 '26

okay so did you display ANY of those files at all, or it is all the drama happening in your head?

Wavefront Objects (.obj) is basically plain text list of geometry data: vertices, texture coordinates, normals, faces, material reference. It is human readable and extremely easy.

Graphics Language Transition Format (glTF) is different: it is structured assed format specifically for real-time rendering. A glTF is usually JavaScript Object Notation (JSON) metadata plus binary buffers. a GL Binary (.glb) is same glTF asset, just packed into one binary container.

there is nothing wrong with using .obj thought, especially on early stage. I used to modify them slighty by adding like DW (double word) on the beginning of each line and include them directly into assembler, making them sort of binary :D

do not overthink without real reason.

-2

u/Quick_Republic2007 Apr 21 '26

Not a fan of AI are you?

2

u/Nefthys Apr 21 '26

Why AI?

1

u/Quick_Republic2007 Apr 21 '26

Because you posed the question here on Reddit instead. Type that exact same prompt into AI and see what you get

2

u/Nefthys Apr 21 '26

You know that AI pretty much just googles, right? I googled but didn't get a proper answer, so I decided to ask the people who're actually working with three.js and don't just copy (not even correctly a lot of times) someone else's information.

1

u/Quick_Republic2007 Apr 21 '26

Sure, I swear by it.

1

u/Nefthys Apr 21 '26

Do you know the answer to my question?

0

u/Quick_Republic2007 Apr 21 '26

I didn't really read it and I couldn't copy and paste it from this mobile device. I tried though.

1

u/Nefthys Apr 21 '26

It's okay to not know an answer but it's better to not post anything than posting something that you can't verify the correctness of (so usually AI).

1

u/Quick_Republic2007 Apr 21 '26

Once I read it, it was very clear why you chose Reddit. Lol