glTF accessor.max / min валидация - PullRequest
0 голосов
/ 29 июня 2018

Спецификация KhronosGroup glTF 2.0 требует, чтобы для массивов POSITION были определены границы accessor.max и accessor.min . Однако эти значения должны быть выражены в виде текстовых строк, в то время как координаты позиции вершины сохраняются в виде чисел с плавающей точкой одинарной точности в строках с кодировкой base64.

Проблема, с которой я сталкиваюсь, заключается в том, что онлайновый Khronos glTF валидатор и расширение Microsoft Visual Code (которое предположительно является портом валидатора Khronos) сравнивает эти значения с 15 десятичными разрядами (то есть с двойной точностью) ) и сообщает об ошибке, если они не совпадают точно. Это чрезвычайно затрудняет отладку больших файлов glTF, поскольку приводит к десяткам тысяч ошибок.

Более важно, мне интересно, важны ли эти ошибки. Я мог бы изменить свой генератор файлов glTF таким образом, чтобы координаты положения вершины могли быть без ошибок выражены в виде текстовых строк, но это кажется нелепым решением. Я что-то здесь упускаю?

1 Ответ

0 голосов
/ 29 июня 2018

Расширение VSCode использует фактический валидатор Khronos glTF, а не порт, через пакет npm. Валидатор написан на языке Dart и перенесен в JavaScript, а сам VSCode основан на Electron и TypeScript и может запускать JavaScript как часть его расширений.

Автор валидатора рассказывает о миксе / максимальной точности в этом выпуске:

https://github.com/KhronosGroup/glTF-Validator/issues/79

Валидатор ожидает, что числа, хранящиеся в JSON, совпадают с числами, хранящимися в буферах, когда они обрабатываются с одинаковой точностью (одинарная точность IEEE для чисел с плавающей запятой).

Затем он приводит пример для языка Ruby, о котором там спрашивал ОП.

Если объяснение там не соответствует тому, что вы видите, подайте новую проблему с валидатором. Спасибо!

...