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 }}
This repository has been archived by the owner on Jul 19, 2020. It is now read-only.
Currently it is possible for coodinates to vary in XYZ component freely. This causes no issues with any algorithms, but it does force those algorithms to normalize the XYZ component often to get the direction a ray travels, or to get the magnitude of the component. If the XYZ component were kept at a length of 1.0 at all times, it would simplify several algorithms, such as Levenberg-Marquardt (and jacobians in general), computing residuals (dot product could always be done with no concern at all for normalizing), checking chirality, and many others. Based on how often normalization happens, this might be helpful. Unfortunately, this does have the downside that normalization must be done every time the coordinate is updated, which might be costly (square root and division may take a while).
If this were to be done, it may be possible for a point to fail conversion. Due to this, an option will need to be returned, meaning that the From impl will have to be removed, which causes some code churn.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently it is possible for coodinates to vary in XYZ component freely. This causes no issues with any algorithms, but it does force those algorithms to normalize the XYZ component often to get the direction a ray travels, or to get the magnitude of the component. If the XYZ component were kept at a length of 1.0 at all times, it would simplify several algorithms, such as Levenberg-Marquardt (and jacobians in general), computing residuals (dot product could always be done with no concern at all for normalizing), checking chirality, and many others. Based on how often normalization happens, this might be helpful. Unfortunately, this does have the downside that normalization must be done every time the coordinate is updated, which might be costly (square root and division may take a while).
If this were to be done, it may be possible for a point to fail conversion. Due to this, an option will need to be returned, meaning that the
From
impl will have to be removed, which causes some code churn.The text was updated successfully, but these errors were encountered: