Closed javagl closed 1 year ago
A summary of the points that are not ticked:
For statistics.class.property
... One could add constraints (like !(min>max)
)
For class.property
: One could go full pedantic mode, and require min
/max
to be integer values when the component type is integral, and require the bounds of the values to be obeyed. For a UINT8
(without offset
or scale
), a max=0.8
does not make sense, and neither does a min=-10000
.
I think that this could make sense. But I'd tend to tackle this as its own issue/PR, if desired. Taking the offset
and scale
into account makes this not entirely trivial. One would have to write it in a form like
The
max
may not be larger thanmaxDataTypeValue*scale+offset
...
with proper specification of what maxDataTypeValue
is...
For templateUri
... One could consider to add the requirement that the variables {level}
, {x}
, {y}
, {z}
MUST be present for the respective tree types.
{mortonIndex}
, then the other variables would be unused...For subtree ... I thought that one could add the constraint that buffer views may not overlap
For availability
... One could add a constraint that availableCount
may not be larger than bufferView.byteLength/8
(?)
For tile
... (see checklist)
transform
could make sense. If this should be addressed, it should be tracked in a dedicated issue. content
or contents
: Right now, the implicit tiling section says that tile.content
and tile.contents
shall be omitted when there is no contentAvailability[x]===1
. It seems natural to require it to be present when there is a 1
-bit in the bitstream. Should this be added in the spec text and the tile.content
schema? More importantly: Are there other (less tangible or obvious) conditions under which tile content must be present? Structural: ...
tile
considerations (above): It's sometimes hard to pin down how semantics affect the validity of an asset. This might be a broader question, once on the spec level, and once on the level of how the validator treats semantics. Regarding extensionsUsed: ...
Looks good. Thanks @javagl.
Addressing https://github.com/CesiumGS/3d-tiles/issues/711 : I'll replicate the bullet point list here, and mark the parts that have already been solved with checkboxes.
[x] For
boundingVolume
:latitude
andlongitude
for theregion
bounding volume should be constrained to the ranges that are mentioned in https://spatialreference.org/ref/epsg/4979/ (-180.0000, -90.0000, 180.0000, 90.0000)south
may not be greater than thenorth
radius
of the bounding sphere should not be negative[x] For
properties
(although deprecated?)maximum
should not be smaller than theminimum
[x] For
statistics
:TheBased on internal discussion, it should remain optionalclasses
should be requiredclasses
dictionary and..." - this is confusing. It should say "... in theclasses
dictionary of the metadata schema of the containing tileset, and ..."statistics.class.properties
description should refer to the class of the metadata schema[ ] For
statistics.class.property
:!(min>max)
) here. But one could go pretty far, e.g.!(mean>min)
, and even make mathematically based constraints about the possible values of the standard deviation and such. Maybe this is a step too far for now (there are more important constraints/checks to be added)[ ] For
class.property
:enumType
should be disallowed for non-"ENUM"
typescomponentType
should be required for the SCALAR/VECn/MATn types.min
/max
to be integer values when the component type is integral, and require the bounds of the values to be obeyed. For aUINT8
(withoutoffset
orscale
), amax=0.8
does not make sense, and neither does amin=-10000
.min/max/offset/scale
do not make sense for variable length arrays. This is mentioned at https://github.com/CesiumGS/3d-tiles/tree/draft-1.1/specification/Metadata#minimum-and-maximum-values but could also be mentioned in the schema[ ] For
templateUri
{level}
,{x}
,{y}
,{z}
MUST be present for the respective tree types. For now, I assume that any{unknown}
expression is an error, and "missing" ones (e.g. a missing{z}
for anOCTREE
) should cause a warning.[ ] For
subtree
was disallowed. But I don't see a strong reason to disallow that (and glTF apparently does allow this as well...)
[ ] For
availability
availableCount
may not be larger thanbufferView.byteLength/8
(?)tile.content
now, and does not mentiontile.contents
)0
[ ] For
tile
:transform
. From "weak" to strict: It should probably not be zero. It should probably be invertible. It should probably have a positive determinant. It should probably not contain skew/shear components. It should probably be decomposable into translation, rotation, scale components. See https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#transformations for inspiration.content
/contents
MUST be present are difficult. One could say that one of them MUST be present whenimplicitTiling
is present, but ... strictly speaking, only when there is anycontentAvailability[i]=true
.[x] For
schema
schema.id
is marked as 'required' and must match the usual "ID regex". The ID may eventually be used (e.g. by CesiumJS) to uniquely identify properties in Custom Shaders, or to identify that theschema
objects of two loaded tilesets are the same schema. But the spec should (at least as an 'Implementation Note') describe the purpose, and give usage hints - for example, whether it should only be a semi-random "unique ID", or a human-readable string, or maybe something that includes a concept of "versioning".[x] For
tileset
:extensionsRequired
must also appear inextensionsUsed
[ ] Structural:
geometricError
that is larger than thegeometricError
of the parent, but overrides this geometric error with metdata so that it is smaller than that of the parent, should this cause a validation issue?[ ] For
subtree
buffer
may omit theuri
property (only one buffer may refer to the binary chunk)[ ] Regarding
extensionsUsed
:This should be reviewed and possibly clarified. If one tileset refers to an external tileset that does not use any extensions, but is later modified to use a certain extension, then the containing tileset may become "invalid", because it does not declare this extension as
extensionsUsed
. While this makes sense from the perspective of knowing which extensions will be used as a whole, it somewhat contradicts the idea of external tilesets being "building blocks" that can be combined arbitrarily.