-
Notifications
You must be signed in to change notification settings - Fork 921
Book 3.8.3: Naming of onb::local()
#1088
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
"Local" is relative. I can't speak for Peter's original intent, but I would call this a model-to-local coordinate transform. But every space's "world" coordinates is some other space's "model" coordinates, because transforms concatenate. I definitely wouldn't call this a transform to "world space", as we may have many other transforms ahead of us. For example, a given quad has modeling coordinates, but then may be transformed to assemble a box, which is then transformed into the Cornell scene, which is then inverse-transformed by the camera (or not, depending on how you model viewing transforms). All that said, I do agree that |
After thinking about this a bit more, and given the overall generality of the orthonormal basis class, I don't think this can be made any more specific than |
The `onb` class implemented several unused methods, so I've removed them in the interest of simplicity. These include the operator[] methods to retrieve the basis axes, as well as a transform function that took three individual double values. Finally, instead of having an uninitialized form with a `build_from_w()` function, the class now requires a vector at construction time, consistent with our use of the class. I've renamed `local()` to `transform()` for a bit more clarity, without trying to name either the input space or the result space, as "local" means different things at different times, and to different people. Resolves #1088
The `onb` class implemented several unused methods, so I've removed them in the interest of simplicity. These include the operator[] methods to retrieve the basis axes, as well as a transform function that took three individual double values. Finally, instead of having an uninitialized form with a `build_from_w()` function, the class now requires a vector at construction time, consistent with our use of the class. I've renamed `local()` to `transform()` for a bit more clarity, without trying to name either the input space or the result space, as "local" means different things at different times, and to different people. Resolves #1088
Hello, sorry if my question is dumb.
But why is this method called "local",
when we are actually transforming from local space to world space ?
The text was updated successfully, but these errors were encountered: