Texture compression for Linux

[Ortolan]

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...

[Guest]

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

[Ortolan]

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...

[Guest]

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

[Guest]

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]

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...

[t00fri]

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

[Ortolan]

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).

[Guest]

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

[Guest]

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]

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)

[Ortolan]

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..

[t00fri]

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