Version 2.0.0-dev.3.3

[lexaknyazev]

2.0.0-dev.3.3

New Features

• Added support for new PBR extensions: KHR_materials_clearcoat, KHR_materials_transmission, and KHR_materials_sheen.

• Added CAMERA_YFOV_GEQUAL_PI validation warning (Camera perspective yfov has no upper limit. #140).

• Added new SKIN_IBM_ACCESSOR_WITH_BYTESTRIDE error for IBM accessors using buffer views with defined byteStride.

• Added new IMAGE_BUFFER_VIEW_WITH_BYTESTRIDE error for images using buffer views with defined byteStride.

• Added new vendor prefixes: ANIMECH, GRIFFEL, MAXAR, MPEG, PANDA3D, PTC, SEIN, SPECTRUM, TRYON, and VRMC.

Changes

• Modified MULTIPLE_EXTENSIONS warning. It is now reported only for explicitly standalone extensions (No explicit warning when using unlit and pbrSpecularGlossiness #145 and Multiple Extensions warning #146).

• Added missing check for morph target accessors overriding buffer view usage.

Bugfixes

• Fixed an endless loop on assets with a node loop within a scene (Validator gets stuck in endless loop #141).

• Fixed building all targets at once (pub run grinder with no args).

• Fixed missing JS API error messages when the validator is compiled in debug mode.

• Web drag-n-drop tool now shows a correct message when no glTF assets were provided.

Integration updates

• npm tool no longer re-defines require (Warning when running within Angular #139).

• npm tool no longer requires options.externalResourceFunction for GLB or assets with embedded data (Bug: Different result in Web view than CLI and node module #138).

• options.validateAccessorData npm tool flag is removed, accessors' data validation is always enabled.

• npm tool now reports IO_ERROR for external resources when options.externalResourceFunction is not provided.

• CLI tool now supports --stdout flag for writing a single validation report to STDOUT instead of a new file.

• CLI tool validates binary data by default (Bug: Different result in Web view than CLI and node module #138).

[donmccurdy]

Unfortunately it'll be 1-2 weeks before I'm able to review this — if others have time to review in the meantime, please feel free to merge this without me.

Should we fail in a case when an npm version is called without options.externalResourceFunction but the asset uses external files and their validation was requested with options.validateAccessorsData: true?

Because validateAccessorsData defaults to true and externalResourceFunction defaults to undefined, it seems unfortunate that validation would always fail with its default options... Maybe providing externalResourceFunction should simply cause accessor data to be validated, and the validateAccessorsData option can be removed?

[emackey]

Maybe providing externalResourceFunction should simply cause accessor data to be validated, and the validateAccessorsData option can be removed?

I like this idea. Basically if the external data can be validated (either because it's GLB or because a function was supplied), then there's no reason to skip validation of it.

If such validation doesn't happen, perhaps there could even be a warning, that the model wasn't completely submitted to the validator?

[lexaknyazev]

then there's no reason to skip validation of it

I think there were some reasons initially. The main was the assumption that binary data validation could be too slow but it looks like even with all the extra checks added in the previous update it's still fast enough.

If such validation doesn't happen, perhaps there could even be a warning, that the model wasn't completely submitted to the validator?

How should such warning be reported? Since it doesn't apply to the asset itself, we'd need to adjust the report schema to have an extra flag, like it has truncated for reports with too many messages. Web version would have an extra visual warning that not all external resources were submitted (as some users drag-n-drop only the JSON file).

[emackey]

How should such warning be reported?

I'm flexible on this. We do have some warnings that are not asset-related, primarily I'm thinking of the "extension not supported by the validator" warning. But yes, this could be a case for a new "truncated" type of warning.

Basically my thinking is, if a user has gone to the trouble to run the validator, they should be warned if it wasn't a completely successful validation of all parts of the glTF, including the external resources. I'm open to ideas though.

[lexaknyazev]

Fair point. We could attribute the lack of externalResourceFunction to resources that actually need it rather than to the report in general.

[emackey]

Ah, we could apply this warning using JSON pointers for each of the external resource(s) affected, that sounds good to me.

[emackey]

@donmccurdy Are you OK with where this conversation ended?

[emackey]

Small suggestion here, but this all looks great. I tested some of the new warnings and messages in VSCode.

[lexaknyazev]

@emackey
Is sheen extension schema ready to be added here?

[emackey]

Yes, thanks!

[lexaknyazev]

Added KHR_materials_sheen support.

[donmccurdy]

Are you OK with where this conversation ended?

A warning on external resources that couldn't be validated sounds good to me, yes. 👍

[emackey]

Let's add the UX3D extension prefix here and call this one done. ✅

[lexaknyazev]

@emackey
Let me update the SDK constraints to keep CI green since we're not fully compatible with 2.12 yet.

[emackey]

Anything I can do to help this along? Do we just need a tighter range on the SDK listed in pubspec.yaml?

[emackey]

Travis has been running for almost 2 hours, is it stuck?

[emackey]

Published to npm.

[lexaknyazev]

Drag-n-drop tool updated.

[hypnosnhendricks]

How could I have tracked the development of SKIN_IBM_ACCESSOR_WITH_BYTESTRIDE from when it was a concept to implementation to release? Our GLB assets are currently running into this newly added error & I would like to be able to track progress of any new errors being added to the validation tool before they make it into release. My github skills are basic at best. Thanks!

[lexaknyazev]

@hypnosnhendricks
The easiest way would be to subscribe to the repo updates as described in the GitHub docs.

As for that particular validation message, its omission before this release was a bug because the spec defines byteStride only for vertex attributes.