PropertyAttributesPropertyAttributePropertyMaxMismatch.gltf is valid about 3d-tiles-validator HOT 7 CLOSED

Same for PropertyAttributesPropertyAttributePropertyMinMismatch.gltf

from 3d-tiles-validator.

I'll read a few things again to be 100% sure, but right now, I'm (only) 99% sure that this is a misunderstanding.

There are two different max values.

• The propertyAttribute.property.max, which is described as

  Maximum value present in the property values.

• The class.property.max, which is described as

  Maximum allowed value for the property.

To put it that way:

• the max of the attribute/texture property is the maximum value that actually appears
• the max of the class property is the maximum value that is allowed to appear

This is reflected in the two test cases:

• The PropertyAttributesPropertyAttributePropertyMaxMismatch sets max=0.3 in the property attribute property, as the maximum value that actually appears. But the maximum value that really appears is 0.25.
• The PropertyAttributesClassPropertyMaxNotInRange sets max=0.7 in the class property, as the maximum value that is allowed to appear. But the maximum value that really appears is 0.75.

The names of these glTF files are quite a mouthful - but I tried to squeeze some meaning into that:

• First one:
  • PropertyAttributes... - The category
  • ...PropertyAttributeProperty... - The specific thing that is wrong...
  • ...MaxMismatch - The actual error: A mismatch (meaning that they should match)
• Second one:
  • PropertyAttributes... - The category
  • ...ClassProperty... - The specific thing that is wrong
  • ...MaxNotInRange - The actual error: The (computed) maximum is not in the (valid) range that was defined by the class.property.max

Also, the messages try to reflect that:

• For the property attribute property: "For property 'intensity', the property defines a maximum of 0.3, but the computed maximum value is 0.25"
• For the class property: "For property 'intensity', the class property defines a maximum of 0.7, but the value at 3 of the attribute _INTENSITY of primitive 2 of mesh 0 is 0.75"

If you think that this is a bug, then I'll have to look into that.
If you think that it is not a bug, but have ideas about how the validator or spec could be improved, feel free to drop them here.

(The inherent ambiguity of "maximum", with the specific meanings of "allowed maximum" and "appearing maximum", always bugged me, but that's on a rather linguistic level...)

from 3d-tiles-validator.

ah ok thanks, I see it now in the specs too:

property attribute property: Max: "Maximum value present in the property values. "

class property: Max: "Maximum allowed value for the property."

Indeed confusing to have a property with same name having complete different meanings in different parts of the specs... I thought only the latter definition was used. I'll check my code again.

from 3d-tiles-validator.

Btw: A property like max is 'Only applicable to SCALAR, VECN, and MATN types.' according to the specs. What if the type is Vector3, what could be the max value? How is it stored in the property, with comma separated values? Is there an example?

from 3d-tiles-validator.

Yeah, one could clarify this with elaborate names like maximumAllowedValue and maximumAppearingValue or so, but it's unlikely that such a change would/could still make it into the spec at this point.

What if the type is Vector3, what could be the max value? How is it stored in the property, with comma separated values? Is there an example?

I think that there currently is no dedicated example for that.

Eventually, the actual check boils down to a call to the ArrayValues class from the 3D Tiles Tools. This class could be seen as ... a bit awkward, because it tries to cover ~"values" that are structurally different: Scalars, 1D arrays, and 2D arrays. This is solely intended for the metadata handling, because there simply is no (TypeScript-level) type information about the metadata values. But it means that from the perspective of the validator, there is no difference for these cases: It just checks anyDeepGreaterThan(value, max) regardless of whether the value/max are number, number[], or number[][].

But it is indeed something for which it could be justified to add a dedicated test on the spec level. The ArrayValues class should have a decent test coverage. But on the validator side, it would be good to have such an example (even if it's a simple one).

About the structure of these values;

The values will always have the same structure as the metadata values. So when the property is a VEC3, then the JSON representation of the metadata value would be a 1D array [0.0, 1.0, 2.0]. When the value is an array of VEC2, then the JSON would be a 2D array [[0.0, 1.0], [2.0, 3.0]].

The actual operations (minimum/maximum, but also offset/scale) are always applied component-wise. This is mentioned at one point in the spec, and aligns with the accessor min/max properties of the glTF core specification.

from 3d-tiles-validator.

ah ok, and for a matrix it's 1D array column major or row major?

from 3d-tiles-validator.

Looks like column major https://github.com/CesiumGS/3d-tiles/tree/main/specification/Metadata#matrices

from 3d-tiles-validator.