You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
🐛[BUG]: Float16 cell areas, cell normals, and Butterfly subdivision overflow, though the results fit in float16 #2248
While making mesh transforms, Loop subdivision, and sampling work on float16 meshes in #2230, I found more places where float16 intermediates overflow, though the results fit in float16. #2230 does not fix them.
cell_areas and cell_normals build cross products and determinants in float16, whose maximum is 65504. A right triangle with legs of 300 has an area of 45000, which fits in float16. Its area is inf in 2D, and in 3D both its area and its normal are nan.
Butterfly subdivision adds positions in float16, so an open mesh near x = 33000 gets infinite edge points. Linear subdivision is not affected.
With #2230, transform updates cached areas and normals in float32. So scale(300.0) on a float16 triangle with legs of 1 gives a finite area if it was cached before the call, and inf (2D) or nan (3D) if not.
Expected: finite areas, normals, and subdivided points whenever they fit in float16. One fix is to compute in at least float32 and cast the result back once, as #2230 does for Loop subdivision.
I've opened #2262 for this, following the #2230 pattern: cell_areas, cell_normals, and Butterfly subdivision compute in at least float32 and cast back to the input dtype once. Your repro now gives 44992. and [0., 0., 1.] with no inf edge points, and scale(300.0) gives the same result whether or not the areas were cached. Float32 and float64 are unchanged, and the full test/mesh suite passes on CPU.
Activity
AshfaqueAhbab commentedon Nov 13, 2026
I've opened #2262 for this, following the #2230 pattern:
cell_areas,cell_normals, and Butterfly subdivision compute in at least float32 and cast back to the input dtype once. Your repro now gives44992.and[0., 0., 1.]with no inf edge points, andscale(300.0)gives the same result whether or not the areas were cached. Float32 and float64 are unchanged, and the fulltest/meshsuite passes on CPU.