Celestia Forums

I'm testing a patch that fixes some problems with orbit display that have long plagued Celestia. If you're building Celestia from CVS, you can replace your render.h and render.cpp with the versions here:

http://www.celestiaproject.net/~claurel/celest ... rec_orbits

Make sure you update from CVS before applying the patch.

The patch fixes some of the jitteriness seen in orbits far from Earth and some depth sorting anomalies. It should fix the 'holes in orbits' bug seen on some Macs, but I haven't been able to test this.

The patch works by transforming the vertices of the orbit paths in double precision on the CPU. Clipping to the near and far planes is performed on the CPU as well. The disadvantage of this approach is that performance will suffer. Fortunately, I haven't been able to see an perf drop so far. Then again, I have an 2.2GHz Intel Core processor. If anyone would like to test out the patch for performance and bugs, I would appreciate it very much. There are ways to improve the performance of double precision orbits, possibly using bounding volume hierarchies. However, I don't want to do that work if the performance is already ok.

This new orbit drawing technique could be enhanced further; with vertex transformation done on the CPU, it becomes possible to add some spline-based smoothing.

--Chris

Chris,

I'll test it right away. I'll be back here in about 15 minutes.

Cham wrote:Chris,

I'll test it right away. I'll be back here in about 15 minutes.

I knew I could count on you for this one

--Chris

The built is done. I'm testing it. After few min only, I didn't noticed any slow down in frame rate, no holes on orbits yet.

The only thing that didn't changed is the jittering of the red orbit, at very close range (at least in the case of an asteroid I'm watching right now).

Cham wrote:The built is done. I'm testing it. After few min only, I didn't noticed any slow down in frame rate, no holes on orbits yet.

The only thing that didn't changed is the jittering of the red orbit, at very close range (at least in the case of an asteroid I'm watching right now).

It's better, but the jittering isn't completely gone. I believe that this is because that while the CPU is clipping against the near and far planes at double precision, clipping against the viewport is still done by the GPU at single precision. I could try and do viewport clipping on the CPU as well, but it's will be slower. A better approach might be to subdivide orbit segments that are close to the camera.

--Chris

After some testings, I now can make some (positive) comments :

1- the red orbit jittering at close range is much less noticeable than before. In many cases ("small orbits"), the jittering is gone. In other cases, it's pretty "calm" (slow jittering). In only one case (yet), I saw a "fast" jittering as before. So globally, I think there's an improvement here.

2- Apparently, the cost on the frame rate is subtle on my machine (dual 2 GHz G5). I didn't saw any major slow down in FPS, except in the extreme case of ALL asteroids orbits turned ON (several hundreds, if not thousands of asteroids orbits and labels !). I'll have to retest the same view with my previous built to compare the frame rate, since it's not obvious there's any slowdown, actually.

3- I wasn't able to reproduce the holes on orbits yet. I need more time on this, just to be sure. However, strangely, I have the vague feeling this bug is gone !

The patch seems to be working for me.
Neptune no longer has its orbital path sometimes drawn in front of it.

Performance seems reasonable but is slower than it was on this 1.86Ghz 6300 Core-2-Duo: Neptune is drawn at 60fps, but Jupiter and Saturn slow to 20-30fps, presumably due to the large number of moon orbits. They're both drawn at 40-60fps by pre4. I have orbit antialiasing and "antialias samples 4" enabled in both versions of Celestia.

Of course, someone needs to try this on slower systems and on Macs.

Orbits seems fine on my config (poor), no major drop in the FPS.

Don't know if related, buts seems I do not have anymore giant solar glare!

