How to read and parse meshes?

Hi all,

I am trying to read and parse meshes (positions) from a b3dm file.
For instance, I know the following things from the parsed gltf:

buffers:
binary_glTF:
byteLength: 61977
type: “arraybuffer”
uri: “data:,”

bufferViews:
ID100:
buffer: “binary_glTF”
byteLength: 52200
byteOffset: 1077
target: 34962

accessor:
ID113:
bufferView: “ID100”
byteOffset: 0
byteStride: 24
componentType: 2126
count: 2175
max: Array[3] [-56.52291, 53.968422, -104.452774]
min: Array[3] [-190.10187, 34.01508, -277.79056]
type: “VEC3”

I am reading the coordinates in the following way:

function decodeVertices(glb, bufferView, rtc) {
var count = 2175; // number attributes
var byt = 4; // byte
var byteStride = 24; // stride between the elements
var dv = new DataView(glb.buffer, bufferView.byteOffset, bufferView.byteLength);
var res = ;
for (var i = 0, j = 0; i < count; i += 3, j += byteStride) {
var val = new Array(3);
val[0] = dv.getFloat32(j, true);// + rtc.center[0]; // get first component
val[1] = dv.getFloat32(j + (byt * 1), true);// + rtc.center[1]; // get second component.
val[2] = dv.getFloat32(j + (byt * 2), true);// + rtc.center[2]; // get third component.
res[i] = val;
console.log('Vals: ’ + val[0] + ', ’ + val[1] + ', ’ + val[2]);
}
return res;
}

``

I get the following results:
Vals: 7.207591074455699e+31, 3.231399467707032e-18, 2.577634550249286e-9
Vals: 2.52259088235218e-18, 6.409691111208815e-10, 3.136870305473835e+27
Vals: 2.7086146658916732e-9, 0.00004367362998891622, 1.4250735797288833e+22
Vals: 2.522595018255243e-18, 1.1721528993864758e+27, 2.308287458743785e-12
Vals: 2.920964398020279e+32, 4.5448218236123114e+30, 4.8393493987304744e+30
Vals: 3.2850787331732012e-18, 6.480466163694132e-10, 3.602292509424787e-12

When adding the rtc.center coordinates, some positions look fine, but some don’t. Especially, some huge values (e.g. the first one 7.207591074455699e+31) make me skeptical.

Am I doing something fundamentally wrong? Or is there another way to read the positions of the meshes?

Thanks in advance!

Just a guess here… Since glb looks to be a typed array, it’s possible you may need to factor its byte offset into the DataView’s byteOffset:

var dv = new DataView(glb.buffer, bufferView.byteOffset + glb.byteOffset, bufferView.byteLength);

``

Also if the glb is a typed array of the whole glb, you will need to offset correctly into the binary body with 20 + contentLength: https://github.com/KhronosGroup/glTF/tree/master/extensions/Khronos/KHR_binary_glTF

Thank you, Sean!
Combining both answers did the trick. :slight_smile:

Hi Sean,

I am working on the same code as mentioned in this thread. But I am having trouble making sense of the coordinates of the vertices.

As it seems to me, the coordinates for each vertex are written as follows in the buffer: (east, up, south). Both the "south" instead of "north" (minus sign) and the ordering ("up" as second coordinate instead of third) seem a little strange to me. Perhaps we are having a wrong offset?

Furtermore, these values seem to be in m, and relative to the center point defined in CESIUM_RTC.

In the gltf data, a single Node is defined consisting of a transformation matrix.

To get to WGS84 coordinates I tried to apply the transformation matrix on the local coordinates vector (east, up, south). Then add the RTC vector and finally convert these (ECEF) coordinates to WGS84. Unfortunately this doesnt seem to be correct.

Could you give me some pointers to what might be going wrong?

Thnx!

It’s hard for me to say what space the vertex coordinates are in, but they look like Cartesian coordinates relative to the CESIUM_RTC, with y being the up-axis. With that assumption, to transform each vertex to WGS84 you should apply the node transform, then apply a y-up-to-z-up transform (https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Axis.js#L53), then add the RTC, then the ECEF->WGS84 conversion.

Thanks Sean! The y-up-to-z-up transformation was the missing transformation!