Hacking Celestia - displaying lines in front of planets

[captainhannes]

Hi all!

For a scientific visualization I need to display things like:
* a line from Jupiter to Earth
* a line from Io to Jupiter
* a bow from Io to Jupiter

I've managed to modify the code in render.cpp and added the drawing stuff to Renderer::renderOrbit. Everything displays - so far so good.

The problem is that i.e. the line from the center of Earth to the center of Jupiter doesn't seems to penetrate Jupiter in the ecliptical plane. That means, Jupiter is always in the foreground and the line always ends where Jupiter's disc begins. The same for the line from Io to Jupiter and the bow.

After trying things for a few hours I'm lost. How can I tell OpenGL to render the lines correctly -> that means, that the line actually penetrates Jupiter ?

Thanks a lot for any pointers!

Best regards,
Hannes.

[Paolo]

Hi Hannes.
This is the same problem that actually exists with orbits path rendering.
In order to solve it is necessary to use z-buffer techniques when planets and lines are rendered.
Due to performance issues and Z-buffer depth limitations Celestia performes a /manual/ Z-sorting instead than using the built-in OpenGL one.
So when Celestia fills the OpenGL pipeline First draws the background, then the stars, then the orbits, then the planets (over the orbits) etc.
Chris has this issue in his to-do list from a long time.
If I don't remember bad he was waiting for 32Bit floating point Z-buffers allowed by the new generation Graphic cards to solve this and other related problems.

[captainhannes]

Ciao Paolo!

Grazie mille!
I thought that the orbit path rendering as it is now is a feature and can be changed easily, in order to render paths also before the planets.
I'm still a bit clueless on how to solve my problem, but since moons are actually also rendered in front of a planet I might find the solution there.

Just as an experiment I tried to draw the line from Earth to Jupiter after the planet is rendered:
function Renderer::render
after the call to "renderPlanet" I added:

Code: Select all

               glBegin(GL_LINE_STRIP);
               glVertex3f(jx,jy,jz);
               glVertex3f(ex,ey,ez);
               glEnd();


But the line does not show up.

I also tried to draw the line from Io to Jupiter in Renderer::renderBodyAsParticle - I verfied that this function is called (in the view Io was only rendered as "particle") - but again, the line did not show up.

I guess this has something to do with OpenGL initialization, but so far I haven't found anything on google...
Could you give me a hint why the lines are not drawn in this case ?

Grazie mille e saluti dall'Austria,
Hannes.

[Paolo]

Ciao Hannes
I'm an OpenGL beginner but I guess that before rendering lines you have to save the current GL state settings, change them in order to render the line correctly and if necessary restore the saved state settings. Also a particular attention is required to manage correctly the clipping planes of the viewing frustum associated to the camera.
Perhaps if you post a Private Message to DirkPitt he will be able to solve this problem very easily.

[dirkpitt]

I thought that the orbit path rendering as it is now is a feature and can be changed easily, in order to render paths also before the planets.
I'm still a bit clueless on how to solve my problem, but since moons are actually also rendered in front of a planet I might find the solution there.

Looks like someone is already on the ball with this one:

http://www.shatters.net/forum/viewtopic.php?p=54320

I'll try this patch out myself as soon as I get the chance. Looks like it does an additional render pass for orbits to make them paint over planets.

[Cham]

Is this patch an hack ? I'm not an OpenGL specialist, but is this code (about the orbital path rendering in front of a planet) fast enough so it wont put Celestia on its "knees" while rendering many orbital paths at the same time ?

For example, there's a lot of moons around Jupiter (or many artificial satellites around the Earth). Is this code able to render them all in front of Jupiter without any big hit on the frame rate ? I guess only experimentations will tell.

This is an old bug which is due for a permanent solution.

[captainhannes]

Hi all!

Thanks a lot for all your replies!

I just wanted to try the patch, but it does neither apply clean to 1.3.2 nor CVS. So I tried to apply it by hand to 1.3.2, but it failed to compile because of undeclared variables.

I have yet to patch the CVS version by hand.
BTW, how do I compile the CVS version ? There is no "configure" script...

Thanks & best regards,
Hannes.

[captainhannes]

Got it: make -f Makefile.cvs

But there is another problem compiling the current CVS version:
# ./configure --with-gtk
It complained that it doesn't find pkg-config, but it is in my PATH. Setting PKG_CONFIG to /usr/bin/pkg-config solved it.

But then this happens:
configure: error: conditional "include_ARTS" was never defined.
Usually this means the macro was only invoked conditionally.

Thanks & best regards,
Hannes.

[captainhannes]

Hi all!

I just saw that there is something wrong with "make -f Makefile.cvs" aswell:

Code: Select all

# make -f Makefile.cvs
This Makefile is only for the CVS repository
This will be deleted before making the distribution

*** Creating acinclude.m4
*** Creating aclocal.m4
aclocal: configure.in: 255: macro `AM_GCONF_SOURCE_2' not found in library
make[1]: *** [cvs] Error 1
make: *** [all] Error 2


Best regards,
Hannes.

[BlindedByTheLight]

Here's a link to that patch that should apply cleanly:

http://www.gnacademy.org/twiki/bin/view ... Extensions