-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Conversation
Thank you for the pull request, @jfayot! ✅ We can confirm we have a CLA on file for you. |
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. |
@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? |
You're perfectly right: the
|
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,
}; |
I do think it's best to separate this behavior from the position's @jfayot My only remaining concern is that we do have some built-in behavior where We'll also need to test to ensure everything is working with the satellite case before this PR is merged. |
Got it @ggetz ! |
@ggetz I have added a new sandcastle demo to illustrate the different tracking reference frames: Entity tracking. |
Hi @ggetz ! Any update on this PR? |
Thank you @jfayot! We'll get back to this in the next few days. Thanks for your patience, we appreciate your contributions! |
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.
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, |
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.
Would it make sense to fall back to autodetect in the case where an entity has no defined orientation?
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 agree on that point, as we already have TrackingReferenceFrame.VELOCITY
. I'll change that!
* @type {number} | ||
* @constant | ||
*/ | ||
VELOCITY: 2, |
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.
What happens when an entity's velocity is 0?
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.
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()); |
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.
Should there be an expect
assertion in this test?
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 fact this test is no more needed as the case descibed here has the AUTODETECT fallback...
* @type {number} | ||
* @constant | ||
*/ | ||
AUTODETECT: 0, |
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.
Many of our enums use NONE
for an undefined or default state. Does that make sense here>
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.
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 aTrackingReferenceFrame.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 theTrackingReferenceFrame.AUTODETECT
byTrackingReferenceFrame.NONE
?
4cae947
to
80c2e14
Compare
Hi @ggetz! Thanks for your comments. This is ready for another review. |
…in their own inertial reference frame
…an orientation defined
…fused with ReferenceFrame ones
9d2b51a
to
e69487a
Compare
Looking good @jfayot! I pushed some minor formatting tweaks to the documentation, but otherwise this is great! Thanks! |
Description
Added
Entity.trackingReferenceFrame
to allow tracking entities in their own reference frame.Issue number and link:
Fixes #12293
Testing plan
Updated:
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
CONTRIBUTORS.md
CHANGES.md
with a short summary of my change