Skip to content

Allow specifying duration of movement time #320

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

Merged
merged 2 commits into from
Apr 10, 2025

Conversation

Carifio24
Copy link
Member

This PR implements something that we want in CosmicDS, which is the ability to specify the duration of a movement between two locations.

As for how I implemented this:

  • Add a new optional duration parameter to our parameters that control goto movements. This represents the desired duration of the move, in seconds.
  • We have two view mover classes: ViewMoverKenBurnsStyle and ViewMoverSlew. The Ken Burns-style mover already has a parameter for the time to target, so almost all of the work here is for the slew mover. We generally create the slew mover via its create function (in fact, I think that's the only way that we do in the codebase), so I've updated that function to take in a duration parameter. If the caller doesn't pass anything in, this will be undefined, and the behavior is left unchanged from what it is currently
    • My original plan had been to do something like createUpDown, and set appropriate values for the various factors to give the desired duration. However, this isn't possible due to the second term in this line, which doesn't have a prefactor that we can adjust. Thus, the approach taken here is a simpler one: create the view mover and let it figure out its times, then adjust the up/down/total times to have the same relative sizes, just scaled to fit the desired duration. This works because only the target time variables are used for the interpolation - the up/down/travel factors are only used in init. If not for how they're used in createUpDown (whose API I assume we don't want to change), they could just be scoped to that function.
  • The rest of the PR is then just plumbing this new functionality through the various layers of the codebase

If anyone wants to test this out, I've set up a demo here that allows specifying the various parameters. Similar to the time functionality exposed in #222, the actual time for the movement will within a few milliseconds of the requested duration.

@pkgw
Copy link
Contributor

pkgw commented Mar 13, 2025

Ah, neat. I haven't tried to run a test of this, but from reading over the changes, everything looks reasonable to me.

@Carifio24
Copy link
Member Author

@pkgw If you're interested in easily trying it out there's a demo (with a UI to set parameters) in the description

@Carifio24 Carifio24 merged commit e60eaee into WorldWideTelescope:master Apr 10, 2025
9 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.

2 participants