Draco compression for lines?

CesiumJS
1

1. A concise explanation of the problem you’re experiencing.

We have a GLTF model with triangle and line primitives. When we compress using Draco from gltf-pipeline:2.0, the filesize increases a bit from the original. If we remove the line primitives from GLTF, draco compression works fine and file becomes 10 times smaller.

Is it possible to use Draco compression for other primitives than triangle-meshes?

2. A minimal code example. If you’ve found a bug, this helps us reproduce and repair it.

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

4. The Cesium version you’re using, your operating system and browser.

2

Hi there,

At least currently, Cesium and gltf-pipeline only decode Draco encoded model mesh geometry, so Models and b3dm tilesets. Correct me if I’m wrong, but I don’t believe [glTF 2.0 supports line primitives](http://We’re working on Point Cloud support currently. ).

Outside of Draco with glTF, we’re working on Draco encoded point cloud support currently, and theoretically it would be a good addition to something like 3D Tiles vector tiles which are intended for geometry like polylines.

Thanks,

Gabby

3

I think GLTF 2.0 does have lines, we are even using them and Cesium renders them correctly:
https://github.com/KhronosGroup/glTF/blob/c02fd64e1fc15985d84cbbfacb536709f7c22e28/specification/2.0/schema/mesh.primitive.schema.json#L36

Anways, the Draco compression does not work well with lines. Also, what we have notices is that i3dm files, the instanced tiles, do not work with Draco-compressed GLTF in them.

4

Fair enough. Can you provide the model for testing?

I have a PR opened to fix the i3dm issue, #6673.

5

This PR fixed most of the i3dm issues, but now we are seeing some instances objects appearing with wrong rotation.

6

I re-opened #6673 so make sure we get to the bottom of the rotation issue. jsal11, if you can provide sample data that shows the issue that would be great.

7

I investigated this more and it looks like all our instanced objects are now 90 degrees rotated on z-axis (height direction)… And I also tested that this does -not- have anything to do with Draco compression, at this moment this same 90 degrees offset is there even without this #6673

PR merge. So this might be a false alarm… We will investigate more and let you know.

8

The 90 degree rotation is a result of another recent PR: https://github.com/AnalyticalGraphicsInc/cesium/pull/6632.

Cesium uses a X forward convention while glTF 2.0 uses Z forward, and that PR applies a correction. But perhaps this rotation should not be applied to i3dm tiles which provide their own rotation.

9

This totally explains the errors we are seeing then. We will revert this Z forward PR and try again.

10

By reverting 6632, everything works perfectly! So the actuol i3dm & Draco fix is fine, but this 90 degree PR breaks things.

(and the GLTF with lines remains unsolved still)

11

We just merged the rotation fix into master: https://github.com/AnalyticalGraphicsInc/cesium/pull/6681. Everything should be working properly now.

At the moment Draco only supports triangle meshes and points. Any primitives that use lines are skipped in gltf-pipeline:

See https://github.com/AnalyticalGraphicsInc/gltf-pipeline/blob/2.0/lib/compressDracoMeshes.js#L93-L95

12

i3dm with draco works fine now for us! Thanks!

About the lineprimitives and draco: is there future plans to implement it or is there some hard technical challenge related to it?

13

The algorithm uses face connectivity to optimization compression. I guess lines could be possible but it is a less common use case. This might be a good question to bring up to the Draco team: https://github.com/google/draco.