Cannot display asteroids and comets... under Linux

[Esteban]

Hi all,


I installed the precompiled package of Celestia on my Ubuntu system. It's working great but I cannot see any asteroids, minor satellites and comets.
For example I cannot see Eros, Phobos, Deimos... while I can see moon, Ganymede and so on.
I have the texture correctly installed and even installed more ine the extras folder but it gives nothing for all object which are asteroids or comets class...

Has anyone experienced this?

Thanks for the help

My comp is :
Toshiba Satellite
Centrino Duo
ATI 1800
Ubuntu Dapper Drake
Celestia is 1.3.2

[jromer]

I installed the autopackage version 1.4.1 on my Ubuntu 6.06 sys and I see comets/asteriods but not any spacecraft or irregular shaped objects like Demos. (cmod issue I believe) If there is a fix to this I sure would appreciate it)

[selden]

That's a bug in the compilation process for Celestia v1.4.1 when compiled with gcc v4.

You need to add

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to the makefile

The code has been fixed in cvs so v1.5 of Celestia will not require that compiler option.

See
http://celestiaproject.net/forum/viewtopic.php?t=10129&

[nalmeth]

I've tried the above fix, and still cannot see any models for MIR, Cassini, or any spacecraft at all, as well as Mars' moons.

I'm also using Ubuntu, I compiled --with-kde, but have also tried with-gtk, with-gnome (with the fix), the autopackage, and Ubuntu's OLD 1.3 version.

I've also tried the following fix from user Boux:
http://www.celestiaproject.net/forum/viewtopic.php?t=9605

Code: Select all

First:

export CFLAGS="-fno-strict-aliasing -O3 -march=pentium4 -fomit-frame-pointer -pipe -fprefetch-loop-arrays -funroll-loops -ffast-math"

Second:

CXXFLAGS=$CFLAGS

Then, as usual:

./configure --with-kde --with-lua --disable-debug
make

According to this post:
http://celestiaproject.net/forum/viewtopic.php?t=10129&
The cmod -> 3ds problem is fixed in CVS? Can anyone confirm?
EDIT: Dummy ,
Got the link from you selden, thx.

I guess I'll go try CVS, but the fix hasn't solved anything whilst compiling. For me anyway

[cartrite]

nalmeth wrote:

According to this post:
http://celestiaproject.net/forum/viewtopic.php?t=10129&
The cmod -> 3ds problem is fixed in CVS? Can anyone confirm?

That is conerning cmods and CVS and had nothing to do with 3ds.

[nalmeth]

That is conerning cmods and CVS and had nothing to do with 3ds.

Yes, I know that.
From Suwalski From this thread: http://www.celestiaproject.net/forum/viewtopic.php?t=9335

I am the cause of this, see:

http://cvs.sf.net/viewcvs.py/celestia/c ... 6&view=log

But the good news is that it's intentional. The models directory was made to match the Windows distribution, and not include the 3ds files when they are not needed.

You can consider the .3ds file to be the "source" for the .cmod file, which is the model that Celestia actually loads. Like all good make-installs, we don't install source! My optimizations actually save sourceforge about 6 megs per download.

How does this cause a problem? The 3ds files should never be used...

This is why I said cmod -> 3ds to relate to the problem with missing cmods, whether or not they are part of problem/solution.
In any case, the fix didn't work for me, so I asked a question. If you can't confirm the problem is solved in CVS, then I'll await other answers, and will be checking it out later today anyway.

[cartrite]

I was just ready to edit my post to read:

I was unaware that this problem affected version 1.4.1

but now I don't have to.

The 3ds files were no longer included if they had a cmod counterpart.

This had nothing to do with the cvs cmod visability problem

The problem I had a when compiling the cvs verions with gcc 4.0 was cmod files were not visible if they were in binary format. This was fixed and I was the one who started the thread you provided a link to. I didn't want confusion to start with people thinking there was a problem with 3ds.

Edit: Apparently I was aware of a problem with version 1.4.1 and had forgotten. I guess my memory is failing in my old age.

[nalmeth]

I was unaware that this problem affected version 1.4.1

Really? hmmm So 1.4.1 worked fine for you (with models), but CVS didn't display the models (until now)?

I'm quite sure it's not my Ubuntu install, I had the same problem on my previous install. And I've setup a new video card since too.

When I'm back home I guess I'll make sure the cmods are setup, maybe try to pull together some sort of report, then try the latest CVS for good measure.

It is kind of a confusing state of affairs.. Frustrating too.
Thanks for elaborating your post, hopefully I can figure something out today.

EDIT: OK, I see about 1.4.1, it's actually a relief to hear it wasn't working, you had me worried it was something on my side at fault.
I don't think its your age though, look at my short-term memory in my previous posts above... I'm only 20

[cartrite]

nalmeth wrote:

In any case, the fix didn't work for me, so I asked a question.

What fix are you referring to? This one?

Code: Select all

CXXFLAGS=-fno-strict-aliasing

That was added to my ./configure line and not the makefile.

BEGIN EDIT:10/03/2006:This is for future reference. Another way to add the CXXFLAG "-no-strict-alaising" to Celestia so that it can be built to correct the binary cmod bug in version 1.4.1 source, the file configure.in (not a makefile) can be edited as follows:
Edit lines 98 and 99 from:

Code: Select all

CELESTIA_CFLAGS="-O2 -Wall -ffast-math -fexpensive-optimizations"

Code: Select all

"CELESTIA_CXXFLAGS="-O2 -Wall -ffast-math -fexpensive-optimizations"

to:

Code: Select all

CELESTIA_CFLAGS="-O2 -Wall -ffast-math -fexpensive-optimizations -fno-strict-aliasing"

Code: Select all

CELESTIA_CXXFLAGS="-O2 -Wall -ffast-math -fexpensive-optimizations -fno-strict-aliasing"

Then run aclocal, autoconf, and automake. After this is done, you can run ./configure as you would normalily. I think it is easier to just add the option to the ./configure line.

Code: Select all

./configure (your options)  CXXFLAGS=-fno-strict-aliasing

END EDIT 10/03/2006



You may also want to try the tool cmodfix and convert a binary cmod file to ASCII and see if that works. If the fix I mentioned above concerning the ./configure line doesn't work you may have a different problem. If you can't see ASCII cmods files then you do have a different problem. They (ASCII) were never affected. The windows cmod fix can be found here. http://www.celestiaproject.net/~claurel/celestia/cmodtools/
I run it in Linux with Wine. It is also in the src/tools/cmod directory of Celestia but will have to be built.

Edit: Come to think of it, I can't remember if I tested that work around with version 1.4.1 or not. I was trying to work out the bugs of my new 64 bit Suse OS at the time and I may have been satisfied with cvs working and stopped there. I'll do a quick compile and post the results.

Edit: I can now confirm that the workaround, add the following to the ./configure line.

Code: Select all

 CXXFLAGS=-fno-strict-aliasing

works for the source code for 1.4.1 and fixes binary cmod file visability problem. On the Suse x86_64 10.0 OS. gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)

cartrite

[nalmeth]

Edit: I can now confirm that the workaround, add the following to the ./configure line.
Code:
CXXFLAGS=-fno-strict-aliasing
works for the source code for 1.4.1 and fixes binary cmod file visability problem. On the Suse x86_64 10.0 OS. gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)

Wow, excellent
Thanks for the effort cartrite

I may have been overwhelmed by all the possible causes/fixes that I didn't enter the line properly, or edited the wrong file.
You know how it is.. Many different routes confuses the brain
Then again, I tend to do 'unhealthy' things to my installations, so I may have another problem on my hands.

I'm sitting here at work on windows seeing everything fine, so I'll run this again when I get home.

Thanks again, it's a vote of confidence

BTW, did you try Boux's alternative fix for this? His comments had me worried about creating instability with this fix, but no one else has commented as such.

[cartrite]

Hey no problem,

nalmeth wrote:

I may have been overwhelmed by all the possible causes/fixes that I didn't enter the line properly, or edited the wrong file.

I think back when I first tried that workaround I was trying to add it to a file, and a couple of times I think I got it to work, but I'm not sure which one it was now. I don't think it was a makefile though. After I edited the file I ran make -f Makefile.cvs. I think? That was for cvs version though.That's when that line was added to the all the makefiles created. Anyhow, it was easier to add it to the ./configure line. I'm sure.

Edit: I tried Boux's way but I think I had some problems getting it to work and I gave up because I had too many things going on at the time. Anyhow I never noticed any instability.
Edit:I may be wrong but I think that the older gcc compilers used that option by default and it was discontinued by the newer compilers after version 3.something. So if there were any instabilities caused by using that option, the vast majority of users would probally see the same instabilities who use the older compilers.

[cartrite]

I just tested the autopackage 1.4.1 on Suse 10.0 and I didn't have any problems with cmods and I didn't alter a thing. This seems to be a different problem with cmods that affects the Ubuntu system.
I wrote:

I was unaware that this problem affected version 1.4.1

Edit: Apparently I was aware of a problem with version 1.4.1 and had forgotten. I guess my memory is failing in my old age.

That may be why I thought I wasn't having problems with 1.4.1. I must have been remembering the autopakage.
cartrite