Now, there is a bug somewhere: ONLY in full screen, the OGL window blink from time to time, and become black if I call the menu (approaching the mouse to the top of the screen or if I call the controls (cmd+,) or any other panel (browser etc...). If a panel is over the GL window it stay black. If the panel is on a second screen the GL window is ok but blink...

Any ideas? Only osX related, no?

I usually don't use full-screen mode anymore because I haven't been able to do a screen-grab from within full-screen Celestia for a very long time: they always come out black. That's why my screengrabs are usually1600x1100 from windows instead of 1600x1200.

(Also the LCD configuration data file provided by the vendor for the display I use at work is wrong: XP claims it can't do 1600x1200, even though that's the native resolution. It's a Samsung SyncMaster 210T that I've been using for several years.)

What I'm seeing now, is that under XP, when running full-screen mode, when the menu bar becomes visible, most of the screen displays what looks like an empty desktop, with one or two empty windows -- e.g. I can see the top border of this firefox window, but the region within its window area is black: no text or firefox buttons of any kind.

But it's unpredictable. It was faiing a minute ago, but now that I'm running a screengrab utility to try to capture what I see, Celestia's full-screen mode is working fine.

*sigh*

This system is
2GB, 1.86 GHz 6300 Core2Duo, Windows XP, sp2 128MB Nvidia Quadro 550, ForceWare 162.62
Celestia as built from CVS plus the new orbit code.
Celestia v1.4.1final

I also saw the same failure just now with Celestia v1.4.1 final. -- for which I did manage to get a screengrab.

The empty window is that of the screengrabber program. Very strange.

p.s. and note that Celestia isn't shown in the taskbar, although that's Celestia's menu bar across the top of the screen. very very strange.

ElChristou wrote:Now, there is a bug somewhere: ONLY in full screen, the OGL window blink from time to time, and become black if I call the menu (approaching the mouse to the top of the screen or if I call the controls (cmd+,) or any other panel (browser etc...). If a panel is over the GL window it stay black. If the panel is on a second screen the GL window is ok but blink...

Any ideas? Only osX related, no?

I can't reproduce this issue on my Mac. Do you have FSAA turned on?

dirkpitt wrote:I can't reproduce this issue on my Mac. Do you have FSAA turned on?

Nope...

I compared extensively my previous built (without Chris's patch) and the newest built (with Chris's patch). After several tests, I may conclude this :

1- I didn't noticed any frame rate dropping. Both builts are giving me the same frame rate for all scenes I examined (with some small and random variations, of course).

2- The hole bug appears to be *almost* completely gone. I'm saying *almost*, since I had few small holes in the case of a single scene with an asteroid on the foreground, and hundreds of asteroids orbits in the background. With my previous built, I had lots of holes with the same scene, so there is clearly some improvement in this case.

I'm able to get many scenes with orbit holes if I use the previous built, very easily, while not a single hole was actually visible with the last built (except in the single case mentioned above).

3- Using the last built, I've noticed a kind of fast blinking effect of all the scenes, if I rotate my point of view around the selected object, especially when there are tons of asteroids orbits visible on the background. I don't have this annoying effect with my previous built. The blinking effect is "medium fast" (**see below**) and of "weak amplitude" : it took me some time before I realised there's a kind of scene blinking. Now, it's clear there's something different. This effect is occuring in both window and full screen modes.

That's all for the moment.

** roughly, about three blinks per sec, while I rotate around an object in some heavy scene with tons of orbits. Actually, the blinking effect appears to be related to the frame rate, which depends on the complexity of the scene. It's like if the screen was gettting all black for a very brief moment of time (less than a tenth of a sec), before redrawing itself.

Cham, isn't this the same kind of blinking effect that you showed me with M20? M22?
(before Chris' orbit patch)

dirkpitt wrote:Cham, isn't this the same kind of blinking effect that you showed me with M20? M22?
(before Chris' orbit patch)

Was that a long time ago ? I'm not sure. Looks a bit the same.

Apparently, it's a kind of slow screen redraw, most visible in complex scenes with low FPS.

Cham,
Which set of asteroids are you using?
I tried to do a quick test with the full set and, not surprisingly, had to reboot to get things back to normal

On my system at home I'm seeing about the same amount of slowdown as I saw on my system at work. With orbital antialiasing and 4x FSAA, I'm getting 60 fps watching Neptune, but only about 30fps watching either Saturn or Jupiter at a distance where their full "ball of strings" just fit on the screen. (Without antialiasing, I get only slightly less than 60fps for Jupiter and Saturn.)

system config:
1GB 3.4GHz P4-550, WinXP Pro sp2
256MB GF 7800 GTX, ForceWare 163.71
Celestia built from CVS + orbital patch

(Other tests I've done seem to confirm that this P4 has about the same performance as the 1.86GHz Core2Duo.)

selden wrote:Cham,
Which set of asteroids are you using?
I tried to do a quick test with the full set and, not surprisingly, had to reboot to get things back to normal

It's an edited set of asteroids that I've found somewhere, probably the same as on the Motherlode. Really, my asteroids database is a mess ! I have all the files from Jack and Grant (?), trojans, MartianTrojans, neo, centaurs, etc. One day, I should clean that mess.

When I turn ON the asteroids orbits, I'm getting a full screen jam of lines, and the frame rate is dropping severly (with any version of Celestia, patched or not). It's a good test bed anyway.

Cham wrote:... roughly, about three blinks per sec, while I rotate around an object in some heavy scene with tons of orbits. Actually, the blinking effect appears to be related to the frame rate, which depends on the complexity of the scene. It's like if the screen was gettting all black for a very brief moment of time (less than a tenth of a sec), before redrawing itself.

Then I must see the same thing but must slower due to my config, + the black screen if I click any panel in full screen or if a panel is over the GL window...

I don't think it's related but the strange orbit bug I mentioned here reappeared.

although it seems less "extreme" in these to shots compared to my old thread.

100 orbit samplepoints:
http://www.purebytes.de/stuff/celestia/ ... _patch.png

500 orbit samplepoints:
http://www.purebytes.de/stuff/celestia/ ... patch2.png

the problem is I made a full clean before compiling this version and the bug is still there.
the only difference to the cvs version are chris new makefiles for the VC2005++ Toolkit.

edit: the good news is I didn't notice any drop in framerates even if I enable all possible orbits on my 2.2 GHz T7500 Core2Duo / GF 8600 GTS

phoenix wrote:I don't think it's related but the strange orbit bug I mentioned here reappeared.

although it seems less "extreme" in these to shots compared to my old thread.

100 orbit samplepoints:
http://www.purebytes.de/stuff/celestia/ ... _patch.png

This has always been present in Celestia. The orbit of the Moon is not a perfect ellipse, and the discontinuity is the result of Celestia trying to present the orbit as an ellipse. There's a similar issue with the planet orbits, though it's not as pronounced. There are a few possible workarounds for future versions of Celestia. The one I like best is to display the orbits of the Moon and planets as true ellipses based on the osculating orbital elements, and recalculate them frequently so they match the current object positions.

--Chris