cesium icon indicating copy to clipboard operation
cesium copied to clipboard

Fix camera zoom issue when tracked entity set or after execute lookAt function

Open Leafmire opened this issue 4 months ago • 2 comments

Description

This PR addresses the issue where the zoom beyond the target point by ignoring pickPosition results (intersection) that are farther than the target point when controller._globe is set to undefined (when the trackedEntity set or the camera's lookAt function is executed).

Before fix

https://github.com/user-attachments/assets/5565ebcc-1f06-442f-a229-0d4bf9e77d4f

https://github.com/user-attachments/assets/b2432fdc-1800-4c6b-b42c-90a5635eee46

After fix

https://github.com/user-attachments/assets/fa7d12e3-bea7-44d3-b17a-09c6d85c57e4

https://github.com/user-attachments/assets/2883ce0e-6e48-4355-9a35-fab456615600

Issue number and link

Fixes #12812 Fixes #12645

Issue scenario

The primary scenarios where this issue occurs are as follows:

  1. Setting trackedEntity or executing the camera's lootAt function toward a specific target.
  2. Moving the camera's center to an “empty” area of the target + a state where another target exists beyond it (in this case, terrain).
  3. Zooming in using the mouse wheel or right-click drag causes the camera to zoom past the target and focus on the target beyond it.

For easy reproduction, I've attached a sandcastle visualizing the ray toward the point the camera is looking at. Aircraft model example Box model example - This case more clear to test issue. lookAt example - This is default CesiumJS example showing cloud.

Main problem

In the Zoom3D function, the issue occurs because the surface of the target in the camera's direction does not exist, so, the intersection point obtained via pickPosition to point to another target beyond the intended target.

Changes

In this code, it appeared that controller._globe was used to determine whether the state was tracked or in look-at mode. So, after calculating the intersection, Check the state of controller._globe and, if a location farther than the target's distance was picked, ignore the intersection.

The initial approach involved early escape during the intersection calculation phase, but this was discarded because it caused several unintended behaviors.

For example, in the case of a balloon Hot Air Balloon zooming normally stops at the balloon's outer surface. However, if the intersection is ignored without distance conditions, zooming will proceed toward the center of the bounding sphere inside the balloon.

So, I implemented it to perform an additional check based on distance conditions after calculating the intersection.

Testing plan

I apologize for not familiar with creating file-based tests. I tested using the sandcastle in the Issue scenario at the top and several built-in sandcastles.

Author checklist

  • [x] I have submitted a Contributor License Agreement
  • [x] 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 updated the inline documentation, and included code examples where relevant
  • [x] I have performed a self-review of my code

Leafmire avatar Oct 24 '25 07:10 Leafmire

Thank you for the pull request, @Leafmire!

:white_check_mark: We can confirm we have a CLA on file for you.

github-actions[bot] avatar Oct 24 '25 07:10 github-actions[bot]

Will this PR make it into the next release? This issue is quite frustrating when working with tracked entities - so the fix would be very much appreciated! 👍

digitallyrefreshed avatar Nov 25 '25 13:11 digitallyrefreshed

Thanks for proposing this fix @Leafmire!

Apologies that this PR appears to have fallen off the radar. We'll take a look shortly and see if it'll be possible to get it into the next release. Hopefully so!

ggetz avatar Dec 10 '25 15:12 ggetz