Celestia Forums

The SVN version of Celestia contains orbit plotting code that has been completely rewritten since 1.6.0. It fixes many shortcomings in the 1.6.0 code:

- Objects would often appear many thousands of kilometers from the orbit path
- Orbits were clipped near the camera
- Very large orbit paths (e.g. the Pluto-Charon barycenter) would appear to 'jitter' when the camera was close by
- Orbits paths of planets and moons weren't updated for the current simulation time
- Artifacts would appear when the ends of approximately periodic orbits were joined. Many people have complained here about the strange appearance of the Moon's orbit.

Here's a screen shot of Cassini and its trajectory plotted with the new code:



Notice that the spacecraft appears exactly on its trajectory. If you try this with 1.6.0, you'll see that the spacecraft is actually quite far from it's trajectory. Another advantage of the new code is speed: I've observed a 2x performance increase when drawing complex trajectories like Cassini's.

If you're able to build Celestia from the code in SVN, here few useful comparisons with the new orbit rendering code and 1.6.0:

- Cassini: observe how the spacecraft remains precisely on the orbit path with the patched code
- Eros: in the 1.6.0, the asteroid is shown thousands of kilometers from even a simple elliptical orbit. Fixed with the patch.
- Moon: the orbit path is constantly updated so that the Moon never appears to drift away. The odd 'jump' in the orbit is gone (actually, just hidden--see below)
- Pluto: travel to Pluto and display the orbit of the Pluto-Charon barycenter. With the patch, the jittering is gone.

The new trajectory plotting code works by drawing the orbit as a sequence of adaptively subdivided cubic curves. This is not an especially novel approach, but it's quite a task to make the code 1) fast, and 2) work well on graphics hardware that only supports single precision floating point arithmetic. Single precision is completely inadequate for the task of orbit plotting. A single precision float has a 23-bit significand, giving a precision of roughly one part in 8 million. Since Saturn is about 1.5 billion kilometers from the Sun at aphelion, the plotting error will be about +/- 100km. This error isn't so noticeable when showing the orbit of Saturn, which is much larger than 100km. However, it's a serious problem for a spacecraft a few meters across.

--Chris

Nice!

It seems my old proposal of using cubic splines has now found its perfect realization (via adaptive sampling).

viewtopic.php?f=4&t=4672&p=33855&hilit=spline#p33855

Fridger

Can this approach also be used to solve the accuracy issues of distant objects?
e.g. stars in a far away cluster, galaxies or even whole clusters.

Planets and other objects around that star?

Solving the accuracy problem for drawing far objects with this approach would be really fantastic.

Celestia has given me a huge amount of pleasure. My increasingly poor eyesight has made me cautious when ever I think something is not right (in this, at least, I have been proved right).
My computer is old and antiquated as you can see but still produces wonderful results for me.
However
Since the introduction of the new plotting code which is excellent, my FPS has roughly halved. My installation is Celestia 1.6 with the latest executable SVN 4863 which I got from abramson (Many thanks to him) . I have a number of addons and vt textures but nothing too large to cause serious slow down. Using the 1.6 executable I get about 14-20 FPS when viewing Earth but if I use SVN 4863 I get 6-7 FPS. SVN 4787 is the 14-20 FPS figure also. I know all is very slow but the extra loss of performance is a pity.

I wonder if you have any suggestions (a new machine would be nice but out of range at the moment).

DOJOMO,

Just to be clear:
Is this loss of performance seen only when Orbit paths have been enabled in the Render/View Options menu?
Or does Celestia run more slowly whether or not Orbits are enabled?

DOJOMO:

What sort of CPU do you have in your computer? The new code benefits greatly when SSE2 vector instructions are enabled. However, some older processors don't support SSE2, and so sse2 isn't enabled in the Visual C++ project in SVN.

--Chris

