-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify extension usage validation #231
Comments
23 tasks
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the use of extensions is validated in (what I first thought to be) a straightforward way. One aspect of that validation is:
boundingVolume.extensions["3DTILES_bounding_volume_S2"]
), then the"3DTILES_bounding_volume_S2"
is stored as a "found" extension in the validation contextextensionsUsed
that have been declared. When an extension was "found" but not declared as "used", a warning is created. When an extension was declared as "used", but not "found", a warning is created.The problem (which is obvious in hindsight): Certain extensions are never "found" explicitly. For example,
3DTILES_content_gltf
. It never appears as an object anywhere, but only allows glTF/GLB files to be used as tile content.This can be solved, to some extent, by keeping track of the actual content data types that have been encountered. (There are corner cases where this becomes less trivial. For example, when the content data validation is disabled via a command line flag).
A related question is the version dependency. A specific example is that
3DTILES_content_gltf
should probably not be used in a1.1
tileset, and using it should cause a warning. The more general question is: How to encode the mix-and-match between "tileset versions" and "allowed extensions". There may be extensions that are valid only in1.0
, other may be valid only in1.1
, and others may be valid in both...The text was updated successfully, but these errors were encountered: