GLTFLoader: Incorrect bounds for glTF models with normalized positions

[donmccurdy]

Repro

Attached, a version of WaterBottle.glb quantized by my (WIP) quantization implementation in donmccurdy/glTF-Transform#59. The model has a number of validation issues that I'm still working on, but it should be able to render in three.js now, and doesn't.

WaterBottleQuantized.zip

If you load the model and then erase the default bounding box information, it works normally.

Screenshot:

Desktop (please complete the following information):

All.

Smartphone (please complete the following information):

All.

Additional context

Referring to the code here...

three.js/examples/js/loaders/GLTFLoader.js

Lines 2860 to 2875 in 51afad9

	if ( attributes.POSITION !== undefined ) {
	var accessor = parser.json.accessors[ attributes.POSITION ];
	var min = accessor.min;
	var max = accessor.max;
	// glTF requires 'min' and 'max', but VRM (which extends glTF) currently ignores that requirement.
	if ( min !== undefined && max !== undefined ) {
	box.set(
	new THREE.Vector3( min[ 0 ], min[ 1 ], min[ 2 ] ),
	new THREE.Vector3( max[ 0 ], max[ 1 ], max[ 2 ] ) );
	} else {

... it looks like three.js (as well as babylon.js, actually) is using the POSITION attribute's .min and .max property to infer bounds of a mesh primitive, without a more costly traversal of the vertex data. However, the glTF specification states:

Exporters and loaders must treat these values as having the same data type as accessor's componentType, i.e., use integers (JSON number without fractional part) for integer types and use floating-point decimals for 5126 (FLOAT).

In other words, a normalized accessor will contain normalized integer values in its min/max, and the implementation needs to convert that to floating-point decimals to use as mesh bounds. This becomes an issue for models using KHR_materials_quantization, which may choose to use normalized 8-bit or 16-bit integer storage.

[donmccurdy]

I was a bit surprised to find this implemented the same way, apparently incorrectly, in both three.js and babylon.js — @lexaknyazev could you confirm I'm understanding the spec right here?

[lexaknyazev]

The core spec allows only real floats for the POSITION accessors, so it's somewhat expected that engines didn't cover quantized use case there.

We should add a note to the extension spec.

the implementation needs to convert that to floating-point decimals to use as mesh bounds.

That's correct.

[zeux]

I believe the core spec already covers this as a generalized topic, as it's merely a reflection of what value is stored in min/max:

accessor.max
Maximum value of each component in this attribute. Array elements must be treated as having the same data type as accessor's componentType. Both min and max arrays have the same length. The length is determined by the value of the type property; it can be 1, 2, 3, 4, 9, or 16.
normalized property has no effect on array values: they always correspond to the actual values stored in the buffer. When accessor is sparse, this property must contain max values of accessor data with sparse substitution applied.

(I don't object to a note, just saying that it's already specified fully as far as I can tell so there's no ambiguity issue)