One issue was with I3dm’s when setting RTC_CENTER, and having the instance positions relative to this RTC_CENTER. The tiles were drawn OK on loading, but after camera movement and/or zoomin the closest tiles did disappear
That sounds like it could be an issue worth tracking. At least, from quickly glancing over the specification of RTC_CENTER in I3DM, it looks like this should be taken into account. If you have example data (preferably, “the same” data, once with the issue and once without it), that could be part of an issue summary.
Now with the 1.1 GPU instancing method I’ve got something similar: trees get shaky when using the ECEF positions
If I understood this correctly, then this happens when putting the actual ECEF tree positions into the TRANSLATION attribute of the EXT_mesh_gpu_instancing.And … in this case, the “jittering” might have to be expected. As you said: The values are simply too large to be represented with 32bit float. And although the translations are not explicitly added to the actual vertex positions, and seem to be conceptually similar to an RTC_CENTER offset: The instancing happens on the level of the GPU itself, with special GL calls, and I assume that’s where the precision is lost.
But I don’t understand why it works allright when I use the ECEF positions in I3dm…
There is some special handling for this.
(The comment there suggests that this may depend on the presence of the RTC_CENTER. This might actually be related to the issue mentioned above: Maybe some of this special handling is not taken into account for some bounding volume/visibility computations or so…, but that would have to be investigated further)
But in general I think it would be easier/less prone to error if we can just use in ECEF positions (instead of something like RTC_CENTER or doing some extra translations) and let CesiumJS figure out the rendering of it. It shouldn’t be too difficult.
If that “It shouldn’t be too difficult” referred to the experience of the developer who uses CesiumJS, then I fully agree 
If it referred to the question of how this (simple, easy to use) behavior could be offered by CesiumJS, then it might be a bit more tricky. But probably not unsolvable. One could probably tackle this with an approach that is similar to the “special handling” that I linked to above:
- Assume that the
TRANSLATIONof theEXT_Mesh_gpu_instancingmight contain large ECEF values - compute the average of these translations
- subtract this ‘average’ from the translations, to obtain the relative translations
- send these relative translations to the GL call that does the instancing
- but… add the ‘average’ as a translation to the model matrix for this call
This would boil down to be an “automatic”, client-side (internal) solution for what you proposed as the workaround:
As a workaround/fix I could probably do an extra node in the GLB with a translation and use relative positions again…
That could solve it. With some degrees of freedom of whether this translation should then be in a node of the glTF, or in a tile transform matrix. I think that the latter might be more flexible, because the GLB could then be “centered at the origin”, which might be easier to digest for other viewers. For example: BabylonJS also tends to choke on glTF assets with large node.translation values, and … you might observe some jittering there. This came up recently in A question about cesium render 3dtiles？ - #2 by Marco13 …