Win32 Executable from SVN

[Derek]

Hi Guillermo,
Sorry 4880 was a mistake should have read 4890, further investigation I've found it's a combination of addons together with your svn 4898 and 4903 which are causing the other problems.

[selden]

The orbit path code has been completely rewritten.
The new code was added to Celestia as of r4825.

Hopefully its bugs will be fixed in the not too distant future.

r4825 | cjlaurel | 2009-08-06 22:15:26 -0400 (Thu, 06 Aug 2009) | 2 lines

Rewrote orbit drawing code to fix multiple shortcomings. New orbit code uses adaptively subdivided cubic curves to draw orbits more accurately and without numerical precision artifacts. The orbit rewrite uses Eigen throughout (instead of the Celestia vector classes.)

[abramson]

OK. Selden, should I report it as a bug, or does everybody already know about this?
G

[chris]

OK. Selden, should I report it as a bug, or does everybody already know about this?
G

The gap is intentional, not a bug. Because of perturbations from other bodies, Pluto's orbit is not a perfect ellipse. Celestia now draw planet orbits over a duration of one mean orbital period, starting at the current time minus one half the orbital period. Thus the gap appears approximately 180 degrees away from the body, though this will vary for significantly eccentric orbits like Pluto's.

This may not be the best way to draw the orbit. Indeed, the fact that a number of people are reporting this as a bug suggests that Celestia should have some other strategy for rendering orbits that are approximately periodic. One possibility is to draw the orbit starting from the current time back to one orbital period earlier, fading out the tail end of the orbit so that the gap looks intentional.

The gap should not be confused with a very real bug when drawing highly eccentric elliptical orbits. I have a partial fix for this already, and hope to have it completed today.

--Chris

[abramson]

Wow! Such a detail! I wasn't aware of this delicacy. Thanks, Chris.

The fading of orbits boud be a fine thing. Even to draw them shorter than a period: for example, to show the apparent path of planets from a vantage point.

Guillermo

[ajtribick]

The gap is intentional, not a bug. Because of perturbations from other bodies, Pluto's orbit is not a perfect ellipse. Celestia now draw planet orbits over a duration of one mean orbital period, starting at the current time minus one half the orbital period. Thus the gap appears approximately 180 degrees away from the body, though this will vary for significantly eccentric orbits like Pluto's.

This may not be the best way to draw the orbit. Indeed, the fact that a number of people are reporting this as a bug suggests that Celestia should have some other strategy for rendering orbits that are approximately periodic. One possibility is to draw the orbit starting from the current time back to one orbital period earlier, fading out the tail end of the orbit so that the gap looks intentional.

Another approach that may be interesting would be to draw the osculating orbit. Not sure how feasible that would be though.

[chris]

The gap is intentional, not a bug. Because of perturbations from other bodies, Pluto's orbit is not a perfect ellipse. Celestia now draw planet orbits over a duration of one mean orbital period, starting at the current time minus one half the orbital period. Thus the gap appears approximately 180 degrees away from the body, though this will vary for significantly eccentric orbits like Pluto's.

This may not be the best way to draw the orbit. Indeed, the fact that a number of people are reporting this as a bug suggests that Celestia should have some other strategy for rendering orbits that are approximately periodic. One possibility is to draw the orbit starting from the current time back to one orbital period earlier, fading out the tail end of the orbit so that the gap looks intentional.

Another approach that may be interesting would be to draw the osculating orbit. Not sure how feasible that would be though.

I've considered this before, and it's completely feasible. The new code draws orbits a series of cubic curves, and there are well-known algorithms for approximating an ellipse as cubics. Only a small number of cubics are required to get quite good accuracy. See for example http://www.tinaja.com/glib/ellipse4.pdf

I see two drawbacks with using osculating orbits:
- It's a different approach than used for non-periodic trajectories, where the actual path through space is shown
- The shifting, precessing ellipses might be confusing to users without some celestial mechanics background

Regardless, the osculating orbits would be very interesting to see, as they should show the orbital evolution of bodies more clearly than other schemes for drawing orbits. If you have some time to write code to calculate a piecewise cubic approximation to an ellipse, I'd add an osculating orbit view to Celestia, at least as an option.

--Chris

[Teto]

Celestia SVN executables from Mr. Guillermo Abramson:
http://cabfst28.cnea.gov.ar/~abramson/celestia/svnexec/

Due to a change of servers, my webpage has changed address. Find the binaries here: http://fisica.cab.cnea.gov.ar/estadistica/abramson/celestia/svnexec (updates every night).

Guillermo

This built is very appreciated.
I've found one problem with built svn4903: When you're approaching a star, its texture is half cutted. Very funny. Is it a bug of the built or of the program itself? I don't know, I'm just a final user.

Teto.

[abramson]

I've found one problem with built svn4903: When you're approaching a star, its texture is half cutted. Very funny. Is it a bug of the built or of the program itself? I don't know, I'm just a final user.

I also see it, Teto. That's definitely a bug, and it's not obvious what's happening.

What you are seeing is the Sun from the inside, which is transparent in Celestia (textures are only visible from the outside). Solar radius is 696000 km, one shouldn't see that until the distance is that value, not more than 1 million as it happens. The size of the Sun is right, though (judging from it's apparent size). Something is been wrongly calculated here.

This is definitely a bug. Strangely, it seems to happen only after visiting Earth! If you interrupt the startup script before going to Earth (with ESC) you can go right to the surface of the Sun without seing this artifact. You can even go to other planets and return to the Sun. But after going to Earth (or the Moon, but the Earth always gets in sight) the next time you go to the Sun you see it. Isn't it weird? Can anybody confirm this? I think you should report it as a bug, and I hope it doesn't give Chris a headache.

Guillermo

[Teto]

Done!

Teto.

[Derek]

Guillermo,

Just checked with a standard 1.6.0 download with no addons or extras doesn't do this it would appear to me that a sun addon is causing the problem.

[chris]

This is definitely a bug. Strangely, it seems to happen only after visiting Earth! If you interrupt the startup script before going to Earth (with ESC) you can go right to the surface of the Sun without seing this artifact. You can even go to other planets and return to the Sun. But after going to Earth (or the Moon, but the Earth always gets in sight) the next time you go to the Sun you see it. Isn't it weird? Can anybody confirm this? I think you should report it as a bug, and I hope it doesn't give Chris a headache.

Nope, not a headache

This is a bug. I have some new sphere rendering code that will fix this bug and a whole bunch of other problems (suboptimal virtual texture usage, performance, black holes in the sky, ...) I was hoping to have it ready, but it's taking some time to perfect. So, in the mean time, I'll find a fix to make the current code work.

--Chris