Interpretation of bytestride parameters about unitygltf

[stevenvergenz]

I think you're just looking at the wrong part of the spec. From the byte stride definition:

The stride, in bytes, between vertex attributes. When this is not defined, data is tightly packed. When two or more accessors use the same bufferView, this field must be defined. Minimum value: 4.

"Between" attributes suggests to me that it does not include the size of the component, implying that a byteStride of 0 would also indicate densely-packed data, but the spec authors prefer to omit the value entirely in this case.

The current algorithm has worked on all the sample models we've tried, but I admit it's possible that we misinterpreted. I don't think any of them use interleaved attributes or anything with byteStride. I'll ask the spec group.

[anthonysteed]

I just think it is ambiguous, if you read this statement:

Each accessor must fit its bufferView, i.e., accessor.byteOffset + STRIDE * (accessor.count - 1) + >SIZE_OF_ELEMENT must be less than or equal to bufferView.length.

Then it implies the stride is the total stride, not the padding.

[anthonysteed]

Wrong button.

This statement implies that the stride is the total stride, not the padding

Each accessor must fit its bufferView, i.e., accessor.byteOffset + STRIDE * (accessor.count - 1) +
SIZE_OF_ELEMENT must be less than or equal to bufferView.length.

[stevenvergenz]

Well, it looks like you're right, though it took some digging. The byteStride definition references WebGL's vertexAttribPointer's stride parameter, which reads:

A GLsizei specifying the offset in bytes between the beginning of consecutive vertex attributes. Cannot be larger than 255.

That's unambiguous. I'll get this fixed soon.

[stevenvergenz]

Fixed in 019b1c6