Move CESIUM_RTC to the feature table for b3dm

[lilleyse]

Now that b3dm tiles have a feature table, it would probably make sense for RTC_CENTER to exist in the feature table. It's still worth supporting CESIUM_RTC as a glTF extension, but the feature table RTC_CENTER seems preferable from a spec point of view.

[pjcozzi]

Would this eliminate the need for the CESIUM_RTC extension? Can you draft up a quick schema example?

[pjcozzi]

@lilleyse is it realistic to scope this for 1.0? E.g., can this be done in one day or less and is it easy for Cesium to preserve backwards compatibility for existing tilesets and exporters?

[lilleyse]

This is in scope for 1.0. It seems like less than one day of effort and should not affect backwards compatibility with the CESIUM_RTC extension.

This could also be a good item to add to the upgrade command in 3d-tiles-tools - https://github.com/AnalyticalGraphicsInc/3d-tiles-tools/issues/142

[ggetz]

Resolved in #301

[caohaoze]

I think we should add Local_Geo_Center to b3dm, rather than RTC_CENTER, because the geo-position can be applied to different ellipsoid.
For example, if we don't use the WGS-1984 ellipsoid, the b3dm with RTC_CENTER may not be placed on the surface of the new ellipsoid accurately.
If we store the Local_Geo_Center with (lon, lat, height), we can use Cesium to calculate the matrix before rendering. This setting can make the data adapt to any kind of ellipsoid.

[caohaoze]

@lilleyse

[lilleyse]

Hey @caohaoze, for now we are just trying to preserve the functionality of CESIUM_RTC. We may look into #286 for post-1.0 plans.

[lilleyse]

In response to using other ellipsoids at runtime - the tiles would be positioned correctly but wouldn't the tile contents not fit properly? Either there would be intersections at the edges for smaller ellipsoids or gaps for larger ellipsoids.