Clarification on min/max float precision

[lexaknyazev]

I've put it in accessor's definitions, because it's the only case of direct comparison between buffer-stored and json-stored floats.

[lexaknyazev]

Maybe we should also add backwards requirement: a json-stored float string must be equal to the decimal gotten from buffer data:

2.3 to Float32Array: [51, 51, 19, 64]
[51, 51, 19, 64] from Float32Array: 2.299999952316284

[pjcozzi]

Thanks @lexaknyazev! Can you also update the accessor's schema file to keep the schema and spec in-sync? The original spec was actually generated from the schema using https://github.com/AnalyticalGraphicsInc/wetzel.

Maybe we should also add backwards requirement: a json-stored float string must be equal to the decimal gotten from buffer data...

Maybe, can you provide the context and use case for this?

[lexaknyazev]

Let's say we have accessor.min: 2.3. Its single-precision bytes are [51, 51, 19, 64] and let's say this is the actual minimum value stored in binary buffer. So, 2.3 conforms PR's requirement.

JavaScript treats all numbers as doubles. When js-based processing tool (such as gltfPipeline) extracts such value from Float32Array it will get 2.299999952316284 which is less than 2.3. So, strictly speaking, 2.3 isn't an actual minimum.

[pjcozzi]

So basically this enforces that exporters need to export the double-precision value for min/max?

[lexaknyazev]

I think that there are two ways to resolve this:

1. Ensure that a numeric value that is converted to a string will be parsed back into the same numeric value (exporter can use C# approach or always print doubles with enough precision).
2. glTF tools can convert JSON doubles to singles in runtime before comparing them with Float32Array values.

[pjcozzi]

Sounds good. Before merging this, can you:

• Update the accessor's schema file to keep the schema and spec in-sync? The original spec was actually generated from the schema using https://github.com/AnalyticalGraphicsInc/wetzel.
• Up to you, but consider adding a non-normative section with your explanations, Clarification on min/max float precision #628 (comment), which would be useful for implementations.

[lexaknyazev]

The question remains: should spec enforce two-way match of values or not? The burden will be on exporters or on clients.

[pjcozzi]

The question remains: should spec enforce two-way match of values or not?

Yes, I think this is fine. Do you agree?

However, we need to put the burden on exporters; otherwise, clients will always require the workaround.

[lexaknyazev]

The question remains: should spec enforce two-way match of values or not?

Yes, I think this is fine. Do you agree?

Yes. I'll update this PR asap.

[lexaknyazev]

Is it OK now?

[pjcozzi]

Looks good, thanks @lexaknyazev!