Require accessor min/max for POSITION?

[pjcozzi]

See CesiumGS/cesium#3925

[pjcozzi]

Labeling as resolved. See fdf4337 in the 1.0.1 branch.

[lexaknyazev]

Just to be clear, why are min|max always required in fdf4337, not just for POSITION?
Are there any common use cases for NORMAL or TEXCOORD?

[lexaknyazev]

One more possibly worth mentioning constraint: min|max length must be one of [1, 2, 3, 4, 9, 16] and match accessor's type.

[pjcozzi]

One more possibly worth mentioning constraint: min|max length must be one of [1, 2, 3, 4, 9, 16] and match accessor's type.

See #617.

Just to be clear, why are min|max always required in fdf4337, not just for POSITION?
Are there any common use cases for NORMAL or TEXCOORD?

This is for simplicity and consistency. Early on, we received some glTF feedback that all properties should be required. We didn't agree as it can make things verbose; however, experience has shown that having some optional and some required properties has caused some implementation confusion for clients - which goes against one of our main goals: making glTF easy to implement consistency. So I think requiring min/max only for POSITION starts to make the required/optional rules too complex and could lead to a less robust ecosystem.

[lexaknyazev]

So I think requiring min/max only for POSITION starts to make the required/optional rules too complex and could lead to a less robust ecosystem.

I was curious because of opposite approach in #616 (diff).

[pjcozzi]

Ah, yes, I think we should make #616 (diff) apply to all attributes, not just POSITION.

@mlimper @lasalvavida what do you think?

Just to be clear, why are min|max always required in fdf4337, not just for POSITION?
Are there any common use cases for NORMAL or TEXCOORD?

This is for simplicity and consistency. Early on, we received some glTF feedback that all properties should be required. We didn't agree as it can make things verbose; however, experience has shown that having some optional and some required properties has caused some implementation confusion for clients - which goes against one of our main goals: making glTF easy to implement consistency. So I think requiring min/max only for POSITION starts to make the required/optional rules too complex and could lead to a less robust ecosystem.

[mlimper]

It doesn't seem like a huge amount of work for implementers of glTF writers if we require them to also write min/max for other attributes, given that they would already provide this information for POSITION.
On the client side, requiring min/max will facilitate implementation... although I must admit that I currently don't have any important real-world use case in mind where one would need min/max for normals / texcoords. Maybe you could figure out that you are looking at an object where everything is viewed from the back (using normal min/max) and then not render it, if backface culling would be enabled?^^
To conclude, I would tend towards making min/max required for all attributes, for simplicity.

[pjcozzi]

Thanks for the input, @mlimper!

@lexaknyazev are you good with this? The WEB3D_quantized_attributes spec will also go this direction.

[lexaknyazev]

@lexaknyazev are you good with this? The WEB3D_quantized_attributes spec will also go this direction.

Consistency matters.

On the client side, requiring min/max will facilitate implementation

Validation will be simplier too.

[pjcozzi]

Thanks for the prompt response! 😄

[pjcozzi]

Updated in #826