Celestia Forums

Chris, is it possible to get some form of texture compression working in the linux version of celestia? FXT1 doesn't work but it only supports textures to 2048x2048 so isn't ery useful anyway. I tried S3TC but it seems that is just the same as DirectX's DXT1/5 format, which causes a segfault when it tries to load in celestia...

Ortolan wrote:Chris, is it possible to get some form of texture compression working in the linux version of celestia? FXT1 doesn't work but it only supports textures to 2048x2048 so isn't ery useful anyway. I tried S3TC but it seems that is just the same as DirectX's DXT1/5 format, which causes a segfault when it tries to load in celestia... :(

Here I have quite a success story to tell (I also had SEGFAULTS after loading DXTx compressed files under Linux).

Aparently, the reason for these problems /and/ the SEGFAULTS upon approaching the ring planets in 1.2.4preview is quite subtle:

There are different and partly incompatible glx-devel packages/headers around:

1) The latest official xf86_glx_(devel)-4.2.0 with static libs and .../include/GL headers

2) mesa-devel (3.4.2) package with headers and libs

3) /usr/include/GL/* headers as provided with the NVIDIA-1.0-2880 drivers


Previously, I had (1) installed which caused the various SEGFAULTS reported here before (!)....

Recently, I have switched to (2) and, amazingly, the SEGFAULTS associated with DXTx-loading /and/ the ring-approach in 1.2.4 are gone!

What remains is a SEGFAULT in 1.2.4 preview, arising upon pressing CTRL-v for planets where a bumpmapping file is loaded (mercury,...). I am working on that...

Meanwhile, I have generated many /large/ *.dds texture files under Windows ME, using the NVIDIA DXT_tools /and/ gimp. Everything works beautifully /and fast/ (after I have eliminated a number of bugs/misprints in the 1.2.4preview). Now the CTRL-key works again and most of the other key-shortcuts.

Among the most beautiful *.dds files I made are:

1) A super-hires texture (8k) with the night illumination! This together with my 8k earth.dds is simply amazing.

2) Using gimp I reduced the rgb monster mars textures to 8k each, gave it an unsharp masking treat for even better sharpness/definition and converted the corresponding 125MB mars.tga file unders Windows ME with the command

nvdxt -file mars.tga -dxt1c

to *.dds.

3) A moon8k.dds file reduced from the huge moon texture available on the NASA page.

4) A hires pluto.dds (4k), that has a beautiful ice specular reflection via an alpha channel that I added.

Bye

Fridger

I'm using the GLX library provided by nvidia. Is it possible to use nvidia's binary drivers with the mesa GL libs? Being able to use 8k x 4k textures sounds so cool, I've got to get it working on my computer...

Ortolan wrote:I'm using the GLX library provided by nvidia. Is it possible to use nvidia's binary drivers with the mesa GL libs? Being able to use 8k x 4k textures sounds so cool, I've got to get it working on my computer... :D

There seems to be some misunderstanding after my statements above. Clearly all of us with NVIDIA cards are using the original NVIDIA dynamical libs/drivers for hardware acceleration.

The crucial issue is what headers (.../include/GL/*.h) etc are used upon /compilation/ of celestia!

I said that there was a set of headers in the xf86_glx-devel package (SuSE 7.3 nomenclature) that one should /not/ use. Check out the contents in ftp://ftp.suse.com/pub/suse/i386/7.3/su ... 6glx-devel

The headers that work are listed in
ftp://ftp.suse.com/pub/suse/i386/7.3/su ... mesa-devel

In addidion, the NVIDIA Linux driver package contains a set of headers for /usr/include/GL. These I have not tested in great detail.

Fridger

Ortolan wrote:I'm using the GLX library provided by nvidia. Is it possible to use nvidia's binary drivers with the mesa GL libs? Being able to use 8k x 4k textures sounds so cool, I've got to get it working on my computer... :D

There seems to be some misunderstanding after my statements above. Clearly all of us with NVIDIA cards are using the original NVIDIA dynamical libs/drivers for hardware acceleration.

The crucial issue is what headers (.../include/GL/*.h) etc are used upon /compilation/ of celestia!

I said that there was a set of headers in the xf86_glx-devel package (SuSE 7.3 nomenclature) that one should /not/ use. Check out the contents in ftp://ftp.suse.com/pub/suse/i386/7.3/su ... 6glx-devel

The headers that work are listed in
ftp://ftp.suse.com/pub/suse/i386/7.3/su ... mesa-devel

In addidion, the NVIDIA Linux driver package contains a set of headers for /usr/include/GL. These I have not tested in great detail.

Fridger

Arrgghh!! I got stuck in an infinite dependency loop trying to remove the xfree86-devel package. Took me two hours just to get back to square one so I won't be trying that again any time soon...

Ortolan wrote:Arrgghh!! I got stuck in an infinite dependency loop trying to remove the xfree86-devel package. Took me two hours just to get back to square one so I won't be trying that again any time soon... :cry:

I don't see what could have happened. Of course, replacing basic packages requires a certain "know how"...

In the console, type

rpm -ql xf86glx-devel

to check what files are in the package that you want to deeinstall.

Next

rpm -e --nodeps xf86glx-devel

to /just/ deinstall xf86glx-devel without taking notice of any dependencies.

Next:

rpm -pql mesa-devel.....rpm

to check whether this package indeed contains the needed headers etc.

Next
rpm -ihv mesa-devel ...rpm

to install.

finally, check all links for the static libs etc and do a

ldconfig

boot X

recompile celestia.

Much luck

Fridger

ok, I did all that. Celestia compiles now at least. I had been trying Mandrake 8.1's Mesa and Mandrake Cooker Mesa with no luck, I then got the Mesa packages built for Red Hat and it compiled, weird... Now if I use a .dds texture for a planet it doesn't segfault but I just get an untextured sphere (dds texture in medres directory, solarsys.ssc file modified accordingly).

Ortolan wrote:ok, I did all that. Celestia compiles now at least. I had been trying Mandrake 8.1's Mesa and Mandrake Cooker Mesa with no luck, I then got the Mesa packages built for Red Hat and it compiled, weird... Now if I use a .dds texture for a planet it doesn't segfault but I just get an untextured sphere (dds texture in medres directory, solarsys.ssc file modified accordingly). :?

It looks like some kind of progress, at least.

Please, make really sure that /all/ headers/libs are definitely from the packages you think they are!

rpm -qf <file>

usually gives the corresponding package. Check notably in /usr/include/GL and /usr/X11R6/include/GL with
rpm -qf *.h

Please, make sure that you use the /1.2.4 preview version/, since the 1.2.2 version does exactly what you described if I correctly remember...

Please, check also whether in the 1.2.4version you now may approach saturn/uranus without provoking a SEGFAULT. Then you are certainly on the right track!

It is crucial in solarsys.scc to comment out the statement
'CompressTexture true'
if *.dds files are to be used.

I am sure you tried to switch resolution with R/shift R when the untextured earth sphere was displayed.

Further info may come from running celestia as argument of 'strace'.

What again was your NVIDIA graphics card/storage size?


Let's see how it goes;-)

Fridger

Ortolan wrote:ok, I did all that. Celestia compiles now at least. I had been trying Mandrake 8.1's Mesa and Mandrake Cooker Mesa with no luck, I then got the Mesa packages built for Red Hat and it compiled, weird... Now if I use a .dds texture for a planet it doesn't segfault but I just get an untextured sphere (dds texture in medres directory, solarsys.ssc file modified accordingly). :?

It looks like some kind of progress, at least.

Please, make really sure that /all/ headers/libs are definitely from the packages you think they are!

rpm -qf <file>

usually gives the corresponding package. Check notably in /usr/include/GL and /usr/X11R6/include/GL with
rpm -qf *.h

Please, make sure that you use the /1.2.4 preview version/, since the 1.2.2 version does exactly what you described if I correctly remember...

Please, check also whether in the 1.2.4version you now may approach saturn/uranus without provoking a SEGFAULT. Then you are certainly on the right track!

It is crucial in solarsys.scc to comment out the statement
'CompressTexture true'
if *.dds files are to be used.

I am sure you tried to switch resolution with R/shift R when the untextured earth sphere was displayed.

Further info may come from running celestia as argument of 'strace'.

What again was your NVIDIA graphics card/storage size?


Let's see how it goes;-)

Fridger

ah, I'm using 1.2.2 so that's probably the problem. Downloading 1.2.4 now, will report how it goes..(fingers crossed)

WooHoo!! After several hours struggling with RPM dependencies and a broken X server I got a working configuration for DXT support. *dances around like an idiot*
Damn, those high-res textures look coooooool! Now I need to convert my entire medres folder to 4kx2k DDS textures and make some 8k ones for the highres folder.
Next step, a 128MB GeForce4 and 16kx8k textures..

Ortolan wrote:WooHoo!! After several hours struggling with RPM dependencies and a broken X server I got a working configuration for DXT support. *dances around like an idiot* :D
Damn, those high-res textures look coooooool! Now I need to convert my entire medres folder to 4kx2k DDS textures and make some 8k ones for the highres folder.
Next step, a 128MB GeForce4 and 16kx8k textures.. :)

Love to hear this!! It's really great with those *.dds files.

Yesterday night, I even dared to combine a 22MB 8kx4k earthnight.dds with 22MB 8kx4k earth.dds, and still get >20 fps with a 1280x960 window in my 1600x1200 screen, 16bit color and earth filling the whole window!
All this with 32MB in my GeForce 2 GTS.

I actually found somewhere in the mails that Chris had tested his code also with the Mesa 3.4.x headers in case of Linux...

Bye Fridger