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
A follow-up to #11400 — there are still multiple ways we could make those types stricter and more useful:
Currently we often use [] as an input type for vector/matrix calculations, resolved as Array<number>. The problem with this is that we can't type-check array length of resulting objects (vec/mat2/3/4 can all be interchangeably interpreted as the same type), and arrays are not compatible with tuples that we use for typing uniform inputs like uniform3f. We should probably exclude Array<number> as input type for these methods and replace them with tuples that have explicit length.
We use either Float64Array, Float32Array or Array for matrices inconsistently throughout the codebase. Ideally we would settle on one way of doing this — either always using Float64Array for intermediary calculations and then converting to Float32Array which WebGL expects at the end, or switching to arrays everywhere so that we never loose precision.
A follow-up to #11400 — there are still multiple ways we could make those types stricter and more useful:
[]
as an input type for vector/matrix calculations, resolved asArray<number>
. The problem with this is that we can't type-check array length of resulting objects (vec/mat2/3/4
can all be interchangeably interpreted as the same type), and arrays are not compatible with tuples that we use for typing uniform inputs likeuniform3f
. We should probably excludeArray<number>
as input type for these methods and replace them with tuples that have explicit length.Float64Array
,Float32Array
orArray
for matrices inconsistently throughout the codebase. Ideally we would settle on one way of doing this — either always usingFloat64Array
for intermediary calculations and then converting toFloat32Array
which WebGL expects at the end, or switching to arrays everywhere so that we never loose precision.cc @ansis
The text was updated successfully, but these errors were encountered: