-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
Planar projection camera #45
Conversation
5a74541
to
0875644
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good except the change in screen2ray
👇
0875644
to
3988c57
Compare
To resolve the problem that led to the focal point check, maybe the near and far plane distances should be marked as either absolute or relative, where absolute is the current behavior and relative gets multiplied by the zoom factor (matching how the old zoom refactor effectively handled the plane distances). This reduces the complexity of the planar projection by making the relative mode the recommended mode, but increases the complexity of the perspective projection which would need to be recalculated if either depth uses relative mode. |
Regarding the absolute/relative (world/camera?) distance units, does it make more sense to force |
I think this is fine, I still think using a planar camera is a bit of an edge case, so I doubt if a lot of people care. I think the check in |
Revision of #42 to not depend on the zooming functionality of #40. Keeping the near and far planes on the correct side of the focal point is tricky with this logic, resulting in the additional check and adjustment in
set_planar_projection
. Reimplementing this projection using theViewer
trait externally would allow for the alternative zoom logic to make that check unnecessary. However, that solution would make the planar projection incompatible with the built-in control samples.