Giters

KhronosGroup / glTF-Asset-Generator

Tool for generating various glTF assets for importer validation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clarification with "Color_0" vertex attribute accessor byte length.

vpenades opened this issue · comments

commented

Hi

I've been testing the new 0.6.1 assets collection, and I've found some assets in the "positive" directory that I think are invalid.

Specifically, the one located at Positive/Buffer_Interleaved/Buffer_Interleaved_01.gltf

It is true that the specification says valid values for the Color_0 attribute are:

Name Accessor Type(s) Component Type(s) Description
COLOR_0 "VEC3"
"VEC4"		 5126 (FLOAT)
5121 (UNSIGNED_BYTE) normalized
5123 (UNSIGNED_SHORT) normalized		 RGB or RGBA vertex color

But also I had the understanding that any attribute byte length was required to be multiple of 4 bytes, thus, UNSIGNED_BYTE and UNSIGNED_SHORT encodings can only be used with VEC4 colors, and VEC3 can only be used with FLOAT encoding.

Buffer_Interleaved_01.gltf Uses a VEC3 x UNSIGNED_BYTE attribute, which produces a 3 bytes stride.

I undertand that the BufferView's ByteStride already pads the vertex length with the missing byte so the whole vertex length is multiple of 4, but.... could not have been better to enforce VEC4 color anyway?

I've noticed glTF validator also passes this one as good...

So, should I interpret that vertex attributes can indeed be defined with odd lengths, and let the ByteStride padding do the work?

commented

should I interpret that vertex attributes can indeed be defined with odd lengths, and let the ByteStride padding do the work?

Yes, there is a scenario where this is useful for interleaving data, though it's not possible without an extension right now. For example, if you have COLOR_0 (byte vec3), COLOR_1 (byte vec3), and uv0 (byte vec2). This has a stride of 8. If we enforced vec4 color, then this would have a byte stride of 12.

cc @lexaknyazev to double check me

commented

should I interpret that vertex attributes can indeed be defined with odd lengths, and let the ByteStride padding do the work?

Yes. Graphics APIs usually take byte offset, stride, and attribute format, so length is handled implicitly.

could not have been better to enforce VEC4 color anyway?

While it is the same layout in terms of alignment, VEC3 type signals that per-vertex colors do not contain alpha.

there is a scenario ...

Interleaving like 3/3/2 is not allowed in the core spec, because each attribute must start at 4-byte boundaries. An extension could relax this in the future.

commented

An extension could relax this in the future.

Hope not 😺

commented

Ok to close?