# 🐉 Anyone using Draco?

**URL:** <https://discourse.threejs.org/t/anyone-using-draco/3074>\
**Category:** Questions\
**Tags:** draco, compression\
**Created:** [June 9, 2018, 12:39am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074 "2018-06-09T00:39:31Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ben](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/ben/32/1174_2.png) [@ben](https://discourse.threejs.org/u/ben)\
**Post date:** [June 9, 2018, 12:39am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/1 "2018-06-09T00:39:31Z")

</div>

[**Draco**](https://github.com/google/draco): [GitHub - google/draco: Draco is a library for compressing and decompressing 3D geometric meshes and point clouds. It is intended to improve the storage and transmission of 3D graphics.](https://github.com/google/draco)  
Have you had a good/bad experience you could share with the community?

> Draco is a library for compressing and decompressing 3D geometric meshes and point clouds. It is intended to improve the storage and transmission of 3D graphics.

> Draco was designed and built for compression efficiency and speed. The code supports compressing points, connectivity information, texture coordinates, color information, normals, and any other generic attributes associated with geometry. With Draco, applications using 3D graphics can be significantly smaller without compromising visual fidelity. For users, this means apps can now be downloaded faster, 3D graphics in the browser can load quicker, and VR and AR scenes can now be transmitted with a fraction of the bandwidth and rendered quickly.

> Draco is released as C++ source code that can be used to compress 3D graphics as well as C++ and Javascript decoders for the encoded data.

My curiosity, I see WebAssembly being used here.

> **[GitHub - ouyangzhaoxing/drcobj: 使用draco压缩和解压three.js模型文件。(Use draco to...](https://github.com/ouyangzhaoxing/drcobj)**
>
> 使用draco压缩和解压three.js模型文件。(Use draco to compress and decompress the three.js model file.) - GitHub - ouyangzhaoxing/drcobj: 使用draco压缩和解压three.js模型文件。(Use draco to compress and decompress the three.j...

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 9, 2018, 2:05pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/2 "2018-06-09T14:05:08Z")

</div>

I’m using it and I think it’s great. Just one example to illustrate this:

The following model at Sketchfab is very complex. The original `OBJ` file is 186 MB big, the `glTF` version about 41 MB. Although the usage of `glTF` clearly reduces the file size, it’s still bad to load this amount of data over a potential slow internet connection. After applying Draco with default compression level to the asset via [gltf-pipeline](https://github.com/AnalyticalGraphicsInc/gltf-pipeline), the file size is reduced to approx. 5 MB. Of course you have now a higher client-side parsing overhead because of the decoding process but the overall delay is much better than before. Nevertheless, for such big models I would recommend to perform the decompression in a worker. Besides, using a mesh compression algorithm like Draco is more efficient than using a general purpose, lossless compression like zip.

https://sketchfab.com/models/30f43907f7814582b5dacbbadbabbe6d/embed?

> [@ben](#):
>
> My curiosity, I see WebAssembly being used here.

Decompression can be a quite computing intensive task. The official Draco libs allow a decompression via JavaScript or WebAssembly. The latter one is the faster approach.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 9, 2018, 2:13pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/3 "2018-06-09T14:13:14Z")

</div>

For the interested reader or student: One algorithm Draco uses is the so called _Edgebreaker_. The following paper provides the theoretical background behind the implementation:

> **[5e15a672b5435eed5c6b5fb75c8f76f826d1.pdf](https://pdfs.semanticscholar.org/4e68/5e15a672b5435eed5c6b5fb75c8f76f826d1.pdf)**
>
> 160.83 KB

---

<div class="post-metadata">

**Author:** ![ben](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/ben/32/1174_2.png) [@ben](https://discourse.threejs.org/u/ben)\
**Post date:** [June 9, 2018, 2:43pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/4 "2018-06-09T14:43:22Z")

</div>

This is impressive indeed I had not realized this important feature of glTF on reducing file size.

- Are their other pro(s) and con(s) for glTF?
- Because we are in 2018 would you recommend using glTF all the time? or sparingly?
- Does glTF have a known limitation(s)?

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 9, 2018, 2:46pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/5 "2018-06-09T14:46:57Z")

</div>

I thought this thread is about Draco? 😉 Maybe it’s better if we not mix topics.

BTW: Draco can also be used without `glTF`. According to the project’s website, it accepts `OBJ` and `PLY` as input. But apart from that, it’s very elegant to use it in combination with `glTF`.

> **[google/draco](https://github.com/google/draco)**
>
> Draco is a library for compressing and decompressing 3D geometric meshes and point clouds. It is intended to improve the storage and transmission of 3D graphics.

---

<div class="post-metadata">

**Author:** ![ben](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/ben/32/1174_2.png) [@ben](https://discourse.threejs.org/u/ben)\
**Post date:** [June 9, 2018, 4:38pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/6 "2018-06-09T16:38:59Z")

</div>

your right, my bad  
a topic for another time

---

<div class="post-metadata">

**Author:** ![looeee](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/looeee/32/59_2.png) [@looeee](https://discourse.threejs.org/u/looeee)\
**Post date:** [June 9, 2018, 7:07pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/7 "2018-06-09T19:07:31Z")

</div>

> [@Mugen87](#):
>
> the glTF version about 41 MB…  
> After applying Draco with default compression level to the asset via [gltf-pipeline](https://github.com/AnalyticalGraphicsInc/gltf-pipeline), the file size is reduced to approx. 5 MB.

😱 😱

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 9, 2018, 7:55pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/8 "2018-06-09T19:55:43Z")

</div>

Yeah, it’s crazy 😆

---

<div class="post-metadata">

**Author:** ![Fyrestar](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/fyrestar/32/52793_2.png) [@Fyrestar](https://discourse.threejs.org/u/Fyrestar)\
**Post date:** [June 9, 2018, 8:26pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/9 "2018-06-09T20:26:40Z")

</div>

Isn’t it a base64 string for the buffers? I mean i got some models in text format for example ~5mb turning into ~120kb models in binary. The algorithm looks interesting, a lot 3D scan models could be optimized/reduced in advance too, a lot faces don’t contribute to any detail, i also noticed this in a lot scans on sketchfab.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 10, 2018, 8:28am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/10 "2018-06-10T08:28:40Z")

</div>

> [@Fyrestar](#):
>
> Isn’t it a base64 string for the buffers?

I’m not sure I understand. What are you referring to?

---

<div class="post-metadata">

**Author:** ![Fyrestar](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/fyrestar/32/52793_2.png) [@Fyrestar](https://discourse.threejs.org/u/Fyrestar)\
**Post date:** [June 10, 2018, 10:16am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/11 "2018-06-10T10:16:23Z")

</div>

I meant glTF (without draco) resulting in 41 MB, looking into the loader it’s using a base64 string for the buffers, that’s a huge difference from having a binary buffer, but quite better than a text format of course. But maybe i missed something and you already used binary buffers.

---

<div class="post-metadata">

**Author:** ![donmccurdy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/donmccurdy/32/33209_2.png) [@donmccurdy](https://discourse.threejs.org/u/donmccurdy)\
**Post date:** [June 10, 2018, 11:34am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/12 "2018-06-10T11:34:29Z")

</div>

glTF has two variants: `.gltf` and `.glb`. Typically `.gltf` will reference separate `.bin` and texture files, whereas `.glb` has everything embedded as binary (not base64) data. It’s _possible_ to embed everything into `.gltf` too, and that’s when you end up with base64 strings in the JSON that increase filesize by ~30%, so that’s unusual and inefficient.

Generally, just use the `.glb` variant (or pack it with [https://glb-packer.glitch.me/](https://glb-packer.glitch.me/)) and you’ll avoid all of that confusion. 🙂

Using Draco alone is a good option if you just need geometry. If you need materials, textures, and animation, then glTF+Draco gives the best of both worlds.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 14, 2018, 12:00pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/13 "2018-06-14T12:00:53Z")

</div>

BTW: Here is the mentioned César model as a `three.js` demo:

[https://cdn.rawgit.com/mugen87/draco-showcase/2ad92db87f5f12d6cf2af8ea58574e2f37e308a0/index.html](https://cdn.rawgit.com/mugen87/draco-showcase/2ad92db87f5f12d6cf2af8ea58574e2f37e308a0/index.html)

It’s interesting to have a look at the network tab of your browser’s dev tools.

---

<div class="post-metadata">

**Author:** ![Fyrestar](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/fyrestar/32/52793_2.png) [@Fyrestar](https://discourse.threejs.org/u/Fyrestar)\
**Post date:** [June 14, 2018, 3:41pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/14 "2018-06-14T15:41:49Z")

</div>

The compression size of draco is impressive, the decompression time is very long but ok for this file size. But i personally don’t see a use of it outside enormous models like from 3D scans. It took ~7 seconds on my powerful desktop machine, on weak mobile devices it will take much longer. At least i don’t see a use for games or the usual apps, but those for 3D scans of course.

At a certain triangle count an average device starts struggle rendering it anyway. This César model for example could be optimized that it would basically look the same, but only around 1-2 MB in uncompressed binary. Besides a lot unecessary faces the flat details on the fabric or armor will look even better/smoother baked in normals maps. The distortion of scans creates a lot wrong details.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 14, 2018, 5:42pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/15 "2018-06-14T17:42:34Z")

</div>

You can always optimize meshes, independently of compression. The demo should just show the difference between the original OBJ file (more or less raw geometry data) and a compressed glTF asset.

> [@Fyrestar](#):
>
> It took ~7 seconds on my powerful desktop machine, on weak mobile devices it will take much longer.

Interesting. The pure decompression takes only ca. 2 seconds on my four years old iMac with latest Chrome.

---

<div class="post-metadata">

**Author:** ![Fyrestar](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/fyrestar/32/52793_2.png) [@Fyrestar](https://discourse.threejs.org/u/Fyrestar)\
**Post date:** [June 14, 2018, 6:20pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/16 "2018-06-14T18:20:00Z")

</div>

Yes, and i agree with draco doing a great job, i just don’t see a reason to generally use it since it’s really rather relevant for big files. For the web one should always optimize the models first before only trying to compress it as much as possible, since triangle count for rendering is the more important point if it’s about games and such.

I really like draco and will integrate it in my own fromat as well.

By optimizing scan models, baking details etc. mobile devices won’t struggle or die rendering it at the same quality. But that only applies to just rendering it in it’s entireness, if there is a LOD rendering technique the hardware limit can be avoided, though it would require to store additional data which i think draco doesn’t handle.

I’ve got a i7 5930k with 6x3501 MHz, 32 DDR4 RAM and TitanX with latest Chrome

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 15, 2018, 8:31am UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/17 "2018-06-15T08:31:48Z")

</div>

> [@Fyrestar](#):
>
> i just don’t see a reason to generally use it since it’s really rather relevant for big files.

Compressing media data is used in many areas like pictures, video or audio. Nobody would come up with the idea to integrate uncompressed image data in a website (established formats like JPEG, PNG or GIF all use compression per default). From my point of view, there is no reason why 3D model data should be a special case. Even small files benefit from compression since the total delay (load+parse/decode) is in general smaller than loading uncompressed data.

---

<div class="post-metadata">

**Author:** ![Fyrestar](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/fyrestar/32/52793_2.png) [@Fyrestar](https://discourse.threejs.org/u/Fyrestar)\
**Post date:** [June 15, 2018, 2:31pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/18 "2018-06-15T14:31:12Z")

</div>

Of course compression is relevant, but for average buffers other compression methods / faster ones suffice as well. And as said, optimizing the actual content since it’s the most important part that will reduce the file size as well.

---

<div class="post-metadata">

**Author:** ![pailhead](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/pailhead/32/85_2.png) [@pailhead](https://discourse.threejs.org/u/pailhead)\
**Post date:** [June 15, 2018, 6:53pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/19 "2018-06-15T18:53:26Z")

</div>

how does it generally compare to gzipped json? Why does json gzip better than a binary mesh? On a high level, it’s a different compression algorithm, while draco is specifically aimed for spatial data?

Theoretically, if draco decoder was part of the browser, there would be no question which format to use. But currently, since browsers can unzip natively, zipped json might win when both size and decoding time are considered?

---

<div class="post-metadata">

**Author:** ![titansoftime](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/titansoftime/32/1044_2.png) [@titansoftime](https://discourse.threejs.org/u/titansoftime)\
**Post date:** [January 21, 2019, 6:50pm UTC](https://discourse.threejs.org/t/anyone-using-draco/3074/21 "2019-01-21T18:50:17Z")

</div>

I literally just started testing with DRACO today for my non-skinned meshes. The filesize reduction is absolutely nuts. 171kb =\> 9kb for example.

What I still need to benchmark is how much overhead the decompression adds and see if the faster download times are worth it. Will do that sometime this week.

[Next page](https://discourse.threejs.org/t/anyone-using-draco/3074.md?page=2)