Question Overwatch 2 Bone Structure — Transformations and MeshComp Offsets

[byte_corvus]

Anyone digging into the OW2 skeletal mesh lately? Tried to update an old internal and the bone transformations are giving me a headache. The pipeline for reading the bone data seems solid, but the results are either squished at the base or fanning out into the void depending on how the rotation is handled.

Confirmed Data Chain:

1. MeshComp + 0x8B0 —> BoneData pointer
2. BoneData + 0x20 —> BoneBase
3. BoneData + 0x00 —> BoneList
4. BoneList + 0x66 —> Bone Count (usually 13 for players)
5. BoneList + 0x38 —> ID Table

The Logic Issue:
The stride appears to be 0x30. Reading the Vec3 at +0x20 identifies local values that look like (0.6, 0.8, 0.7). If you just add these to the entity origin (MovComp + 0x90), everything clusters at the player's feet. If you try to apply the yaw from MovComp + 0x80 (converted from uint16), the bones fan out horizontally based on distance from the camera.

Spoiler: Current Bone Reading Implementation

static inline int ReadBones(uintptr_t meshComp, uintptr_t movComp, const Vec3& origin, Vec3* out, int maxBones) {
    if (!AddrValid(meshComp) || !out || maxBones <= 0) return 0;
    const uintptr_t boneData = mem::Read<uintptr_t>(meshComp + 0x8B0);
    if (!AddrValid(boneData)) return 0;
    const uintptr_t boneBase = mem::Read<uintptr_t>(boneData + 0x20);
    const uintptr_t boneList = mem::Read<uintptr_t>(boneData + 0x00);
    if (!AddrValid(boneBase) || !AddrValid(boneList)) return 0;
    const uint16_t boneCount = mem::Read<uint16_t>(boneList + 0x66);
    if (!boneCount || boneCount > 200) return 0;
    const uintptr_t idTable = mem::Read<uintptr_t>(boneList + 0x38);
    if (!AddrValid(idTable)) return 0;
    uint32_t id_table[200];
    if (!mem::ReadBuf(idTable, id_table, boneCount * sizeof(uint32_t))) return 0;
    const size_t bufSz = (size_t)boneCount * 0x30;
    char* buf = (char*)malloc(bufSz);
    if (!buf) return 0;
    if (!mem::ReadBuf(boneBase, buf, bufSz)) { free(buf); return 0; }
    memset(out, 0, sizeof(Vec3) * maxBones);
    int highestId = 0;
    for (int i = 0; i < (int)boneCount; ++i) {
        const int bid = (int)id_table[i];
        if (bid < maxBones && bid > highestId) highestId = bid;
    }
    for (int i = 0; i < (int)boneCount; ++i) {
        const uint32_t boneId = id_table[i];
        if (boneId >= (uint32_t)maxBones) continue;
        const Vec3* local = reinterpret_cast<const Vec3*>(buf + i * 0x30 + 0x20);
        if (!std::isfinite(local->x) || !std::isfinite(local->y) || !std::isfinite(local->z)) continue;
        out[boneId] = { origin.x + local->x, origin.y + local->y, origin.z + local->z };
    }
    free(buf);
    return highestId + 1;
}

Technical Roadblocks:

1. Are these positions relative to the skeleton root or the world? Entity origin is correct since 3D boxes draw perfectly, but bones don't follow the same linear translation.
2. Rotation handling — the engine uses a specific compression for rotations. Applying raw yaw from MovComp seems to be missing the transformation matrix or parent-child bone hierarchy.
3. Stride check — Is 0x30 still the confirmed layout for the skeletal mesh buffer? The Local Vec3 at +0x20 might just be a component of a larger matrix (3x4 or 4x4).

If anyone has managed to get a clean bone draw without the horizontal fanning, drop a hint on the transformation logic. I suspect we're missing a final multiply against the component's world matrix or a bone-parent offset.

Anyone tested this on the latest patch?