Status:
Consistency question
Source version:
Carbon v5.0.0, commit 342fbe595b572070e09b583a03e215011f5924e9
Notes
I do not have a runnable Carbon build, so I could not determine whether this distinction is intentional.
Source
TriGeometryRes::GetLodIndexForScreenSize, at TriGeometryRes.cpp:294, scans from coarse to fine and compares the screen size with the current LOD threshold using >=.
EveInstancedMeshManager::GetMeshLod, at EveInstancedMeshManager.cpp:971, scans from fine to coarse and compares with the next LOD threshold using >.
Description
These rules produce different results when the screen size is exactly equal to a threshold. An otherwise equivalent mesh can therefore select adjacent geometry LODs depending on whether it is rendered through the instanced path.
Away from exact threshold values, the two searches appear equivalent.
Is the boundary difference deliberate?
Status:
Consistency question
Source version:
Carbon v5.0.0, commit
342fbe595b572070e09b583a03e215011f5924e9Notes
I do not have a runnable Carbon build, so I could not determine whether this distinction is intentional.
Source
TriGeometryRes::GetLodIndexForScreenSize, atTriGeometryRes.cpp:294, scans from coarse to fine and compares the screen size with the current LOD threshold using>=.EveInstancedMeshManager::GetMeshLod, atEveInstancedMeshManager.cpp:971, scans from fine to coarse and compares with the next LOD threshold using>.Description
These rules produce different results when the screen size is exactly equal to a threshold. An otherwise equivalent mesh can therefore select adjacent geometry LODs depending on whether it is rendered through the instanced path.
Away from exact threshold values, the two searches appear equivalent.
Is the boundary difference deliberate?