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

Approximate LVLH #818

Merged
merged 7 commits into from
Jun 1, 2013
Merged

Approximate LVLH #818

merged 7 commits into from
Jun 1, 2013

Conversation

bagnell
Copy link
Contributor

@bagnell bagnell commented May 31, 2013

Makes an approximate LVLH reference frame the default when the camera is following an object.

@mramato @emackey This looks good when following a satellite, but not when following a vehicle. Try following a vehicle in Vehicle.czml or BAMS_C4ISR.czml. Let me know what you think.

camera.transform = Transforms.eastNorthUpToFixedFrame(cartesian, ellipsoid, update3DTransform);
var failed = false;

var deltaTime = time.addSeconds(1.0);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the reason you are seeing odd behavior in vehicle.czml and BAMS is because this value is too big. There's no reason this can't be a small value because interpolation will always point you in the right direction to the next point. The smaller the better. I changed it to 0.01 to test and I think you'll find it's much nicer that way.

Copy link
Member

Choose a reason for hiding this comment

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

Why not use the derivative of the Lagange (or whatever) polynomial as the velocity, rather than finite differencing? I believe this is what Components does. CC @rcpage3

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I suggested this. If there is a way to get a derivative out of the Lagrange interpolation, that is definitely preferable, especially since it eliminates the need to perform the frame transformation twice.

@bagnell
Copy link
Contributor Author

bagnell commented May 31, 2013

@mramato This is ready for another review.

@mramato
Copy link
Contributor

mramato commented Jun 1, 2013

After a bunch of offline discussion, it was decided that while this code is not optimal, it's probably the best we can do in the near term. If the finite difference being used in this change proves sub-par, we'll revisit the issue.

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.

5 participants