Using TextureLoader() with a draco compressed GLTF causes an error

Questions
1

Hey guys, I’m loading a DRACO compressed GLTF, which works great, it’s cut my file size down considerably.

Inside the loader, I apply a texture to one mesh, this works with a non-compressed GLTF of the same file.
I’m just using the usual TextureLoader() like so:

const texture = new THREE.TextureLoader().load(
            this.settings.screenshot
          );

          texture.flipY = false;
          texture.wrapT = THREE.RepeatWrapping;
          texture.repeat.x = 1;
          texture.repeat.y =
            this.deviceHeight / this.settings.screenshotHeight;
          this.texture = texture;

          const screenshot = new THREE.MeshBasicMaterial({
            map: texture,
          });
          o.material = screenshot;

Again, this works well with a non-compressed GLTF but I’m getting this recurring warning (on each frame update)

This warning fires once

[.WebGL-0x7fd5d87e3200]GL ERROR :GL_INVALID_VALUE : glVertexAttribPointer: size GL_INVALID_VALUE

This one recurres on frame update

[.WebGL-0x7fd5d87e3200]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attached to enabled attrib 1 : no buffer

The texture also does not show. Is there another step I should be doing in order for this to work? Can draco handle textures loaded in this way?

2

Does the error still appear if you leave out the TextureLoader code? Draco shouldn’t be affecting textures at all. Does the model appear correctly in https://gltf-viewer.donmccurdy.com/?

3

Hey man,

Nah the screen actually isn’t rendering there at all

Here’s the files if that helps at all. Maybe I should try output it again? I just used the compress setting in Blender 2.8 exporter

Standard GLTF
laptop_standard.glb (2.5 MB)

Compressed
laptop_draco.glb (469.3 KB)

To answer you question, the error disappears when I use a standard material for the screen (that mesh). Threejs renders the model correctly on my end though, not sure why it doesn’t show in your uploader?

One other thing, the image texture by its nature is not power of two

4

Looks like there’s a bug in Blender’s draco compression exports, you may need to file something on https://github.com/KhronosGroup/glTF-Blender-IO. If you export normally (without Draco) and then compress it with glTF-Pipeline instead, you’ll get a small (and working) file:

laptop_draco_2.glb (183.8 KB)

1 Like
5

Legend, thanks so much. I did see glTF-Pipeline mentioned in different threads but I should have taken a closer look. All the best to you

6

I’m sure there’s a good reason for this, but why isn’t Draco compression the defacto for glTF on the web? Does it have drawbacks I’m not aware of?

7

In one sense it is (a lot of people use it) but it’s not necessarily the default output of every tool.

I’m guessing about why that is, but maybe a few things:

  1. A lot of 3D models files are texture-heavy rather than geometry-heavy. Draco only compresses meshes, so you need other things (see: Basis, KTX) for textures.
  2. The Draco decoder is large for a web library, and takes a bit of time to decode data. For something geometry-heavy that often pays off, but not necessarily for smaller models.
  3. It’s lossy, and less portable (WebGL engines all implement it, but editing tools and native tools may not). So you may want to think of it as one-way compression for your final assets, because you’ll have a hard time “undoing” Draco compression.
  4. There are two alternatives: quantization, and meshopt compression. three.js supports the first, but not yet the second.
1 Like