Different bounding volumes

[pjcozzi]

Point clouds use contents.boundingSphere for the RTC center point. This is not documented yet in README.md. We could put it in the tile itself, but it belongs here instead if 3D Tiles allow bounding spheres as a potential bounding volume, which I suspect we will.

[mpgerlek]

+1

[pjcozzi]

Until we flush out the bounding volume, Cesium is deriving the bounding sphere from the bounding box: https://github.com/AnalyticalGraphicsInc/cesium/pull/3158/files#diff-e51181d6e2f4fd006b1404f2fe1f65a2R58

Not optimal, but only temporary.

[pjcozzi]

I'm not ready to fully design this quite yet, but I am thinking we will replace tile.box and tile.content.box with something like tile.boundingVolume/tile.content.boundingVolume, which would be a dictionary object like:

boundingVolume : {
    sphere : //
    box : // a true box in Cartesian space
    region : // a "box" in Cartographic space, what "box" currently is
    ...
}

I think box would be an AABB in the tilesets coordinate system (which we would need to store in tiles.json) so, for example, cities with a principal bearing axis of 45 degrees or point clouds with arbitrary orientation can be subdivided optimally instead of just slicing longitude/latitude/height.

There may also be a need for box to be an OBB (or for separate AABB and OBB properties).

Perhaps the spec will allow multiple bounding volumes to be declared in boundingVolume so the client can pick the optimal one for the task, e.g., a k-DOP may be used for collision detection and a sphere may be used for culling.

Is allowing multiple bounding volumes overkill, e.g., the union of children bounding volumes is a better fit than a parent's bounding volume so it can be useful to test the parent, then children bounding volumes before rendering the parent. This can be done with the current tiles.json schema. Is something more general worth the complexity?

[e-andersson]

Is there anything I can do to help on this? I think we'd like to use a bounding sphere for the root tile in a global tileset scenario, so we can have a root covering the whole globe.

[pjcozzi]

Yes, you are welcome to do all of it. 👍

In Cesium, here are the types of interest:

• BoundingSphere
• AxisAlignedBoundingBox
• OrientedBoundingBox

I have also toyed with the idea that we only need AABB, not OBB, since the tileset should be able to define a local coordinate system, e.g., for point clouds or cities that are not subdivided on longitude/latitude boundaries, so the tiles would use an AABB in the tileset's coordinate system, which would be an OBB in WGS84. I dunno, it will need some implementation work to be sure.

To get started, perhaps you could just do the least amount needed to the spec and Cesium to add support for bounding spheres. Then we can see how to scale it to AABB/OBB (should be obvious).

What do you think?

[e-andersson]

That's generous 😄

Sounds good, I'll have a go at adding support for bounding spheres and then we'll see about the other types.

[pjcozzi]

Awesome! Looking forward to you progress.

[pjcozzi]

Spec updates: #51