Skip to content
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

updating Camera.changed to account for changes in roll #11844

Merged
merged 4 commits into from Feb 23, 2024

Conversation

malaretv
Copy link
Contributor

@malaretv malaretv commented Feb 21, 2024

Description

I attempted to fix the remaining issues with #9365, which I think was closed prematurely.

Current behavior: For cases where camera is not pointed straight down to surface twistLeft/Right do not cause a Camera changed event to fire.

Attempted fix: Add a similar check performed for heading to be also performed for roll. This seems to properly cause the change event to be triggered. I do not know if this is the most optimal fix, just copying what was done by others to handle this case too.

Issue number and link

#9365 Can open a new issue if appropriate

Testing plan

I added a test case that listens for the Camera changed event for twistLeft after first telling the camera to lookUp by 45deg. This test failed before my changes, and passed after my changes.

Author checklist

  • I have submitted a Contributor License Agreement
  • I have added my name to CONTRIBUTORS.md
  • I have updated CHANGES.md with a short summary of my change
  • I have added or updated unit tests to ensure consistent code coverage
  • I have update the inline documentation, and included code examples where relevant
  • I have performed a self-review of my code

@ggetz
Copy link
Contributor

ggetz commented Feb 21, 2024

Thanks @malaretv! I can confirm we have a CLA on file for you.

camera._changed.raiseEvent(
Math.max(rollChangedPercentage, headingChangedPercentage)
);
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed there is no early return in the heading check previously. I believe this is because the function needs to clone the frustum before exiting, as is done below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that makes sense. I'll remove the early return since previous behavior was okay.

I was trying to avoid the event maybe being fired multiple times, but maybe that is a non-issue -- or at the very least outside the scope of this one.

Thanks for the review!

Copy link
Contributor

@ggetz ggetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your PR! I just have one comment.

@malaretv
Copy link
Contributor Author

Thank you for the review @ggetz . I've addressed the one comment

@ggetz
Copy link
Contributor

ggetz commented Feb 23, 2024

Looks good! Thanks @malaretv!

@ggetz ggetz merged commit ba6f5a3 into CesiumGS:main Feb 23, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants