Callisto orbit

[Paolo]

Probably I've found a little bug in the calculation of Galileian satellites orbits.

Directly after the program loading, type [enter] then type Callisto and the goto command (g-key). Display the orbits wint the "o" key, then move away from the satellite (left+right mouse button and drag or muse wheel) about 200,000 km. On my system the shape of the Callisto Orbit seem to have an unusual discontinuity.

Now type "f" follow command and accellerate the time 100,000x with "l" key. Wait and look. When Callisto terminates an entire orbit and reaches the previous mentioned discontinuity it abandons the displayed orbit shape.

I've tested also the other galileian satellites, and Europa seem to behave in the same strange way.

My system
AMD Athlon XP 1800
ATI Radeon 8500
Windows XP pro

Hi to all.

This software is wonderful. Every day is possible to discover something new.

[selden]

Paolo,

Making time go backward shows it more quickly (the J key)

Unfortunately, all orbits have this problem to a greater or lesser amount. It would be very helpful if the differences between the drawn orbit paths and the actual orbits of objects could be reduced or eliminated.

[chris]

Paolo,

Making time go backward shows it more quickly (the J key)

Unfortunately, all orbits have this problem to a greater or lesser amount. It would be very helpful if the differences between the drawn orbit paths and the actual orbits of objects could be reduced or eliminated.

The non-Keplerian orbits used in Celestia can be very expensive to compute, particularly when 100+ points are required to render an orbital path. So, the paths are computed just once and then cached . . . I could modify Celestia to recompute the paths occasionally, but less than every frame. Another change I've considered is to make the orbit path of just the current selection update every frame. Would these compromises be helpful?

--Chris

[selden]

Chris,

I understand the overhead that'd be required for drawing the non-keplerian orbits continuously. An occasional recomputation for the objects in view, done somewhat more frequently for the selected object (or perhaps with the frequency determined by the relative distances of objects?) sounds like a very reasonable compromise.

Apparently it's a separate problem, but I'd also be made very happy if somehow the drawn orital paths could be constrained to pass through the centers of the visible objects. It's rather disconcerting to approach an object and see its "orbit" disappear off-screen. This is a problem for Keplerian orbits as well as the non-Keplerian ones.

Thanks for thinking about this issue.

[Paolo]

Chris

I don't know if I'm going to say something stupid but my suggestion is the following:

1) Use some kind of Bezier's or cubic interpolation to reduce the number of samples and calculations for the orbit paths.
2) Recalculate each frame the orbit shape only for the selectet body;
3) If the item 2) is implemented also the Selden's suggestion:

Apparently it's a separate problem, but I'd also be made very happy if somehow the drawn orital paths could be constrained to pass through the centers of the visible objects. It's rather disconcerting to approach an object and see its "orbit" disappear off-screen. This is a problem for Keplerian orbits as well as the non-Keplerian ones.

should be solved easily, adding one point to the path and forcing it to fit in the center of the selected body.
4) Perhaps performing the rendering with z-buffering of the orbit path of the selected body outside the other orbits rendering stuff and after the body rendering should display the path entering in the middle of the body, and solve another small visualizing problem.

Sorry for my poor. English. I Hope that you get the ideas.
Bye.

[Paolo]

Perhaps the following link should help.

http://artsandtechnology.humber.ac.uk/~ ... esson7.pdf

I think that the example should fit with the orbits paths. But I'm not so expert of OpenGL.

Bye

[Paolo]

I've played for a while with the example of bezier interpolation with OpenGL reported in last post. I think it works.

If applied to Celestia for orbit paths calculations, could be necessary to sample, with the complex orbit routines, only 4 points and interpolate 2 Bezier control points for each sampled point.

The Bezier curves should give a smoother aspect to the orbits paths too.

Bye