`forceLod` does not reach instanced or raytracing geometry

[cppctamber]

Status:
Consitancy question.

Source version:
Carbon v5.0.0, commit 342fbe5

Notes:
Established from the code paths only as I have no runnable Carbon build, so I could not confirm the visible effect in a client.

Source
TriGeometryRes::GetLodIndexForScreenSize honours a debug override before searching:

if( m_forceLod && m_forcedLodIndex >= 0 )
{
    return int( std::min( m_forcedLodIndex, lastLod ) );
}

Description
forceLod and forcedLodIndex are editable attributes (TriGeometryRes_Blue.cpp:44). Two other sites select a LOD by screen size without consulting it : EveInstancedMeshManager::GetMeshLod (:971) and the raytracing path in EveChildInstancedMeshes (:134-141), which open-codes the search inline. Both read the same thresholds, copied verbatim from m_lods[lod]->m_maxScreenSize (EveInstancedMeshManager.cpp:250 and :312, EveChildInstancedMeshes.cpp:314).

With forceLod on, non-instanced geometry pins to forcedLodIndex while instanced and raytracing geometry keeps selecting by screen size, so the override appears not to work for instanced content. That the searches agree on everything else suggests the copies were meant to match GetLodIndexForScreenSize and just missed the override.

Related: GetMeshLod(ix, 0) and GetMeshLod(ix, 0.f) bind to different overloads with opposite meanings (LOD index 0 = best detail, screen size 0.f = worst). Both forms appear in the codebase.

[cppctamber]

Correction, 2026-07-30. My entry previously claimed the two LOD searches "disagree exactly at threshold boundaries That was wrong: they are equivalent for every input, boundaries included. GetLodIndexForScreenSize returns max{i : t[i] >= s}; GetMeshLod returns min{L : s > t[L+1]}. m_lods is sorted by descending m_maxScreenSize at load (TriGeometryRes.cpp:1113), which makes those expressions equalthe opposite scan directions and the >=/> split cancel.