-
Notifications
You must be signed in to change notification settings - Fork 2
Cursor mode #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
base: master
Are you sure you want to change the base?
Cursor mode #23
Conversation
…amera in a similar fashion to RealMyst/Myst V.
…ges the camera near the edge of the screen.
| { | ||
| // rotate the camera in accordance with how close the cursor is to the edge of the screen | ||
| this->AddPitchInput( | ||
| VerticalMouseNudgeThreshold - (1 - VerticalMousePosition)); |
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.
Not certain this is the right expression. We would want the amount nudged to be proportional to how much of the threshold has been moved across. If the cursor has barely impinged into the threshold, let's say 1% of the threshold, then this pitch input argument would be VerticalMouseNudgeThreshold * 99%. If the cursor has impinged a lot (50%), the number would be less, VerticalMouseNudgeThreshold * 50%. Does that sound right? Either way, some more explicit variable names would make things a bit clearer. For instance
auto farImpingement = FMath::Clamp(1 - VerticalMousePosition, 0.0f, 1.0f);
auto nearImpingement = FMath::Clamp(VerticalMousePosition, 0.0f, 1.0f);
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.
in testing the current code appears to do just that - if the cursor is closer to the edge, the camera moves faster. if nearer to the center, it moves slower.
intent was to avoid making more variables/function calls than necessary.
may be more of a style thing. happy to use clamp instead if desired.
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.
OK, I think I ironed out why this is weird to me: the bigger the threshold is, the more the maximum camera spin velocity will be. Basically you have v = t - y where v is velocity, t is threshold size, and y is measured coordinate. The maximum velocity will be y = 0, so v = t - 0 = t. So v is proportional to t. What seems more natural to me would be v = (displacement of cursor into threshold region) / (size of threshold region). In other words, for the top region, that'd be v = y / t and so on.
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.
i see what you're saying. it's a bit counter-intuitive but knowing that the screen space in this function is measured from -1.0 to 1.0 it seemed to be the method that required the fewest calculations and function calls. also, the commit last night allows for a multiplier so you can have a really small threshold and a really fast (or slow) turn rate.
|
Let's also revert the commit with the file mode changes (as I'm guessing that was accidental), unless there's a reason not to. |
|
looks ok. you may want to run |
…rsor nudges the camera near the edge of the screen." This reverts commit f4ea2f7.
-updated comments and formatting in accordance with team style
Updates cursor mode to the camera pans similarly to realMyst or Myst V.