glTF vertex colors break when using COMPONENT_TYPE_UNSIGNED_SHORT

[chipolux]

Godot version: 3.2.3
I've also tested on the 3.2 branch @ 541bc18

OS/device including version: macOS 10.15.7, Intel 2.4GHz 8-Core i9, AMD Radeon Pro 5500M 8GB, GLES3

Issue description: When exporting a glTF scene from Blender that uses vertex colors they are not correctly imported in Godot. In particular this is due to a recent change in the Blender 2.91 glTF exporter that changes the vertex colors from a VEC4 w/ FLOAT (5126) components to a VEC4 w/ UNSIGNED_SHORT (5123) components.

There is no option in Blender to force the component type, and Blender does not set the normalized flag in the relevant accessors which would also fix this issue.

The glTF spec does require that UNSIGNED_BYTE and UNSIGNED_SHORT components for COLOR_0 should be normalized, but I'm not sure if that means Blender should be setting the accessor flag, or if the importer should handle this.

Steps to reproduce:

1. Generate a simple scene in Blender 2.8 that uses vertex colors and export it to glTF 2.0.
2. Update to Blender 2.91 and export the same scene in the same way.
3. Import both scenes into a Godot project and assign a spatial material with the "Use As Albedo" flag set to all relevant meshes.
4. See how the scene that was exported from 2.8 correctly displays the colors, while the scene from 2.91 is likely entirely white.

Minimal reproduction project: gltf-test.zip
This example project contains two scenes, ship-float.tscn which uses vertex colors packed as COMPONENT_TYPE_FLOAT, and ship-ushort.tscn which uses vertex colors packed as COMPONENT_TYPE_UNSIGNED_SHORT. Otherwise they are identical.

I also have a commit in my fork that "fixes" this, but I'm not sure if it would be better to just override the normalized flag on the accessor before calling _decode_accessor, or if really this should just be handled over in the Blender exporter by setting the normalized flag when they set the component type.

[chipolux]

Oh, I also checked and this is "broken" in master as well, but man... I'm just not sure if Blender should be setting the normalized flag or not...

[fire]

It is difficult to get released version of Blender bugs fixed. Will look at the spec.

It would be ok to detect that a color array is UNSIGNED_BYTE and UNSIGNED_SHORT to set the normalized flag on it in the Godot glTF import / export segments.

[scurest]

Blender does not set the normalized flag in the relevant accessors

It is definitely a bug in the Blender exporter if it doesn't set "normalized": true, but it does set this when I try it.

[fire]

Can you test Godot with #44746 or #44745. This means a newer version than 3.2.3.

Edited: I missed your note.

[fire]

I hope this helps.

[scurest]

The ship-ushort.gltf file from the .zip attached to the OP is missing "normalized": true for its COLOR_0s (note that it also fails to validate for this reason), but its asset.generator field also says it was created by THREE.GLTFExporter, not Blender.

[chipolux]

Hmm, you're right, I ran it through a converter as I only had the GLB easily available and wanted to find the diff between my two exports. Here's a new GLTF exported directly from Blender. And you're also right about it setting the normalized flag! It's using v1.4.40 of the their built-in exporter.

I'm a real dummy, sorry about that guys. The patches that'll go into 3.2.4 will fix this!