A 3D Tiles validator can help identify structural and content problems in a tiled delivery. Its report is meaningful only for the root, resources, content types, and options it actually examined. Record that coverage, then check package resolution and the recipient’s intended use separately; a clean report alone does not establish that the delivery is usable.
Define the delivery and the recipient decision
Before checking files, identify the delivered representation and version, its root tileset or package, and the operation the recipient needs to perform. A delivery may begin from a tileset.json file or a package such as .3tz or .3dtiles. If the tiles were produced through a transformation, record which delivery revision and transformation output are under review.
State the intended recipient and task in practical terms: for example, opening a coordination view, inspecting a selected area, or loading the tiles in a named client. That purpose determines which resources and observations matter. A schema or structure check cannot decide whether the coordinates align with the project, whether the display is suitable, or whether the recipient can complete the task.
Set the input boundary and inventory references
3D Tiles describes a hierarchical tileset. A root can reference tile content; implicit tiling also uses subtree files and availability information. External tilesets can introduce another resource boundary. A valid root file therefore does not by itself show that every referenced tile, subtree, or nested tileset is present and reachable. See the OGC 3D Tiles 1.1 specification for the format and conformance model.
Choose the exact input the validator will receive and list what it includes. Note whether it is the whole delivery package or one root file, and whether referenced resources are inside that boundary. Record excluded resources, external locations, and any unavailable or unsupported content. Keep a manifest or other stable identifier for the checked delivery so that a later report can be tied to the same files.
Pin the validator and its coverage
Record the validator name and exact release, package version, or commit, together with the 3D Tiles version and every option or configuration file used. The CesiumGS 3D Tiles Validator README describes support for 3D Tiles 1.0 and 1.1, tileset JSON, implicit tiling, metadata, selected tile-content formats, and .3tz or .3dtiles packages. It lists B3DM, I3DM, PNTS, and CMPT content, and says glTF tile content is checked with the Khronos glTF Validator. These are documented project capabilities, not evidence that a particular installed build or delivery passed.
Options can narrow what a run checks. For example, the README describes validateContentData: false as checking tileset JSON structure without validating tile-content data; includeContentTypes can select content types; and excluding CONTENT_TYPE_TILESET can omit external tilesets. Confirm each option against the exact installed version because the repository’s main branch and its CLI, interfaces, and report details can change.
Keep the enabled checks and exclusions visible. If the delivery uses a format, extension, metadata semantic, or external resource the validator does not cover, record that limit instead of treating absence of an issue as evidence that it was checked.
Preserve the report with its scope
Retain the complete report and the configuration that produced it. The validator documentation describes console and JSON report output; preserve the raw output even when you prepare a shorter summary. Include enough context for someone else to identify the same check:
delivery:
representation_and_version: ""
root_or_package: ""
revision_or_manifest: ""
purpose:
recipient_task: ""
validator:
name_and_exact_build: ""
configuration: ""
included_content_types: []
excluded_checks_or_resources: []
result:
full_report_location: ""
errors_warnings_and_omissions: ""
unresolved_resources: []
recipient_checks:
package_resolution: "not checked"
spatial_alignment: "not checked"
visual_or_task_result: "not checked"
Describe warnings, errors, skipped checks, and unresolved references using the report’s own terms. If results are filtered or summarized, retain the unfiltered report and say what the summary leaves out. A result with no reported issues applies only to the selected checks and input; it does not expand coverage to excluded resources or untested client behavior.
Check the package and recipient task separately
After structural validation, resolve the delivery from a clean location that resembles the recipient’s environment. Confirm that required tile content, subtrees, and external references can be found from the delivered boundary rather than only from the sender’s workspace. If the recipient depends on a network or service, document which resources were actually available during the check.
Then assess spatial alignment, display behavior, and task requirements as separate questions. The OGC specification defines format structure and conformance but leaves visualization behavior to clients. A conforming tileset therefore does not prove that two clients display it identically, that its placement is accurate for the project, or that it is fit for a specific coordination or review task. Define the needed spatial comparison with the applicable spatial context, and exercise the intended recipient operation before making an acceptance decision.
If the delivery changes after validation, identify the new revision and repeat the affected checks. Compare the new report and recipient observations with the accepted baseline; do not carry a previous result forward to a changed package.
For representative-package selection and source-to-destination comparisons, see Test Exchange Packages. For the distinction between conformance and task acceptance, see Conformance, Validation, and Fit for Purpose. A reproducible record should also travel with the CAD handoff.
Key points
- Identify the delivered tileset root or package, exact version, and recipient task.
- Record whether tile content, implicit-tiling subtrees, metadata, and external tilesets were included or excluded.
- Pin the validator build and options, and keep the full report with the delivery revision.
- Check clean-location package resolution, spatial alignment, client display, and recipient task separately from structural validation.
- Repeat affected checks after a transformation or delivery change; report only the claim supported by each result.