3D Tiles Validator Roadmap

[pjcozzi]

Validator roadmap

Validates

• tileset.json
• Tile Formats
  • b3dm
  • i3dm
  • pnts
  • vctr
  • cmpt
• Declarative styling

This is a non-exhaustive list, please add all corner-cases as you come across them. Also update the spec/schema with cases that they do not cover.

Requirements

Architecture

• Node.js library and command-line tool
• Returns JSON object (Node.js) and readable output (command-line tool) with errors/warnings. Base off of the glTF Validator. Include JSON line numbers when possible.
• Unit tests with outstanding code coverage
• Reference doc (Node.js library) and usage doc (command-line tool)

tileset.json validation

• General
  • Valid JSON Validator - readTileset #10
  • Validate the schema, e.g., required properties, min/max values, allowed datatypes/values, etc.
  • Port any bounding volume tests to Cesium
• tile (including spatial coherence of the tree)
  • Going down the tree, a tile's geometricError must be <= to the parent tile's geometricError.
  • Likewise, root.geometricError must be <= the tileset's geometricError.
  • Going down the tree, a tile's boundingVolume must be inside/overlap its parent tile's boundingVolume (taking into account applying transforms).
    • The tile's content needs to be strictly inside the parent tile's boundingVolume. See Bounding volume spatial coherence.
      • This is a non-trivial and needs to take into account 3D Tiles transform and glTF node hierarchy (use gltf-pipeline). Get enough experience before tackling this one.
    • When a tile has no content (because it is just used for culling), its boundingVolume must be completely inside its parent tile's boundingVolume. Also update the spec with this.
• tile.content
  • tile.content.boundingVolume, when defined, is completely inside tile.boundingVolume (use Cesium's functions)
  • tile.content.url points to a file that exists (and a tile/tileset that validates)
  • When tile.content.url is an external tileset, these rules must be followed.

Tile format validation

• b3dm
  • Validate header Validator - validateB3dm header #9
  • Validate Batch Table is valid JSON and follows the schema (have a generic validation function for this).
    • Validate offset/length for all properties pointing to the binary body are in range
  • Validate glTF using glTF-Validator.
  • If the tile has a Batch Table, verify that the glTF has a technique parameter semantic _BATCHID.
  • Validate that glTF batchId attributes are in range, i.e., they exist in the Batch Table.
  • Validate batch table hierarchy
• i3dm
  • Validate header. Validator - validate i3dm header #22
  • Validate Feature Table is valid JSON and follows the schema.
    • Validate BATCH_ID semantic, if defined, is in range (have a generic validation function for this).
    • If NORMAL_UP/NORMAL_RIGHT (or NORMAL_UP_OCT32P/NORMAL_RIGHT_OCT32P) are defined, verify that they are orthonormal.
    • Validate offset/length for all properties pointing to the binary body are in range
  • Validate Batch Table is valid JSON and follows the schema (have a generic validation function for this).
    • Validate offset/length for all properties pointing to the binary body are in range
  • Validate glTF using glTF-Validator.
• pnts
  • Validate header. Validator - validate pnts header #24
  • Validate Feature Table is valid JSON and follows the schema.
    • Validate BATCH_ID semantic, if defined, is in range (have a generic validation function for this).
    • Validate RGBA/RGB/CONSTANT_RGBA are in range.
    • If NORMAL/NORMAL_OCT16P are defined, verify they are of unit length.
    • Validate offset/length for all properties pointing to the binary body are in range
  • Validate Batch Table is valid JSON and follows the schema (have a generic validation function for this).
    • Validate offset/length for all properties pointing to the binary body are in range
• vctr
  • Validate header.
  • Validate Feature Table is valid JSON and follows the schema.
    • Validate BATCH_ID semantic, if defined, is in range (have a generic validation function for this).
    • TODO: finish this as the tile format stabilizes.
    • Validate offset/length for all properties pointing to the binary body are in range
  • Validate Batch Table is valid JSON and follows the schema (have a generic validation function for this).
    • Validate offset/length for all properties pointing to the binary body are in range
• cmpt
  • Validate header. Validator - validate cmpt header #23
  • Recursively validate inner tiles, including composites of composites. Validator - validate cmpt header #23

Declarative styling validation

Do this last after the tileset.json and tile formats validation.

• Valid JSON.
• Validate the schema.
• Validate each JavaScript expression (Cesium uses jsep).
  • Cesium does some runtime validation, but the validator needs to be more comprehensive. See Expression.js. The unit tests may also be useful, see ExpressionSpec.js.
  • Carefully read the styling spec and validate all rules related to type compatibility, function/constructor parameters, reg exps, etc.
• When a tileset and style are validated at the same time, verify that the style references properties that exist in the batch table? Or they should should return undefined?

[FreakTheMighty]

Hey team! I'm interested in using the validator, but see that things have stalled. I'd be open to contributing, but I'm not sure how up-to-date this roadmap is. Any chance someone familiar with this could give the checklist ☝️ a once over?

[javagl]

Recently, there have been some efforts to revive the validator. I'll try to summarize the points from the roadmap here. The original points (or summaries thereof) are given in "italics". Comments/resolutions are given in plain text. Points that are already covered are omitted.

---

Validator roadmap

• "Declarative styling"

  • This is tracked in Add support for declarative styling validation #234

• "Update the spec/schema with cases that they do not cover"

  • Clarifications for the spec that resulted from the implementation of the validator are tracked in Clarifications and additions for the specification 3d-tiles#711 and, addressing them is on the Roadmap

Requirements/Architecture

• "Unit tests with outstanding code coverage"
  • There are unit tests and some integration tests. The current coverage may not be "outstanding", but increasing it is an ongoing task. Further thoughts about the test approaches are summarized in Review the unit test approach #226
• "Reference doc (Node.js library) and usage doc (command-line tool)"
  • The CLI usage is documented in the main README.md (and may be moved to a USAGE.md once it becomes too large). The API documentation is auto-generated, and may be hosted publicly at some point - see Publish the API documentation #254

tileset.json validation

The general validation (JSON schema, basic spatial coherence, ...) are covered now. The ones that are not covered yet:

• Some aspects of bounding volume containment and overlap checks. The current state of the bounding volume checks was largely taken from the previous state of the validator (and ported from JavaScript to TypeScript), and could be extended to check Validate that geometry is fully contained in bounding volumes #233 and the remaining cases from Validator - Bounding Volume Spatial Coherence #25 .

• "tile.content.url points to a file that exists (and a tile/tileset that validates)"

  • This is open for debate: Whether or not a non-resolvable resource should be an issue depends on the use case. For example, when validating a tileset file locally, then one could consider a missing file as an ERROR. When a tileset contains an (absolute) http:... URL, then one might want to not even access that resource during validation. Generally, I consider this as one special case of the broader issue to Define the validation configuration options #224

Tile format validation

This section listed different aspects that could be validated for the tile formats b3dm, i3dm, pnts, vctr, cmpt. Considering that these formats are now considered to be "legacy" (and largely replaced by glTF), it is unlikely that an increased effort here is justified. See the first comment in this issue for details, and search open issues with Validator - in the title for cases that are already tracked as dedicated issues.

---

Considering that everything is either addressed, obsolete, or tracked in existing issues, I think that this issue can be closed.