Hi, I’m trying to use use extension CESIUM_primitive_outline with Draco in CesiumJS 103, but get the following error on load:
I’ve used gltf-pipeline to create the Draco compressed file:
$ gltf-pipeline -i test13.glb -o test13c.glb -b -d
Some remarks:
I’ve included the compressed model.
test13c.glb (4.2 MB)
Anyone have some suggestion about this issue?
If I understood that correctly, then you have a version of the given GLB that uses the CESIUM_primitive_outline, and wanted to compress this with Draco, using the gltf-pipeline.
And it seems like the CESIUM_primitive_outline extension is not (yet) taken into account in the gltf-pipeline: The CESIUM_primitive_outline extension defines a set of indices that are supposed to represent the edges for outline rendering. And Draco changes the topology and structure of the mesh. This means that these indices basically become “invalid” for the new, Draco-compressed structure.
The gltf-pipeline may have to update the indices, so that they match the new, Draco-compressed structure, but I don’t know how what the effort could be for implementing that. I opened Draco compression probably breaks `CESIUM_primitive_outline` extension · Issue #630 · CesiumGS/gltf-pipeline · GitHub, to at least keep track of that.
(Just a short heads-up: It seems that --draco.compressionLevel=0, as suggested in index order not preserved · Issue #579 · CesiumGS/gltf-pipeline · GitHub , causes Draco to keep the index order - this might be a workaround, but I haven’t tried it out yet)
Ok I tried with -draco.compressionLevel 0, I see the file is less compressed but same error in CesiumJS (gltf-pipeline version 3.0.5)
I had a closer look at this, with some details in the linked issue, and a possible fix in Basic CESIUM_primitive_outline support by javagl · Pull Request #631 · CesiumGS/gltf-pipeline · GitHub . If you can attach the original model that you used (with the outline extension, but without Draco), then I can check whether the extension now survives the Draco compression.
ok great! Original model with outlines without Draco: https://bertt.github.io/cesium_3dtiles_samples/samples/outline/delaware/test13.glb
Apparently, doing a full Draco compression does affect the indices. I tested it with a simple model earlier, and there, the indices remained the same. But with the attached model, they are modified. (It might magically depend on the complexity of the model…? And … the new indices appear to be stored something that resembles a sparse accessor (but is not) … I’d have to read more here…)
However…
The original model has ~46.2 MB, and a small segment of it looks like this:
With compressionLevel=0, the model has ~16.8 MB, and looks like this:
One can see that the topology is right, but with the lines are bit squiggly due to the quantization. The default quantiztation for the positions is 11 bits (the README currently says 14, but it’s 11 - that has to be fixed).
So I also tried it with 14 quantization bits for the positions, and this results in ~18 MB, looking like this:
At this perspective, that’s hardly distinguishable from the original one.
With compressionLevel=1, it goes down to ~13.1 MB, but … the indices are messed up:
But… this might not be toooo surprising. (In fact, I found it surprising that the indices did not seem to change when I tested it with a simpler model…)
Of course, the linked PR is only a slight improvement, compared a full re-write of the (changed) indices (but… it only took a few minutes to implement it, so that’s OK I guess). But when setting compressionLevel=0, it should now be possible to transport the outline extension through gltf-pipeline Draco compression, and this still reduces the size considerably.
Attached is the one with compressionLevel=0, and quantizePositionBits=14.
I can confirm with the code in the PR and compressionLevel =0 and quantizePositionBits=14 it works 
https://bertt.github.io/cesium_3dtiles_samples/samples/delaware/
