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

Added Entity.trackingReferenceFrame #12194

Merged
merged 10 commits into from
Nov 15, 2024

Conversation

jfayot
Copy link
Contributor

@jfayot jfayot commented Sep 15, 2024

Description

Added Entity.trackingReferenceFrame to allow tracking entities in their own reference frame.

Issue number and link:

Fixes #12293

Testing plan

Updated:

  • EntitySpec.js
  • EntityViewerSpec.js
    to cover this new property

Updated Sandcastles CallbackPositionProperty and Interpolation for demo

Tested in the 3 different scene modes.
Tested non regression on fast satellites and slow moving objects.

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

Copy link

Thank you for the pull request, @jfayot!

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

@ggetz
Copy link
Contributor

ggetz commented Sep 16, 2024

Thanks for the PR @jfayot! Would you mind expanding a bit on the motivation behind this change? Is it mostly to address #11657?

@jfayot
Copy link
Contributor Author

jfayot commented Sep 16, 2024

Not really, in fact. I wanted to relate this PR to something similar, but the real motivation is to achieve the same effect as what you can see in Callback Position Property sandcastle in a one-liner and still be able to move the camera around the tracked entity.
May be the best would be to try the updated Interpolation sandcastle to give you an idea...

@ggetz
Copy link
Contributor

ggetz commented Sep 18, 2024

@jfayot Thank you, got it. I do think your Sandcastle example is useful behavior!

My concern here is I think there is some mismatch about how CesiumJS defines an "inertial reference frame". It appears that you are using it to refer to the entity's inertial reference frame (as in this example). In the rest of the CesiumJS API, I believe it is used to refer to Earth's inertial reference frame, or ECI. What are your thoughts?

@jfayot
Copy link
Contributor Author

jfayot commented Sep 18, 2024

You're perfectly right: the ReferenceFrame.INERTIAL refers to the International Celestial Reference Frame, not to the entity's inertial reference frame.
Would it be ok if I rename the ReferenceFrame enum like this ?

  • EARTH_FIXED
  • CELESTIAL
  • BODY (or ENTITY)

@jfayot
Copy link
Contributor Author

jfayot commented Sep 18, 2024

Or may be just create a new enum:

/**
 * Constants for identifying well-known tracking reference frames.
 *
 * @enum {number}
 */
const TrackingReferenceFrame = {
  /**
   * The east-north-up entity's frame.
   *
   * @type {number}
   * @constant
   */
  EAST_NORTH_UP: 0,

  /**
   * The entity's inertial frame.
   *
   * @type {number}
   * @constant
   */
  INERTIAL: 1,
};

@ggetz ggetz self-assigned this Sep 20, 2024
@ggetz
Copy link
Contributor

ggetz commented Sep 20, 2024

Or may be just create a new enum:

I do think it's best to separate this behavior from the position's ReferenceFrame. 👍

@jfayot My only remaining concern is that we do have some built-in behavior where EntityView.js "autodetects" satellites and and other orbital entities based on how fast they are moving and changes the camera view to Earth's inertial reference frame. I'm concerned that specifying EAST_NORTH_UP or INERTIAL will be confusing if that autodetect kicks in. What are your thoughts here?

We'll also need to test to ensure everything is working with the satellite case before this PR is merged.

@jfayot
Copy link
Contributor Author

jfayot commented Sep 20, 2024

Got it @ggetz !
You're right: EAST_NORTH_UP should be renamed AUTO_DETECT with a clear documentation of its behavior.
Anyhow, my implementation of inertial tracking overrides this auto-detect behavior. Is that the good way to go, or should auto-detect always happen even if INERTIAL is chosen?
IMO it should not: I've tested INERTIAL on satellites, and it's not that bad: there is a very little cycling shift that comes over time, but nothing compared to east-north-up tracking mode (I can't even say if this shift comes from the entity's orientation or not, but if it's the case, then this is what is expected in this tracking mode).
I'll update the PR to make things clearer! I'll probably also update the Sandcastle demo to be able to test satellites.
And one last thing if you think it has any value: I'll add another tracking option: INERTIAL_WITHOUT_ROLL (any other name welcomed)... wait for the demo!

@jfayot
Copy link
Contributor Author

jfayot commented Sep 24, 2024

@ggetz I have added a new sandcastle demo to illustrate the different tracking reference frames: Entity tracking.

@jfayot
Copy link
Contributor Author

jfayot commented Oct 7, 2024

Hi @ggetz ! Any update on this PR?

@ggetz
Copy link
Contributor

ggetz commented Oct 7, 2024

Thank you @jfayot! We'll get back to this in the next few days. Thanks for your patience, we appreciate your contributions!

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.

Awesome, I think this is a good approach @jfayot.

Apologies for the delay in getting back to this PR! I hope you still have interest in getting this change merged.

* @type {number}
* @constant
*/
INERTIAL: 1,
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to fall back to autodetect in the case where an entity has no defined orientation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree on that point, as we already have TrackingReferenceFrame.VELOCITY. I'll change that!

* @type {number}
* @constant
*/
VELOCITY: 2,
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens when an entity's velocity is 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is mentioned in #8900: The issue is that if the vehicle stops, the orientation becomes undefined, causing an abrupt change in the vehicle's orientation
The behavior will be the same here, causing the camera position to change abruptly following the entity's orientation

const entity = new Entity();
entity.trackingReferenceFrame = TrackingReferenceFrame.INERTIAL;
const view = new EntityView(entity, scene);
view.update(JulianDate.now());
Copy link
Contributor

Choose a reason for hiding this comment

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

Should there be an expect assertion in this test?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fact this test is no more needed as the case descibed here has the AUTODETECT fallback...

* @type {number}
* @constant
*/
AUTODETECT: 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

Many of our enums use NONE for an undefined or default state. Does that make sense here>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Most of the enum with a NONE value I've seen are reflecting something meaningful:

  • ArcType.NONE
  • ExtrapolationType.NONE
  • Visibility.NONE
  • HeightReference.NONE
  • ...
    I'm not sure a TrackingReferenceFrame.NONE value would be of any interest. This would represent an invalid value that should be tested against, and add more noise to the code IMO.
    Unless you would prefer me to replace the TrackingReferenceFrame.AUTODETECT by TrackingReferenceFrame.NONE?

@jfayot jfayot force-pushed the feat_tracking_reference_frame branch from 4cae947 to 80c2e14 Compare October 29, 2024 16:24
@jfayot
Copy link
Contributor Author

jfayot commented Oct 29, 2024

Hi @ggetz! Thanks for your comments. This is ready for another review.

@ggetz
Copy link
Contributor

ggetz commented Nov 15, 2024

Looking good @jfayot! I pushed some minor formatting tweaks to the documentation, but otherwise this is great!

Thanks!

@ggetz ggetz added this pull request to the merge queue Nov 15, 2024
Merged via the queue into CesiumGS:main with commit 09a0276 Nov 15, 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.

Camera orientation problem with sampledPositionProperty and trackedEntity
2 participants