As already reported to Chris by email, I'm also experiencing a huge slowdown with the newest code, while using exactly the same installation (with addons) as for the official 1.6.0. And yet, my computer isn't that old (it's actually a very powerfull computer with a strong video card).

Thanks for the speedy response.
First of all an apology. I assumed my signature and hardware details would show at the bottom of my post. It should now.
Secondly the FPS is virtually constant whether orbits are enabled or not. (I have just tested it again after the usual wait it settled at about 5.6 FPS in both cases.
Finally, I purchased the machine in the middle of 2002. I guess this may be the explanation. A bit like me - old age.

David

It looks like there was a substantial loss of performance between r4842 and r4845. I keep copies of builds that I've done, and I ddn't build either of the two intermediate versions.

Viewing Saturn, with and without orbits being drawn,:

v1.6.0: 83 / 102 (no sse2)

with sse2:
r 4814: 87 / 110
r 4824 86.5 / 112
r 4834 97 / 117
r 4842: 97 / 117
r 4845 77 / 86
r 4854 77 / 87
r 4864 77 / 85

These measurements were done just now. (just after 3PM EDT 2 Sep 09)
I ran r4842 again at the end and it had the same performance as before, so I don't think the performance loss is due to the graphics hardware overheating and slowing its clock.

System:
2 GB 1.86 GHz Core2Duo E6300, Win XP Pro SP3
128MB Quadro FX 550, ForceWare v169.47
1600x1200 display, vertical sync disabled.

I think Chris

Enabled anisotropic filtering for planet textures (when supported by hardware.)

That may account for the loss of fps. That was r4843.
cartrite

cartrite wrote:I think Chris

Enabled anisotropic filtering for planet textures (when supported by hardware.)

That may account for the loss of fps. That was r4843.
cartrite

I doubt that. Even with my old card, I barely feel 8x anisotropic filtering. I did lots of respective tests in the past, since I always apply anisotropic filtering as an efficient remedy against polar pinching...

But I seem to remember that Chris experimented with various improved algorihms that vastly increased the number of knots?

Fridger

cartrite wrote:I think Chris

Enabled anisotropic filtering for planet textures (when supported by hardware.)

That may account for the loss of fps. That was r4843.
cartrite

It's possible that anisotropic filtering is at fault. It doesn't significantly affect performance on my system, and Fridger has reported similar results. However, the performance characteristics of anisotropic filtering have varied dramatically among different NVIDIA and ATI GPUs. The only other change that happened between 4842 and 4845 was a fix for the XCode project, which only affects the Mac.

To test whether anisotropic filtering is causing the slowdown, try disabling it by changing line 149 in texture.cpp from this:



to



Ultimately, the user will have control over the anisotropic filtering level via a GUI control panel. Despite the performance drop, I still believe that it should be on by default, as it dramatically improves texturing quality in the area near a planet's poles.

--Chris

OK with my old fx5900 ultra card, I get these results for Earth located in the window center, right after startup

1) 8x anisotropic filtering: 33.4 fps
2) "if (false)": 38.4 fps

All overriding AA etc effects are switched off in NVIDIA control.
There is an effect but not dramatic. I don't feel a big slowdown if I switch on the new orbits (along with plenty of asteroids!)

Fridger

Anisotropic filtering was the cause of my slowdown.
After recompiling, I now get 87 / 116 fps (with/without orbit paths)
[correction 97 / 116. I misread.]

I suspect it's at least part of the cause of DOJOMO's slowdown, too, since he has older hardware. SSE2 emulation probably contributes, too.

I just now deleted celestia.vcproj and downloaded a fresh copy. SSE2 code generation is enabled in Celestia -- RMB -- Properties -- C/C++ -- Code Generation/

It is clear that anisotropic filtring will give rise to SOME slowdown (see also my data). But I always found that it is quite small compared to AA filtering by a respective factor Nx

There is NO free lunch anywhere

Fridger

Thanks Selden.
My ansiotropic filtering control in the nVidea GeForce 2Go graphics processor properties has only 2 choices:-
Application or 2X.
It makes no difference to the performance which is selected. I assume therefore if it is a factor I can't turn it off unless some option is intriduced in Celestia.exe.
Is that a possibility?

Thanks to all
David