Computing final ECEF position of vertex arrays inside B3DM/GLTF

[mlfarrell-convene]

Been struggling with this for days now. Can someone please explain to me whether or not this is correct.

I have binary GLTF data that has a CESIUM_RTC value. I've interpreted that to mean that the data itself is in the ECEF coordinate system. I've confirmed that by rotating the data to ENU via multiplying an inverse orientation matrix who's columns are formed by the local ENU vectors (computed from ECEF CESIUM_RTC converted to lat/long)

However, when converting the per-vertex ECEF values to LLH (using algorithm )https://www.mathworks.com/matlabcentral/fileexchange/7941-convert-cartesian--ecef--coordinates-to-lat--lon--alt?focused=5062924&tab=function), I get wildly incorrect height values and arbitrarily rotated 3D data with respect to LAT/LON plane.

My question: is the proper way to determine the ECEF position of an embedded vertex inside B3DM/GLTF to simply add the cesiumRTC position to it? And If so, why the heck am I getting wrong values when converting cesiumRTC+pos values to wgs84 LLH??

[mlfarrell-convene]

Answering my own question for others.

The answer was no. The per-vertex position data inside the GLTF are in Y-up but the ECEF center IS NOT. It is in Z-UP. So somehow the position data is in some weird ECEF-but-not-really coordinate system where Y is up.

Conversion Solution:
rotate position by X axis 90 degrees
add result to cesiumRTC
convert result to LLH->ECEF
counter rotate by X axis -90 degrees if Y-up is needed for OpenGL

Please document this better if you can. I lost almost 2 days to this.

[lilleyse]

Sorry about the confusion, we plan on clarifying this better in the spec this coming month.

There is a little more background here: #280 (comment). As in that comment I recommend setting tileset.json asset.gltfUpAxis to Z so the entire pipeline (including renderer) is z-up.

[ggetz]

Resolved in #301