Status:
Confirmed from source
Source version:
Carbon v5.0.0, commit 342fbe595b572070e09b583a03e215011f5924e9
Notes
I do not have a runnable Carbon build, so this was not reproduced at runtime.
Source
Eve/SpaceObject/Children/EveChildLineSet.cpp:212, currently:
m_currentScreenSize = frustum.GetPixelSizeAccross( &m_boundingSphere );
Description
Updated
EveChildLineSet calculates screen size from a local-space bounding sphere, probably should be:
m_currentScreenSize = frustum.GetPixelSizeAccross( &sphere );
Why: m_boundingSphere is local-space. sphere is that same sphere transformed to world space at :208 for the frustum test two lines above, then discarded. :212 is the only site in the class that reads the member untransformed. The accessor at :263 and the debug draw at :540 both transform it first, so local storage is deliberate and each consumer converts.
Effect: LOD measures distance from the world origin instead of the camera, on an unscaled radius, so a line set lods by where it happens to sit in space. The Vector4* overload is also the depth estimator (TriFrustum.cpp:245, entry 4), so the error is not a bounded offset.
Related question
No scene lodFactor is applied anywhere in EveChildLineSet, so a user LOD-quality setting does not reach line sets. Not a lone holdout as only five children apply one (EveChildCloud, EveChildCloud2, EveChildMesh, EveChildParticleSystem, EveChildQuad), and they disagree on direction (EveChildCloud.cpp:224 multiplies by GetLodFactor(), EveChildMesh.cpp:378 uses GetInvLodFactor() — entry 2), so no sibling is citable as the correct pattern. Intentional or not is undetermined.
Status:
Confirmed from source
Source version:
Carbon v5.0.0, commit
342fbe595b572070e09b583a03e215011f5924e9Notes
I do not have a runnable Carbon build, so this was not reproduced at runtime.
Source
Eve/SpaceObject/Children/EveChildLineSet.cpp:212, currently:Description
Updated
EveChildLineSet calculates screen size from a local-space bounding sphere, probably should be:
Why:
m_boundingSphereis local-space.sphereis that same sphere transformed to world space at:208for the frustum test two lines above, then discarded.:212is the only site in the class that reads the member untransformed. The accessor at:263and the debug draw at:540both transform it first, so local storage is deliberate and each consumer converts.Effect: LOD measures distance from the world origin instead of the camera, on an unscaled radius, so a line set lods by where it happens to sit in space. The
Vector4*overload is also the depth estimator (TriFrustum.cpp:245, entry 4), so the error is not a bounded offset.Related question
No scene
lodFactoris applied anywhere inEveChildLineSet, so a user LOD-quality setting does not reach line sets. Not a lone holdout as only five children apply one (EveChildCloud,EveChildCloud2,EveChildMesh,EveChildParticleSystem,EveChildQuad), and they disagree on direction (EveChildCloud.cpp:224multiplies byGetLodFactor(),EveChildMesh.cpp:378usesGetInvLodFactor()— entry 2), so no sibling is citable as the correct pattern. Intentional or not is undetermined.