KhronosGroup / glTF

glTF – Runtime 3D Asset Delivery
Other
7.16k stars 1.14k forks source link

Need more information on properly extracting TEXCOORD_0 from compressed data. #2108

Open monoto opened 2 years ago

monoto commented 2 years ago

I am having trouble with this exported GLFT model with Draco Compression and your document is not helping. The UV coordinate came out all wrong. There are 3 primitives each pointing to a different BufferView.

"meshes": [
    {
      "primitives": [
        {
          "attributes": {
            "TEXCOORD_0": 1,
            "NORMAL": 2,
            "TANGENT": 3,
            "POSITION": 4
          },
          "indices": 0,
          "material": 0,
          "mode": 4,
          "extensions": {
            "KHR_draco_mesh_compression": {
              "bufferView": 0,
              "attributes": {
                "TEXCOORD_0": 0,
                "NORMAL": 1,
                "TANGENT": 2,
                "POSITION": 3
              }
            }
          }
        }
      ],
      "name": "LanternPole_Body"
    },
    {
      "primitives": [
        {
          "attributes": {
            "TEXCOORD_0": 6,
            "NORMAL": 7,
            "TANGENT": 8,
            "POSITION": 9
          },
          "indices": 5,
          "material": 0,
          "mode": 4,
          "extensions": {
            "KHR_draco_mesh_compression": {
              "bufferView": 1,
              "attributes": {
                "TEXCOORD_0": 0,
                "NORMAL": 1,
                "TANGENT": 2,
                "POSITION": 3
              }
            }
          }
        }
      ],
      "name": "LanternPole_Chain"
    },
    {
      "primitives": [
        {
          "attributes": {
            "TEXCOORD_0": 11,
            "NORMAL": 12,
            "TANGENT": 13,
            "POSITION": 14
          },
          "indices": 10,
          "material": 0,
          "mode": 4,
          "extensions": {
            "KHR_draco_mesh_compression": {
              "bufferView": 2,
              "attributes": {
                "TEXCOORD_0": 0,
                "NORMAL": 1,
                "TANGENT": 2,
                "POSITION": 3
              }
            }
          }
        }
      ],
      "name": "LanternPole_Lantern"
    }
  ],

My code to iterate over primitives to extract geometry:

for (var k=0; k<mesh.primitives_count; k++)
{
  var prm = mesh.getPrimitive(k);
  var mod = prm.type;
  var mat = prm.getMaterial();
  var indAccessor = prm.getIndices();
  var indCount = indAccessor.count;
  var indOffset = indAccessor.offset;
  var ibView = indAccessor.getBufferView();
  if (prm.has_draco_mesh_compression)
  {
      var draco = prm.getDraco();
      ibView = draco.getBufferView();
  }
var viewBuf = dt.fetchedBuffer[ibView.index];
var ibuf = viewBuf.slice(ibView.offset, ibView.offset + ibView.size);

var dracoCallback = function(materialIndex) {
    return function( bufferGeometry ) {
        // handle geometry
        };
};

dracoLoader.decodeDracoFile(ibuf, dracoCallback( profile.materialIndex ));
}

Without Draco, the model looks like: goodDraco With Draco: badDraco

Looking into BufferGeometry that decodeDracoFile spit out, it contains correct number of float32s and each between [0, 1].
Not sure what the problem is.
Do I still need to get the UV from attributes and ignore what comes out of the BufferView?

Since the indices and positions seem to be correctly extracted from bufferView. why are uvs the exception?

donmccurdy commented 2 years ago

@monoto it doesn't seem like the part of your code setting the vertex attribute is included in the snippet above (around the comment // handle geometry), so I can't quite tell what's going wrong. It's also possible that the API of the Draco library has changed a bit, which would be outside the scope of the glTF specification and perhaps better addressed with an issue on the Draco library's repository.

In case it's helpful, here's some of my own code implementing Draco decoding in gltf-transform: