Err:
Playground:
Manually patched the KHR_draco_mesh_compression class and removed the check:
The code was introduced here:
I’m still investigating. Draco has a specific API for dealing with triangle strips that we are not calling, so I’m not sure if it is actually working or not.
After some research, I’m really confused.
The API I was referring to earlier is for converting triangles to a strip, so it’s not relevant.
Draco seems to not support triangle strips: How to encode triangle strips? · Issue #423 · google/draco (github.com)
But yet, KHR_draco_mesh_compression extension explicitly states it can be triangle strips.
AFAICT it is not possible to know if the encoded data in Draco is a triangle strip or not. Thus, the glTF primitive mode must be included to know whether the payload is triangles or a triangle strip. This is weird as the intention is that the Draco payload can be standalone. It seems like the Draco payload is actually triangles, but being used as (almost like being casted to) a triangle strip afterwards.
@kzhsw Do you know how this Draco data got encoded?
A quick search over glTF-Sample-Viewer, glTF-Transform, and three.js shows that the GetTriangleStripsFromMesh is not used in those libraries. Not sure if it’s the correct api to use.
I pinged someone from Khronos who might know what is going on. Until then, I can simply remove this check, but I don’t know if this is the right thing to do. Is this something you need quickly?
1 Like
Would possibly need this in next one or two weeks, hope this get confirmed and landed soon.
I put the PR so that it’s ready to go, but I won’t merge it until I hear back.
1 Like
I haven’t heard back, so I filed an issue on glTF GitHub. Hopefully this will get someone to respond.
1 Like
It seems no one knows, so I guess we can just merge it and see what happens.
1 Like