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 these overload semantics are intentional.
Source
TriFrustum.cpp:236-307.
Description
GetPixelSizeAccross(const Vector3&, float) projects the center onto the view direction and divides by that depth, clamped at 1e-5.
GetPixelSizeAccrossEst(const Vector3&, float) instead divides by:
sqrt( lengthSq - radius^2 )
The remaining overloads choose between these formulas based on the argument type:
Vector4* forwards to the view-depth form at :236Sphere forwards to GetPixelSizeAccrossEst at :295-297AxisAlignedBox forwards through Sphere at :299-306
Equivalent bounds can therefore receive materially different screen-size measurements depending on whether the caller holds a Vector4, Sphere, or AxisAlignedBox.
The formulas particularly diverge off the view axis. The view-depth form can become very large when the projected depth approaches zero or is negative, while the estimated form continues to use center distance.
Both return FLT_MAX when the camera is inside the sphere. Some problematic positions may also be rejected by frustum culling before the result is consumed.
Is the type-dependent choice of estimator intentional?
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 these overload semantics are intentional.
Source
TriFrustum.cpp:236-307.Description
GetPixelSizeAccross(const Vector3&, float)projects the center onto the view direction and divides by that depth, clamped at1e-5.GetPixelSizeAccrossEst(const Vector3&, float)instead divides by:The remaining overloads choose between these formulas based on the argument type:
Vector4*forwards to the view-depth form at:236Sphereforwards toGetPixelSizeAccrossEstat:295-297AxisAlignedBoxforwards throughSphereat:299-306Equivalent bounds can therefore receive materially different screen-size measurements depending on whether the caller holds a
Vector4,Sphere, orAxisAlignedBox.The formulas particularly diverge off the view axis. The view-depth form can become very large when the projected depth approaches zero or is negative, while the estimated form continues to use center distance.
Both return
FLT_MAXwhen the camera is inside the sphere. Some problematic positions may also be rejected by frustum culling before the result is consumed.Is the type-dependent choice of estimator intentional?