Fixed double vision problem in foreground orbits

[doctorjoe]

There is some astrophysics involved here. The moons close in to the large planets are strongly influenced by the planet's gravitational field and the oblateness of the planet and so they settle down into nice flat orbits.

There is however a "halo" of captured asteroids that are further away. They are less tightly bound to the planet and so have more diverse orbits.

The same thing happens at the solar system scale ( with the Oort cloud) and at the galactic scale where you have a disk and a halo.

[BlindedByTheLight]

Hey guys... haven't had a chanec to check the patches... out of town for a week. But looking forward to the changes. Happy 4th!

[doctorjoe]

One thing to keep in mind is that I'm running on a machine that is very graphically slow, so I'm not likely to see major slowdowns.

[dirkpitt]

One thing to keep in mind is that I'm running on a machine that is very graphically slow, so I'm not likely to see major slowdowns.

I'll try and benchmark your updated patch this weekend.

[dirkpitt]

I think that the saturn rendering is correct and what you are seeing are some background moon orbits. I looked at the item with celestia 1.4pre6 and the rendering is the same.

I've got a good guess as to what caused the slow down. Basically to simplify the code I changed it so that elliptical orbits used the same sampling code as the custom orbits and this involves calculating the time based location which is slow.

The speed has not improved significantly, unfortunately. Also, the "orbits on top of the planet"
issue is definitely there, and it looks like a miniature version of the planet's own moon orbits
are being duplicated on top of the planet at a certain distance. Another issue that may be related
is the planet's own orbit path is drawn on top of the planet when I zoom in very close to the
planet itself.

[doctorjoe]

I've upload dirkpitt.patch to the celestia pages. I've turned off a few things and I'd like to see if it help. Any profile information you can get will be very useful.

If you don't see any speed up, go into orbit.cpp and change

OrbitAngleThresholdProc defaultOrbitThresholdProc(1.0);

to

OrbitAngleThresholdProc defaultOrbitThresholdProc(5.0);

to see if this help


There are two things that could be broken.

1) I'm calculating orbits in a very different way
2) I'm trying to get the foreground rendering right.

[doctorjoe]

Can you post a screenshot of the moon on top of planets problem?

I'm not seeing it at all in my version,

[doctorjoe]

You'll have to install the gototime.diff patch from my patch set to get it to compile cleanly.

[doctorjoe]

I'm not seeing a slow down on my system. I'm pretty sure that whatever is causing the double moon on your system is also causing the slow down. If you can post that picture, we can try to figure out why the patches act differently.

Also, you are starting from a clean CVS build and then applying the patches, correct?

[doctorjoe]

Try setting the rendering path to basic and see if the double moon problem disappears. I'm pretty sure that the double orbit problem and the slowdown are related.

[doctorjoe]

It's a bit difficult to try to fix a bug that I can't reproduce, but I've made some changes that code improve things.

The new patches

1) reduce the orbit sample rate to what it used to be
2) change the order of the commands slightly which may or may not fix the double moon problem
3) Force a refresh of the frames per second value once every 10 seconds

Interested to know if they improve things.

Also, I have to turn smooth orbits off in order to run on my machine. My graphics card does not do hardware color blending and turning on smooth orbits kills the machine. I'd be interested in seeing if turning off smooth orbits drastically improves performance.

[dirkpitt]

I'm not seeing a slow down on my system. I'm pretty sure that whatever is causing the double moon on your system is also causing the slow down. If you can post that picture, we can try to figure out why the patches act differently.

I found the bottleneck: GL display lists. Here is the "top 6" list from a typical GL profile (performed with Apple's OpenGL Profiler) with the orbit patch:

GL Function;# of Calls;Total Time (?sec);Avg Time (?sec);% GL Time;% App Time
glEndList;22,273;6778903;304.36;71.26;14.01
glDeleteLists;22,110;1899766;85.92;19.97;3.93
glNewList;22,273;740322;33.24;7.78;1.53
glGetFloatv;22,273;37346;1.68;0.39;0.08
glGenLists;22,273;26849;1.21;0.28;0.06
glIsList;44,383;20920;0.47;0.22;0.04

glEndList hogs up to 14% of the total application time. A corresponding time profile of the application itself (performed using Apple's Shark application) suggests that there are a lot of repeated memory allocations/deallocations that correspond to these gl*List calls and these are incurring a very high overhead.

To confirm this, I removed all the gl*List calls and replaced them with a direct call to renderOrbit() (like in previous versions of your orbit patch). This resulted in frame rates roughly similar to the unpatched Celestia, or about 10x the speed.

All my tests were done with the Basic render path, and smoothed lines (which incur a negligible performance penalty on my machine).

By comparison, without the patch:

GL Function;# of Calls;Total Time (?sec);Avg Time (?sec);% GL Time;% App Time
glBegin;195,803;1295357;6.62;27.36;1.04
glVertex3f;15,400,075;1255558;0.08;26.52;1.01
glEnd;195,802;512320;2.62;10.82;0.41
glDrawArrays;536;428052;798.61;9.04;0.34
glVertex3fv;2,676,808;365148;0.14;7.71;0.29
glDrawElements;22,642;338514;14.95;7.15;0.27


I haven't had time to really diagnose what's causing the double orbit problem but it appears to be unrelated to the slowdown. Here are screenshots:

saturn01.jpg

When I pan to the right, the doppelganger drags along with the mouse:

saturn02.jpg

My machine: Apple PowerBook G4 15" 1.33GHz, 768M RAM, ATI Mobility Radeon 9700 64M VRAM, OpenGL 1.5.

[doctorjoe]

Let me try to fix the display list problem first. What I can try to do is to cache the display list so that once it is created, it get shared between frames. Right now, the display list is only used to redraw the foreground orbits.

The double orbit looks like it is trying to redraw the solar orbit with saturn as the sun.

Does it happen when you turn rendering path to basic?

[dirkpitt]

The double orbit looks like it is trying to redraw the solar orbit with saturn as the sun.

Does it happen when you turn rendering path to basic?

Yes.

[doctorjoe]

Let me know if this helps the speed. If it doesn't, I've got something else that I can try.

[doctorjoe]

Try turning off moon orbits and planet orbits separately and see what that does to the double,

[dirkpitt]

I'm not sure if I'm doing this correctly because both the moon orbits and planet orbit automatically switch on if I select the planet. What I did manage to achieve was switch off both planet and moon orbits, which switches on just the planet orbit when I select a planet. When I do this, the doppelganger disappears (i.e., no moon orbits, no doppelganger).

[doctorjoe]

Thats probably why I'm not seeing the problem. I'm selecting the planet. Let me try some things this evening.

[BlindedByTheLight]

doctorjoe... I actually was unable to build the latest patches from 7-11-05 (running Mac OS X 10.4.2 now - if that makes a difference) because I am unable to build the latest code from CVS

Here is a pic of the error I got:



I'm guessing some of the new stuff Chris uploaded is causing the difficulty?

[doctorjoe]

Looks like stuff is being checked in.

Will try again tomorrow.