Extension for automatic ENU registration

[Marco13]

I think that such an extension could make sense. But extensions should be well thought through, considering the implications: Runtime engines must dedicatedly implement support for that extension. And it’s important to find the right balance between making it 1. simple enough to actually bring a benefit/simplifcation, and 2. still making it powerful enough to offer what users need.

Some further thoughts:

@andreasplesch

There are some additional benefits of making this functionality declarative, in an extension:

• users do not have to know or use the tool or think too much about how this is done since it is now internal to the viewer implementation.
• implementations can approach this in the way they prefer, for example if there is already similar functionality outside of 3d tiles support.

I think focusing a potential extension on just one, limited, well defined target function is possible and would be the most effective. It should be small.

Just to confirm my understanding: The purpose of the extension would then really only be replace the tile.transform - is that correct?

You originally mentioned the bounding volume. And I now think that this was only intended as a possible way to transport the lat/lon/height information. But the bounding volume is still one of the requirements for integrating a glTF into a tileset JSON.

Would that extension include anything that is related to the definition of the bounding volume of the glTF?

The point is: If someone has a glTF and wants to “wrap” that into a tileset JSON to place it somewhere on earth, then having such an extension like { lat: .. lon:... height:...} could be simpler and more intuitive than the transform: [...]. But it will still need a boundingVolume. And if the bounding volume has to be computed with an external tool, then it’s only a small step for that tool to also compute the proper transform…

In fact, one of the most important parts of that createTilesetJson function is the computation of the bounding volume. This is also “simple”, in some way, because it really is just the bounding box of the glTF, converted into the tileset boundingVolume.box representation. But users would still need tooling support for that, i.e. for computing the bounding box of the glTF, converting it into the boundingVolume.box representation, and taking into account the up-axis-conversions, like shown in this snippet.

Maybe the higher-level question is: Which tools would produce tilesets that contain this extension?

---

@andreasplesch

This issue does apply but I did not understand why merging after creating Tilesetjsons for single glTFs is not a good option.

There are many options. And in fact, some of the challenges for the whole topic of “geo-placement” is exactly that there are so many ways of how it could be represented.

(I wrote much, much more here, but that derailed a bit - trying to focus on your point: )

There are the two options:

1. One could create two tileset.json files, each containing one glTF and a geo-locating transform, and the merge them into one tileset.json
2. One could directly create one tileset.json, with two glTF files that should have certain geo-locations

An attempt to illustrate the difference:

I think that the latter is far more flexible and easier to handle. Storing the “geo-locating transform” twice is not ideal. And more importantly: When someone wants to modify this, it can become really challenging: There would be two children, and their transform arrays are

-0.12062712460954786,0.9926978879842713,0,0,-0.7706863170115904,-0.09364951363581787,0.6302954619596158,0,0.6256929738933811,0.07603072923063509,0.7763553507467535,0,3998831.079016911,485915.70577487565,4928505.253901741,1
and
-0.12062712807471718,0.9926978875632031,0,0,-0.7706863166846918,-0.0936495163260206,0.6302954619596157,0,0.6256929736279837,0.07603073141471559,0.7763553507467534,0,3998831.0773207457,485915.71973342943,4928505.253901741,1

What is that?

Yeah, it’s just the same geo-position, twice, but a few meters apart. Having that geo-placement once, and letting the transform of one child just be
1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 10, 0, 0, 1
makes it clear: This is moved 10 meters along x.

Another point is about modifications of these transforms at runtime (in CesiumJS). You’re loading a tileset.json, and have a tile hierarchy like root->children[0]->children[4]->glTF, and the glTF appears at the right place. But you don’t know whether this is caused by one transform of the root, a transform of one of the children, or a combination thereof. This was one of the quirks that made that sandcastle in the other post more complicated, and limitied the applicability of that approach at the same time.

I’m derailing again.
But … maybe not completely:

@andreasplesch

It may be insightful to use
…
as an example to study if in this case such an extension would be helpful. Just an idea.

This is exactly the case that I described above: Someone knows the relative locations of the buildings: “This building is 10 meters left of this one”. It’s more intuitive to describe these relations locally, and then have a single place (at the root of the tileset) that provides the geolocation.

That’s another specific question regarding the extension that you suggested:

Should that extension be applicable to every tile, or only to the root?

(I may silently have assumed that it should only be in the root. But maybe you intended it to be applicable to each tile individually…?)

---

@andreasplesch

This was not explicitly mentioned but including the geospatial placement in the 3D Tileset via an extension makes it completely standalone and transportable.

There are several ways of “representing a geo-location”. And I already summarized some of them elsewhere:

1. the actual geometry (vertex data) contains the position and orientation of the model on the globe (this is not recommended, because it leads to the common “Precisions, Precisions” jittering issues)
2. the model has a certain orientation, and the CESIUM_RTC extension (somehow deprecated…)
3. the glTF node hierarchy (usually the root node) contains the transform that puts the geometry at a certain position/orientation on the globe
4. the glTF model is referred to as tile content in 3D Tiles, and the tile transform contains the proper transform
5. the whole tileset is put to a certain position/orientation with a 1-liner at runtime, by setting its modelMatrix

They are basically sorted by “increasing flexibility”. And I think that the concept of “portability” is important. When you have a glTF that contains a node.matrix that places the geometry at a certain geolocation, then this 1. violates some conventions of glTF, and 2. makes it hard to place this glTF elsewhere.

Option 4. is the most flexibile one if the geolocation should still be encoded in the tileset itself. But this should probably be constrained even more: I think that the actual geo-placement should preferably only happen via the root.transform (and the children[i].transforms should be the identity, or small, local transforms).

@andreasplesch

This of course is true also by just using ECEF coordinates or a matrix transform in the first place but then additional tagging/metadata is needed to confirm to a renderer that the CRS used is indeed ECEF.

Encoding that information explicitly is certainly desirable. There already is a metadata semantic TILESET_CRS_GEOCENTRIC for encoding that information. But one could make a case to store this in/as some extension as well.

@andreasplesch

One consideration is the case of a Tileset using such an extension within a parent Tileset which is also using the extension.

This is one of the things that has to be thought through. There already are a few aspects of “external tilesets” that are a bit vague and could be specified more clearly. But certain (invalid) combinations of features (in tilesets and their external ones) could probably be ruled out easily by the specification of such an extension.