Validation of EXT_instance_features #284
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds upon #280
It adds functionality for validating
EXT_instance_features
. There is a considerable overlap on a low technical level: ForEXT_mesh_features
andEXT_instance_features
, the validator has to validate "feature IDs and their values". The main difference is...EXT_mesh_features
, the feature ID attribute refers to the mesh primitive attributesEXT_instance_features
, the feature ID attribute refers to theEXT_mesh_gpu_instancing
attributesEXT_instance_features
, the feature ID can not refer to feature ID texturesThe current state here is to "carve out" the validation of feature IDs so that most of the code can be shared for the validation of both extensions.
It does raise some questions for the unit tests. Most of the feature ID validation should already be covered with tests for the
EXT_mesh_features
part. There's probably no need to add dozens of files for theEXT_instance_features
validation that are invalid in the same way. At some point, this will touch #226 and raise the question of whether all unit tests should be done based on complete files, or whether some of them should be broken down to the lower ("classical") level of specs that check the behavior of individual functions. So instead of having a bunch ofone could have a single
to check the same thing on a different level. But (for now) I still like the "holistic" approach of using complete files, and deciding on the level and granularity for the other approach could be tricky.