Bone index 0 is not treated consistently by attachment sets

[cppctamber]

Status:
Engineering note.

Source version:
Carbon v5.0.0, commit 342fbe595b572070e09b583a03e215011f5924e9

Content version:
TQ build 3444265

Note
I do not have a runnable Carbon build, this was identified during testing of my JS GR2 tools where I'd asserted bone 0 could not be animated.

Sources

• EveSpriteSet.cpp
• EveBannerSet.cpp
• EveHazeSet.cpp
• EvePlaneSet.cpp
• EveSpotlightSet
• EveSpriteLineSet
• Utilities/BoundingBox.h
• EveBannerSet.cpp
• EvePlaneSet.cpp

Description
Several attachment update paths accept only bone indices greater than zero:

• EveSpriteSet.cpp:146
• EveBannerSet.cpp:168
• EveHazeSet.cpp:223
• EvePlaneSet.cpp:252 and :391
• EveSpotlightSet.cpp:154
• EveSpriteLineSet.cpp:156

For example:

if(
    light.lightData.boneIndex > 0 &&
    light.lightData.boneIndex < boneCount
)

Other paths explicitly accept bone 0:

• Utilities/BoundingBox.h:72
• EveBannerSet.cpp:424
• EvePlaneSet.cpp:338

Sprite geometry also accepts bone 0 at EveSpriteSet.cpp:196-197:

auto boneIndex = m_spriteData[i].boneIndex;
if( boneIndex < boneCount )
{
    TriMatrixCopyFrom3x4(
        &m,
        &bones[boneIndex]
    );
}

The packed sprite index is uint32_t, so this is effectively an upper-bound check. Index 0 is accepted.

Meanwhile, -1 is used elsewhere as the explicit no-bone sentinel, while set items and SOF records generally default their bone index to 0. This makes bone 0 both a real bone and the value carried when nothing assigns another index.

If bone 0 is animated, sprite geometry can follow it while the associated light path does not.
The apparent justification occurs at EveSpaceObject2.cpp:3263.
I found no assertion or import-time validation enforcing that assumption.

// We're assuming for now that the bone 0
// isn't animated for performance reasons.
if( locator.boneIndex <= 0 )

My JS GR2 content scan produced:

Tree	Files	Files with animations	Bone-0 tracks	Animated bone 0
dx9/model/ship	5,064	480	2,109	0
Other space-object trees	6,060	662	2,384	8

No ship animated bone 0.
Eight non-ship assets did: four rotating container models and the corresponding _lowdetail variant of each.

deployables/generic/container/standard/standardcs.gr2
deployables/generic/container/standard/standardcm.gr2
deployables/generic/container/standard/standardcl.gr2
deployables/generic/container/bio/biocs.gr2

Each has a two-bone ["root", "end"] skeleton. The keyed rotation is on root, at index 0.

This shows that “bone 0 is static” is not a universal space-object asset invariant. I could not locate the containers’ .black records, so I could not establish whether any affected asset uses attachment sets whose bone-0 paths differ.