vertex_positions returns garbage (bit-reinterpreted doubles) for FBX files with double Vertices arrays

[wdw89]

Bug: vertex_positions returns garbage for FBX files with double Vertices arrays

pyufbx version: 0.0.7 (Windows, Python 3.13, installed from PyPI wheel)

Summary

When loading an FBX 7.4 binary file whose Vertices array uses type code d (double), mesh.vertex_positions returns garbage values (denormals / huge powers of two) instead of the actual coordinates. The topology (faces/indices) is correct — only vertex data is corrupted.

Root cause

In src/ufbx_wrapper.c L213-221:

const float* ufbx_wrapper_mesh_get_vertex_positions(const ufbx_mesh *mesh, size_t *out_count) {
    ...
    *out_count = mesh->vertex_position.values.count;
    return (const float*)mesh->vertex_position.values.data;   // ← blind cast
}

ufbx's ufbx_real defaults to double (float requires opt-in via UFBX_REAL_IS_FLOAT). If the extension is not compiled with UFBX_REAL_IS_FLOAT, values.data points to a double buffer, and casting it to const float* makes the Cython layer reinterpret the raw bytes as float32 — a bit-level reinterpretation, not a value conversion.

The same blind cast exists in the other vertex attribute getters (vertex_normals L223, vertex_uvs L233, vertex_tangents L243, vertex_bitangents L253).

Evidence (bit-exact)

Test file: Meshy-exported FBX, Vertices array = 15954 doubles, zlib-compressed.

1. Manual parse of the array header [ArrayLength=15954][Encoding=1][CompressedLength=50087], zlib decompress, read as <f8 → 5318 vertices, all coordinates in ±0.5 (correct).
2. ufbx output vs raw double bytes reinterpreted as float32: bit-for-bit identical (e.g. both produce 0x20000000 = 1.0842022e-19 for the first component; correct value is -0.367188).
3. ufbx output vs correct values cast to float32: all 15954 components differ.

Bit-identical to a byte reinterpretation can only happen with a memcpy-style cast — a real double→float value conversion would produce values close to the correct ones.

Note: world_transform getters correctly use double*, which is why node transforms are fine — only the vertex attribute getters are affected.

Suggested fix

Either:

• compile the extension with UFBX_REAL_IS_FLOAT (then the cast is correct and ufbx does the value conversion internally), or
• keep ufbx_real as double and convert properly in the wrapper (copy into a float buffer, or expose the real element size).

The first option is the one-line fix if float32 precision is acceptable for the Python API.

Repro

import ufbx
import numpy as np, struct, zlib

scene = ufbx.load_file("model.fbx")  # FBX with double Vertices array
vp = np.array(scene.meshes[0].vertex_positions, dtype=np.float64)
print(np.abs(vp).max())   # expect ~0.5, get ~1e19 garbage for ~12% of components

Happy to provide the test FBX if useful.

[wdw89]

Additional finding: ASCII FBX files are equally affected

Follow-up testing with ufbx's own test data (data/*.fbx in this repo's upstream) shows the bug is not limited to binary FBX with double Vertices arrays — ASCII FBX files are corrupted too, because ufbx stores ASCII-parsed arrays as ufbx_real (double) internally, and the same blind cast hits that buffer.

Evidence 1: blender_279_edge_circle_6100_ascii.fbx (unit circle, 256 verts)

Text in file:

Vertices: 0.000000,1.000000,0.000000,-0.024541,0.999699,0.000000,...

mesh.vertex_positions output contains garbage like -27.3756, 1.875, -1.118e-18, and even NaN (3 NaNs in 768 components).

Bit-level proof: the ufbx output is exactly equal to the correct double array's byte stream reinterpreted as <f4, truncated to the first N floats:

text_vals = [0.0, 1.0, 0.0, -0.024541, 0.999699, ...]  # parsed from ASCII
f4s = np.frombuffer(np.array(text_vals, dtype='<f8').tobytes(), dtype='<f4')
out = np.array(scene.meshes[0].vertex_positions).flatten()
np.array_equal(np.nan_to_num(out), np.nan_to_num(f4s[:len(out)]))  # True

So the Cython layer reads the first count float32s out of a double buffer — each vertex's 3 doubles yield 6 f4 slots, and the second half of the data is silently dropped.

Evidence 2: maya_cube_6100_ascii.fbx — the "silent corruption" case

Text values are a plain cube ±0.5. Output is ±1.75 — because the high 4 bytes of double(0.5) (0x3FE00000) read as f4 = 1.75. No NaN, no huge values, no crash: the mesh just renders at the wrong scale/shape. This makes the bug easy to miss in casual testing.

Why this matters

• Affects any FBX whose Vertices end up in a double buffer: binary d arrays and all ASCII files (regardless of how the values are written).
• Corruption can be silent (wrong-but-plausible coordinates), not just obvious garbage.
• The same applies to vertex_normals / vertex_uvs / vertex_tangents / vertex_bitangents getters.

Workaround we're shipping

Parse Vertices ourselves (binary: zlib + type-code aware read; ASCII: regex the text array) and cross-check against mesh.vertex_positions; replace when they disagree. Happy to share the parser if useful.