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
Currently, all normal matrices in Jax are calculated with code such as:
mat4.invert imv, modelview
mat3.fromMat4 normal, imv
mat3.transpose normal, normal
This is correct. However, it's also costly. Would it be worthwhile to have Jax check the normal object for a flag such as orthonormal? If true, the normal matrix would be calculated simply by taking the upper 3x3 of modelview; and imv could be calculated by simply taking the transpose of modelview. If the property is false or nonexistent, the slower but safer method is used.
Jax could then manage this flag internally with wrapper classes such as Jax.Camera. The flag has to be explicitly set: if not set by Jax or by the developer (in the off chance that they're directly calculating their own matrices), the slower, more correct version would be used.
Need to investigate whether this is a good idea at all; whether it is architecturally viable; and what, if any, performance gains can be had from this approach. Bonus points for benchmarks.
The text was updated successfully, but these errors were encountered:
Currently, all normal matrices in Jax are calculated with code such as:
This is correct. However, it's also costly. Would it be worthwhile to have Jax check the
normal
object for a flag such asorthonormal
? Iftrue
, the normal matrix would be calculated simply by taking the upper 3x3 ofmodelview
; andimv
could be calculated by simply taking the transpose ofmodelview
. If the property is false or nonexistent, the slower but safer method is used.Jax could then manage this flag internally with wrapper classes such as
Jax.Camera
. The flag has to be explicitly set: if not set by Jax or by the developer (in the off chance that they're directly calculating their own matrices), the slower, more correct version would be used.Need to investigate whether this is a good idea at all; whether it is architecturally viable; and what, if any, performance gains can be had from this approach. Bonus points for benchmarks.
The text was updated successfully, but these errors were encountered: