GLTFExporter: Add support for WebGPURenderer

[donmccurdy]

Related:

• Addons: Support overview in WebGLRenderer and WebGPURenderer. #29295
• Provide a WebGPU build that re-exports from three #29156
• USDZExporter: Add support for WebGPURenderer. #29507

Remaining:

• "Export Scene 1 and Object" test is failing, with invalid output

[donmccurdy]

@Mugen87 @sunag I think the remaining issues in this PR have been fixed – ready for review!

[Mugen87]

When using WebGPURenderer in misc_exporter_gltf I have encountered one issue.

(First of all it was necessary to remove the LineLoop object from the scene since this type of 3D object is not supported by WebGPURenderer in general.)

The real issue is that the coffeemat asset is not correctly imported in glTF Viewer. The following validation errors appear:

Error	Message	Pointer
MESH_PRIMITIVE_ATTRIBUTES_ACCESSOR_INVALID_FORMAT	Invalid accessor format '{VEC3, UNSIGNED_INT}' for this attribute semantic. Must be one of ('{VEC3, FLOAT}', '{VEC3, BYTE}', '{VEC3, BYTE normalized}', ..., '{VEC3, UNSIGNED_SHORT}', '{VEC3, UNSIGNED_SHORT normalized}').	/meshes/0/primitives/0/attributes/POSITION
MESH_PRIMITIVE_ATTRIBUTES_ACCESSOR_INVALID_FORMAT	Invalid accessor format '{VEC2, UNSIGNED_INT}' for this attribute semantic. Must be one of ('{VEC2, FLOAT}', '{VEC2, UNSIGNED_BYTE normalized}', '{VEC2, UNSIGNED_SHORT normalized}', ..., '{VEC2, SHORT normalized}', '{VEC2, UNSIGNED_SHORT}').	/meshes/0/primitives/0/attributes/TEXCOORD_0
MESH_PRIMITIVE_ATTRIBUTES_ACCESSOR_INVALID_FORMAT	Invalid accessor format '{VEC3, UNSIGNED_INT}' for this attribute semantic. Must be one of ('{VEC3, FLOAT}', '{VEC3, BYTE}', '{VEC3, BYTE normalized}', ..., '{VEC3, UNSIGNED_SHORT}', '{VEC3, UNSIGNED_SHORT normalized}').	/meshes/1/primitives/0/attributes/POSITION
MESH_PRIMITIVE_ATTRIBUTES_ACCESSOR_INVALID_FORMAT	Invalid accessor format '{VEC2, UNSIGNED_INT}' for this attribute semantic. Must be one of ('{VEC2, FLOAT}', '{VEC2, UNSIGNED_BYTE normalized}', '{VEC2, UNSIGNED_SHORT normalized}', ..., '{VEC2, SHORT normalized}', '{VEC2, UNSIGNED_SHORT}').	/meshes/1/primitives/0/attributes/TEXCOORD_0

[donmccurdy]

@Mugen87 the issue is caused by these vertex attribute conversions:

three.js/src/renderers/webgpu/utils/WebGPUAttributeUtils.js

Lines 50 to 62 in 1360b24

	// patch for INT16 and UINT16
	if ( attribute.normalized === false && ( array.constructor === Int16Array || array.constructor === Uint16Array ) ) {
	const tempArray = new Uint32Array( array.length );
	for ( let i = 0; i < array.length; i ++ ) {
	tempArray[ i ] = array[ i ];
	}
	array = tempArray;
	}

glTF does not permit the use of uint32 or int32 for vertex positions, and WebGPU does not permit 8-bit and 16-bit integer formats AFAIK, so the conversion for WebGPU is not compatible with glTF.

Related:

• WebGPURenderer: Add (u)int16 Support #28008

I guess GLTFExporter could convert the attributes to float32, or we could change the WebGPU patch to use float32, or we could wait on gpuweb/gpuweb#4549. But I think that probably doesn't need to block the current changes.

[donmccurdy]

Aside - when running this demo with WebGPURenderer there is a rendering issue on my device (macOS, M1, Arc/Chromium), before starting the export. Looks possibly related to integer geometry, too, maybe normalized uint8 and uint16 are not handled? Sort of off topic but just noting in case I forget. :)

[Mugen87]

Then I vote for an attribute conversion in the exporter.

[donmccurdy]

@Mugen87 I've pushed a fix for the int32/uint32 problem, the coffeemat.glb export renders without validation errors. However, texture decompression in WebGPUTextureUtils doesn't seem to be working quite correctly yet. Comparing before and after in https://gltf.report —

before	after

The model includes KHR_texture_transform, perhaps WebGPUTextureUtils needs to temporarily disable UV transforms? I'd prefer that this be considered an unrelated issue and not part of the current PR, though.

[Mugen87]

With #29680, the coffeemat.glb export is imported correctly in gltf-viewer now.

The issue with ShaderBall.glb is more interesting. It uses normalized attributes and renders distorted in the example. However, removing all other objects from the scene and the error is gone. Depending on what objects you remove, ShaderBall.glb might be scaled up so the entire scene gets gray.

This seems to be more an issue of a broken world matrix. But I don't know yet where the root cause is. It might make sense to file a separate issue for that.