Bounding volume validation

[javagl]

• Fixes Validate that geometry is fully contained in bounding volumes #233
• Requires a version of the 3D Tiles Tools that includes Bounding volume generalizations 3d-tiles-tools#189

The 3D Tiles Validator Roadmap (that will have its 10th birthday soon) casually contained the point

The tile's content needs to be strictly inside the parent tile's boundingVolume. See Bounding volume spatial coherence.

Even though this issue is outdated, this specific check was still on the roadmap via #233 . This issue already contains a description of the task, and some thoughts about how to address it. There are some aspects to that that can be a bit tricky. And the roadmap issue also mentioned:

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.

But it can be nearly trivial when there are the right building blocks that the functionality can be assembled from. A crucial part of the current implementation here is the generalization that is part of CesiumGS/3d-tiles-tools#189 : It offers a VertexProcessing class that can be called like this:

    // The consumer that will receive all vertices of the content
    const consumer = (p: number[]) => {
      // Do something with that point...
    };

    // Process the vertices, passing each vertex to the consumer
    await VertexProcessing.fromContent(
      contentUri,
      data,
      externalGlbResolver,
      true,
      consumer
    );

It can receive PNTS, GLB, CMPT, B3DM, or I3DM content data, and will simply pass all vertices to that "consumer" (including the transforms from I3DM data, or things like the RTC_CENTER from the feature table).

The 3D Tiles Tools PR also contains a few BoundingVolumesContainment utility functions, for checking whether a certain point is contained in a certain bounding volume.

So this PR now adds a ContentDataBoundingVolumeValidator class that brings this together:

• It traverses the tile hierarchy
• For each traversed tile, it computes the bounding volumes of the tile and all its ancestors
• For each content of the traversed tile, it processes the vertices with the VertexProcessing function
• Each vertex is checked for containment in the tile bounding volumes and the content bounding volume using the BoundingVolumesContainment functions
• It counts the number of vertices that are not contained in the bounding volumes
• When there are >0 vertices that are not contained in the bounding volumes, validation issues are generated

The validation issues contain some additional details. For example, when there is a tile bounding volume that does not contain all vertices, then an issue like this will be generated:

{
  "type": "CONTENT_NOT_ENCLOSED_BY_BOUNDING_VOLUME",
  "path": "unitCube.glb",
  "message": "The bounding volume of tile /root/children/0 does not contain 12 of the 24 vertices of content 'unitCube.glb'",
  "severity": "ERROR"
}

It includes a short description of the actual tile (/root/children/0 here), and information about how many vertices have not been contained.

When there is a content bounding volume that does not contain all vertices, then it will cause the following issue:

{
  "type": "CONTENT_NOT_ENCLOSED_BY_BOUNDING_VOLUME",
  "path": "unitCube.glb",
  "message": "The content bounding volume for content 'unitCube.glb' does not contain 12 of the 24 vertices",
  "severity": "ERROR"
}

---

Remaining tasks:

Integrating it

Nothing of that is wired in yet. I tested it with a local standalone application that only called this validation function. It is not entirely clear where and how it should be integrated: This validation is rather expensive. It should probably be disabled by default, and only enabled via some --checkBoundingVolumeContainment flag. Therefore, I'd probably not wire it in "too deeply" into the main validation functionality. I.e. I think that it should not be done as part of the main content validation. Instead, it should be a step that is performed after the general validity of the tileset already has been checked.

Minor updates of other validators

As mentioned in #233 (comment) : There are some containment checks in the Maxar extension validators. These could be updated in terms of the issue type, as well as the coverage of the bounding volume types.

Tests

I locally have >20 test cases, covering ...

• valid cases with PNTS/B3DM (both with an without RTC), I3DM, and GLB, the latter with various configuations of (nested) tile transforms, and box/sphere/region bounding volumes
• invalid cases (all based on GLB - this does not matter), with different (nested) tile transforms and bounding volume types
• valid and invalid cases for implicit tilesets, with explicit checks for CesiumJS ignores bounding volume metadata for implicit tilesets cesium#13195

These will be added as unit tests soon.

EDIT: There probably should be a dedicated test case with an external tileset as well (e.g. an external tileset attached to a tile that has a non-identity transform)

[javagl]

The last commits added a set of specs.

There is an issue mentioned at CesiumGS/cesium#13195 (comment) that remains to be resolved before finalizing this PR.

[javagl]

This was tested with the current state of CesiumGS/3d-tiles-tools#189 , meaning that it can become "ready" as soon as this PR is merged and a new released of the tools is available.

[javagl]

The dependency for the 3D Tiles Tools has been updated to 0.5.3, which includes the bounding volume containment validation functions.

Some validation for MAXAR_extent that was introduced recently does not yet handle bounding boxes or spheres. I'll have a closer look to see whether this part can now call the generalized containment validation functions. (Not critical or important, but would be "nice to have").