Celestia and virtual reality CAVE

[seiryuukami]

Hello,

I'll start with a short introduction.
I'm Ben, I'm a 21 year old Dutch student. My field of study is Engineering and Computing sciences.
Since February I've been working (internship) for the Fontys University of Applied Sciences. My department is the virtual reality lab.

The project I've been designated is the integration of Celestia with the CAVE of Fontys here.
To do this, I am to use a program called vrJuggler.
Some links with more information:
CAVE http://um3d.dc.umich.edu/hardware/CAVE/
vrJuggler http://www.vrjuggler.org/

I've downloaded a copy of Celestia's source code, it's dependencies and got MS visual studio 2005.
I can compile and run Celestia. (no debug though, which is quite a pain)
I've also began to integrate vrJuggler with Celestia.
But, I've ran into a number of very odd runtime errors and significant loss of image quality.

I'm looking for someone who is willing and able to help me. I have been reading the source code and its documentation, but there's much that still eludes me. (yeah, I'm not very clever) I'm looking for very detailed information about especially the Render part of the source code.
Can anyone help me?
Should I just post my questions right here?

[selden]

A group in Brazil modified an older version of Celestia to work with their Cave using Glass.
Have you tried contacting them? See http://www.lsi.usp.br/~paiva/glass/glass.htm

There are only one or two people who understand Celestia's rendering code. (Not me!) You might as well ask your questions here. Maybe others can chime in with suggestions.

[seiryuukami]

Thank you.
My chances of running into one of those people would be... not high?

I know it's been done before. Unfortunately I must use vrJuggler for my project. <_< I don't really have a choice.
I'll try to contact the people who've made it work before.

Here some details about the problems I've encountered and things I'd like more information on.

To make a program work with vrJuggler (when it works with vrJuggler, it works with our CAVE) the program must be divided into a few specific functions.
There's a calculation function called "preframe", meant to preform the calculations needed. I've linked it to the function CelestiaCore->tick().
Basically that is the 'main loop' of the program.
Then there is the infamous "draw" function. This calls the main render loop. So obviously I've linked it to Simulation->render( *renderer );
This works, but the images that are produced are not very pretty. One can recognize planets (some textures don't work while others do) stars have a great yellow-ish square around them. And most fascinatingly, when I approach Mars's Deimos... the program causes an access violation. Attempt to read address NULL.

At this point I must say I've removed the entire Windows front end. There are no windows, menu bars, any of that. vrJuggler creates it's own render windows when the program is started, and for the time being, I am content not to be able to give any input to this Celestia-ish program.

I suspect because there is no main window or anything like it, a lot of variable in the program are incorrect. (like windowHeight, pixelSize)
If anyone has a suggestion on how to fix this problem adequately, please do share.
However I had desperately sought for a callback like function that I thought I deleted and could be responsible for the access violation, but came up empty.

I've had to make an adjustment to the GetTextureCaps() in texture.cpp. Because of the absence of a GLwindow this function was returning 0, causing a devision by 0 elsewhere in the code. So I've opened an unmodified version of Celestia to see what values this function returns under 'normal circumstances', I've adjusted to GetTextureCaps() to return a more useful value when it would originally come up with 0.

What I know that I need to do, but I could really use some help with is this.
The render function is too intelligent at the moment. I see it does lot's of checking, making sure objects over vast distances remain visible and that's good! I will need that.
But what it also does it check of objects are within the field of view, or viewport of the window. Which is bad because in the CAVE there's a lot more that can be seen.
Also I'm not sure what to make of the Frustum... I don't understand what it does.
What I need to render function to do is:
Position the user of camera and render each object without checking if it is in the FOV, but with checking if it is out of range.

I shall make a few screenshots, I hope they'll help.

[selden]

The symptoms you describe look very much like OpenGL bugs. What version of OpenGL is implemented in your Cave system?

Can you run Celestia unmodified, using just one "wall" perhaps? That might provide a reasonable test of the OpenGL library to try to eliminate it as the source of the problems. Or would running that way have to use a different OpenGL library?

Are Celestia's keyboard commands still available?
i.e. can you type a Ctrl-V to step through the render modes available in the Cave?

[seiryuukami]

Thank you.
I really do hope you are wrong and these are not OpenGL bugs... but you're right I must consider the possibility.

Unfortunately, it's not possible to run Celestia unmodified on one wall.
To run on a wall, it needs vrJuggler, and juggler demands that I mess up the code significantly.

However!
I've done the following, and found the following:
I've traced what would happen in a normal Celestia when you press CTRL + V, and I've modified my juggler-Celestia to "press on CTRL + V" a few times on start up. The program cannot receive input from mouse or keyboard, so simply put, I made it give itself input. ^_^;;

I found that no matter how often I try to chance the render path, nothing changes. So I made it spit out a few values and found it most enlightening.
the render path is 0. Always. It only seems to use Basic.
Could this be a cause of the ugliness?
What could cause this?
And can it be helped? How?

*edit x2*
O__O I just found out that the function Renderer::renderBodyAsParticle is causing the squares around the sun
I've commented the content of the function, and the square around the sun is gone... it still shows for other stars...
How does this make sense?

[selden]

You need to discuss the OpenGL library with your local system administrator to find out what your Cave libraries are intended to be providing. The problems with textures and squares usually are caused not by obsolete OpenGL but by buggy OpenGL. Celestia depends on the libraries being correctly implemented. It may simply be that the libraries haven't been updated for a long time. They're usually free for downloading from the company that makes the graphics hardware. Under Windows XP you can disable graphics hardware acceleration entirely, which causes the use of MicroSoft's software OpenGL libraries. They're slow, but do seem to implement OpenGL v1.1 accurately.

Render path Basic roughly corresponds to requiring OpenGL v1.1. Under Windows, the Render paths and their major feature differences are
* Render path: Basic (objects, clouds and eclipse shadows) OpenGL v1.1
* Render path: Multitexture (NightLights) OpenGL v1.2
* Render path: OpenGL vertex program (Specular and BumpMaps & Ring shadows) OpenGL v1.4
* Render path: OpenGL 2.0 (multiple light sources & shadows; sprites)

In other words, to see all of Celestia's eye candy, the host computer's graphics must provide OpenGL v2.0.

Celestia tests for the availability of various OpenGL functions to decide which Render paths are available. I don't know exactly where it does that. You're already much more familiar with the code than I am.

I hope this helps a little.

[seiryuukami]

Yes! Thank you, now we're getting somewhere.

I think the/a problem is that with the removal of the GLwindow, Celestia can no longer determine which versions of OpenGL I have available.
With an unmodified version of the source code, Celestia does run in all its glory. So I don't see a reason to doubt the libraries themselves.

I'm looking for a way to ensure Celestia will render as if there is OpenGL 2.0 available, eventhough it may not detect it while initializing.

Please, keep the good ideas coming. ^_^

[seiryuukami]

I have some news!

After much tracing of variables I've found the part responsible for the ugly squares!

In function: StarRenderer::process

// If the star is brighter than the saturation magnitude, add a
// halo around it to make it appear more brilliant. This is a
// hack to compensate for the limited dynamic range of monitors.

This function adds a new particle to the glareParticles vector.
The function that then handles the actual rendering of this particle is Renderer::renderParticles

by replacing glBegin(GL_QUADS);
with glBegin(GL_SPHERE_MAP);
in the renderParticles function, the squares disappear.
unfortunately, this is exactly the same result as when one removes the renderParticle function entirely...

I've been able to increase the general image quality significantly by hardcoding the values for windowHeight and windowWidth. (to some very high values with the correct ratio)

The main pain in the ass right now is that the program seems to use 0 hardware acceleration.
When I approach a planet with many moons like Saturn, the whole thing lags a lot...

Do you have any idea how I can get the program to use acceleration again? Where should I look for how it got turned off in the first place?

*edit*
I've been hunting down the access violation I get when I approach Mars/Deimos.
I found that it also occurs when I go to:
Mars/Phobos
Jupiter/Adrastea
but not when I go to Jupiter/Io or Jupiter/Europa.

I think it's caused by the shape of the satellites. Io and Europe are spherical moons, while Phobos, Deimos, and Andrastea are more asteroid-shaped.
Do you know which part of the code is responsible for rendering those more rock-like objects?

[selden]

3D graphics hardware acceleration is controlled by the operating system, not by Celestia. Under Windows, it's in the Display Properties menu.

e.g. select
Start
Control Panel
Display icon
Settings tab (upper right)
Advanced button (lower right)
Troubleshoot tab (upper right)
move the Hardware Acceleration slider all the way to the right

[seiryuukami]

I have found the cause of the segfault (aka access violation) when rendering asteroids and not-spherical moons and such.

In the file mesh.cpp, line 522 (give or take)
"glx::glGenBuffersARB(1, &vbObject);"
This operation causes the segfault.
When I comment it, and the models still render. But! after using a goto command to fly to Deimos or any other such object, the camera misses the target and I get a great view of just-out-of-view-Deimos. So I suspect the function was some kind of translation.
Can anyone tell me more about this operation, and how it can generate a segfault?

[Giel]

I have found the cause of the segfault (aka access violation) when rendering asteroids and not-spherical moons and such.

In the file mesh.cpp, line 522 (give or take)
"glx::glGenBuffersARB(1, &vbObject);"
This operation causes the segfault.

That would be another indication of missing hardware acceleration (or more specifically an older OpenGL version). This is because the function glGenBuffersARB is only available when the ARB_vertex_buffer_object OpenGL extension is provided. From OpenGL version 1.5 this extension is included by default, but the software implementation of OpenGL on Windows implements OpenGL version 1.1

When I comment it, and the models still render. But! after using a goto command to fly to Deimos or any other such object, the camera misses the target and I get a great view of just-out-of-view-Deimos. So I suspect the function was some kind of translation.

Nope, that function just generates unique names for buffer objects (i.e. it doesn't actually generate those buffer objects themselves).

This page describes that function more accurately: http://www.opengl.org/sdk/docs/man/xhtm ... uffers.xml

Btw, you can get an overview of all (core, i.e. not part of extensions) OpenGL functions here: http://www.opengl.org/sdk/docs/man/ (note, this is about OpenGL 2.1).

Can anyone tell me more about this operation, and how it can generate a segfault?

The reason it generates an exception is because that operation doesn't exist. I.e. you're probably calling a NULL pointer (i.e. trying to execute code at memory location 0).

[chris]

I have found the cause of the segfault (aka access violation) when rendering asteroids and not-spherical moons and such.

In the file mesh.cpp, line 522 (give or take)
"glx::glGenBuffersARB(1, &vbObject);"
This operation causes the segfault.

That would be another indication of missing hardware acceleration (or more specifically an older OpenGL version). This is because the function glGenBuffersARB is only available when the ARB_vertex_buffer_object OpenGL extension is provided. From OpenGL version 1.5 this extension is included by default, but the software implementation of OpenGL on Windows implements OpenGL version 1.1

When I comment it, and the models still render. But! after using a goto command to fly to Deimos or any other such object, the camera misses the target and I get a great view of just-out-of-view-Deimos. So I suspect the function was some kind of translation.

Nope, that function just generates unique names for buffer objects (i.e. it doesn't actually generate those buffer objects themselves).

This page describes that function more accurately: http://www.opengl.org/sdk/docs/man/xhtm ... uffers.xml

Btw, you can get an overview of all (core, i.e. not part of extensions) OpenGL functions here: http://www.opengl.org/sdk/docs/man/ (note, this is about OpenGL 2.1).

Can anyone tell me more about this operation, and how it can generate a segfault?

The reason it generates an exception is because that operation doesn't exist. I.e. you're probably calling a NULL pointer (i.e. trying to execute code at memory location 0).

It sounds like Celestia is not correctly detecting the presence of the vertex buffer object OpenGL extension. If the extension is not available, Celestia shouldn't be calling the function. I'll see if I can figure out how this could be going wrong. Are you using the most up to date drivers? All recent OpenGL drivers should include support for the vertex buffer object extension.

--Chris

[seiryuukami]

Thank you very much for your posts!

Truth be told, I'm not 100% sure.
But when I first got a copy of the Celestia source and compiled it, it worked exactly as it is supposed to.

I suspected there was something wrong with Celestia's extension detection after I introduced vrJuggler. Like Selden suggested I tried to change the render path while running the program. But it always uses Basic. (when the source was unmodified, it could use a lot more render paths)

With a lot of help from Giel I am now trying to use Cygwin to compile Celestia. In an attempt to get debug options.

[seiryuukami]

There is news!

Giel and I managed to figure out why Celestia's extension detection didn't work.
As it turns out, Celestia was attempting to create and initialize it's GLContext before OpenGL was initialized.
OpenGL is initiated much later on in the program by vrJuggler.
We've solved this by re-initializing the GLContext right before the render loop is called for the first time.
This way a healthy render path can be chosen. The program now use OpenGL 2.0 as default... which sure as hell beats basic!

However! New/old problems showed up as a result of the new render path, and I was hoping you could provide me some insight as to what functions or parts of code or now called (in the GLPath_GLSL) that have remained dormant up until now.
I understand that's a lot, so I'll narrow the parameters by naming the symptoms.
Only the front screen is used to render stars and planets. (I've had this problem before, and fixed it by making sure no rendering of objects ends up in the Projection matrix. Did the same check this time, but it seems like I've missed something... do you know where I should look?)
Orbits and Labels do render on the other screens. However! Orbits are only visible as long as they are 'really close'. When in orbit around the moon, the orbit shows well enough, but when the demo.cel shows the inner solar system, no orbits are shown.
Stars that are rendered as points are appearing as squares of various color and size. Giel has determined this has to do with the shaders being used. The size of the stars is not computed properly because of the invalid screen size. I'm trying to find a valid workaround, but so far vrJuggler hasn't given me much to work with.

[seiryuukami]

I've solved the issue of the square-long-distance stars by hardcoding a boolean!
in void Renderer::PointStarVertexBuffer::render()
bool useSprites.
true gives the squares, false looks like normal.

This issue I'm currently breaking my brain over is,
How come the moon gets rendered... while the Earth and the sun do not?
I thought the same code responsible for rendering a moon was rendering planets as well.
Where do theirs paths uncross?
As far as the missing sun goes... I am still clueless.

[selden]

Does Mars get rendered?

Both the Moon and Mars have bumpmaps associated with them. The Earth and Sun do not.

[seiryuukami]

Good thinking sir, thank you!

Mars does render! so the lack of bumpmaps must somehow make other planets invisible...
Also I must mention, Mars does look terrible.
It seems to have a disagreement with the view frustum. *insert image*

I have changed view frustums and camera rotations where ever I could find them, to not clip or cull objects that might be visible on the right, left or bottom window. I've done this by introducing a for-loop, like so:

for(int i = 0; i < 4; i++)
{
Quatf ori = observer.getOrientation();

if(i == 2)
{
ori.rotate(Vector3<float>(1.0,0.0,0.0),(0.5 * PI));
}
else
{
ori.rotate(Vector3<float>(0.0,1.0,0.0),(0.5 * PI) * i);
}

starDB.findVisibleStars(starRenderer,
obsPos,
ori, // used to be observer.getOrientation();
degToRad(fov),
(float) windowWidth / (float) windowHeight,
faintestMagNight);
}

The plan is that this way objects visible on all four screens will be added to the starRenderer's list.
I've no evidence pointing out that this is causing the odd-ness Mars is experiencing. However! It does allow Mars/Moon to render on the other screens without a texture. I suspect there is another "are you in view" check for textures.... perhaps we gone a little overboard with all the checks..?

[seiryuukami]

Hello,

I've integrated a Wii controller with my perversion of Celestia, and I must say it's nice to have some control over the program back. I'm here to report my findings and ask what the hell is going on. ^_^

I have linked a few buttons of the wii controller to a few simple functions in Celestia. The result left me quite dumbfound.

I've been working with a start.cel script that would take me directly to Earth, Moon or Mars. (since I was having the problem that I couldn't see Earth, but could see the moon or the mars) But! When I pressed the button on the wii controller to take me to Earth, it worked and I could see the planet. Aside from the atmosphere rendering on all view windows, the thing looks quite nicely. Which is good! But....
How can the Earth not show up when the start script takes me to it,
and do show up when I execute the following code: (code under wiiMote button event, in class CelestiaCore)
{
Selection sel = this->getSimulation()->findObject("Earth", true);
if (!sel.empty())
this->getSimulation()->setSelection(sel);

this->getSimulation()->follow();

this->charEntered('G');
}

start.cel is this:
{
timerate { rate 0 }
labels { clear "planets|minorplanets|stars|constellations" }
renderflags { set "stars|planets|orbits|galaxies"
clear "constellations|cloudmaps" }
wait { duration 2.0 }

select { object "Earth" }
goto { time 5 distance 4 upframe "equatorial" }
wait { duration 5.5 }
print { text "Watch for the Earth and Sun as we orbit the Moon" row -3}
orbit { axis [ 0 1 0 ] rate 30 duration 10 }

wait { duration 2 }

rotate { duration 10 rate 15 axis[0 1 0] }
wait {duration 10 }
}

I know I don't have to type this-> but I love the auto completion.
Can anyone explain to me how calling this code is different from running a cel-script?

[selden]

I notice that in both cases you aren't specifying the full path to Earth.
For the code to be robust, you should select "Sol/Earth".

If some other star happens to be selected, Celestia won't be able to find the Earth.
Might that be related to your problem?

[seiryuukami]

I'm sorry, I should have told you I tried that. And it makes no difference.

I have figured out the cause of this.
It turns out to be exactly the same problem that causes Mars to appear so... wrong!

The near and far planes of the view frustum do not work properly.
(vrJuggler uses it's own view frustums <__< Grr! )
So I didn't see the Earth because the demo script had a to high number for distance.
The goto command took me a lot closer, so the planet did show up and then it actually looks really nice.

I'll now be looking into vrJuggler some more to see if there is a healthy workaround.
In the meantime I'd like to ask you a few not render related questions.
Those are easy, right? ^_^

Chew on this code a bit please.

state = mWiiMoteB->getData();
if(state == gadget::Digital::ON)
{
Selection sel = this->getSimulation()->findObject("Sol/Earth", false);
if (!sel.empty())
this->getSimulation()->setSelection(sel);

this->getSimulation()->follow();

this->charEntered('G');
}

state = mWiiMotePlus->getData();
if(state == gadget::Digital::ON)
{
Selection sel = this->getSimulation()->findObject("Sol/Jupiter", false);
if (!sel.empty())
this->getSimulation()->setSelection(sel);

this->getSimulation()->follow();

this->charEntered('G');
}

This is part of the Wii Controller interface. Deceptively simple. Just how I like it!
Simply put, if I press the B button, Celestia takes me to Earth. This works.
If I press the Plus button, Celestia should take me to Jupiter... but it doesn't.
Selection sel.empty() is true then. How come?
And what exactly does that boolean do? (tried both true and false, noticed no change)
If you know of a more elegant way to do what I'm describing in this code here, please do share!