Virtual texture bug fixed in CVS

[chris]

I finally got around to fixing the bug where way too many virtual texture tiles to get loaded causing Celestia's memory footprint to skyrocket. The change has been committed to CVS. I've done some limited testing and it looks to me like memory usage is back to it's pre-1.5.0 state. Anyone who's using a 1.5.0 build: please let me know if the fix works for you as well.

--Chris

[t00fri]

I finally got around to fixing the bug where way too many virtual texture tiles to get loaded causing Celestia's memory footprint to skyrocket. The change has been committed to CVS. I've done some limited testing and it looks to me like memory usage is back to it's pre-1.5.0 state. Anyone who's using a 1.5.0 build: please let me know if the fix works for you as well.

--Chris

What a relief!!

I just quickly recompiled Celestia-CVS with my new 2.0Ghz Core 2 Duo/ 256 MB nVidia Quadro NVS 110M notebook under VS++.net 2003 and checked my FULL 64k VT tile set out: including my DXT5nm normalmap tiles, of course.

It is an incredible difference after your fix.

Even with the relatively slow harddisk in my notebook, I can display all levels up to level 5 virtually without ANY delay and VERY smoothly. The framerate is ~ 50/sec with Mie scattering activated ~100 without!

Sorry...no spare time these days.

+++++++
Edit: actually there still seems a bug in the code for dxt5nm TILES. More tonight.
+++++++

Bye Fridger

[chris]

I finally got around to fixing the bug where way too many virtual texture tiles to get loaded causing Celestia's memory footprint to skyrocket. The change has been committed to CVS. I've done some limited testing and it looks to me like memory usage is back to it's pre-1.5.0 state. Anyone who's using a 1.5.0 build: please let me know if the fix works for you as well.

--Chris

What a relief!!

I just quickly recompiled Celestia-CVS with my new 2.0Ghz Core 2 Duo/ 256 MB nVidia Quadro NVS 110M notebook under VS++.net 2003 and checked my FULL 64k VT tile set out: including my DXT5nm normalmap tiles, of course.

It is an incredible difference after your fix.

That's very good to hear. Thanks for taking the time to test out the fix. I haven't yet had a chance to fix the problem that Runar reported with VTs on ringed planets.

+++++++
Edit: actually there still seems a bug in the code for dxt5nm TILES. More tonight.
+++++++

Let me know . . . I'll have a couple hours to take a look bugs tonight.

--Chris

[rra]

confirmed over here too ,
Celestia flies again with the VT's , before
it finally would crash after paging too much memory.


Thanks ,

Ren?©

[Boux]

What a change!
VTs load very fast and smoothly.
I can use them again
Thanks!

[t00fri]

Chris,

here is now some more quantitative feedback:

1) with my full set of 64k VT tiles for Earth and my 1k normal map tiles being in PNG format, everything works PERFECTLY with my new notebook (~50fps 1440x900 fullscreen) as well as with all Linux flavors on my Desktop. Actually, my "old" FX-5900Ultra @ 3.2 GHz/3GB RAM CPU does somewhat worse ~40fps than the notebook...

2) As to my 64k/1k DXT5nm format nm-tiles, I see lots of artefacts, however! Since I was trying to adapt to your unconventional setup quite some time ago, I first had to reconstruct via an explicit layer decomposition how my tiles were composed. It turns out that they are

Code: Select all

out.r = in.g
out.g = in.g
out.b = in.g
out.a = in.r   


such that the rgb color is gray. So note, out.r and out.b are NOT zero.

Moreover, I am not sure whether you coded things such that the extension of the individual tiles may remain .dds while of course in the .ctx file, TileType "dxt5nm". This would in principle be enough information to tell Celestia, about the special DXT5 format, without the additional work of renaming 2500 tiles

So how does it have to be?

Anyway, without renaming the individual tile endings, in the console-log the loaded nm-tiles are nevertheless logged with .dxt5nm endings attached at all levels, yet there are errors stating an unrecognized format!

So honestly, I don't know what's going on there and right now I lack the time to dig through your new code myself.

Bye Fridger

[danielj]

I browse the CVS and couldn??t find the update.Where is it?

I finally got around to fixing the bug where way too many virtual texture tiles to get loaded causing Celestia's memory footprint to skyrocket. The change has been committed to CVS. I've done some limited testing and it looks to me like memory usage is back to it's pre-1.5.0 state. Anyone who's using a 1.5.0 build: please let me know if the fix works for you as well.

--Chris

[Starshipwright]

Dainel, I think that phoenix's latest build includes the update, you can get it at:

http://www.purebytes.de/stuff/celestia/

[chris]

2) As to my 64k/1k DXT5nm format nm-tiles, I see lots of artefacts, however! Since I was trying to adapt to your unconventional setup quite some time ago, I first had to reconstruct via an explicit layer decomposition how my tiles were composed. It turns out that they are

Code: Select all

out.r = in.g
out.g = in.g
out.b = in.g
out.a = in.r   


such that the rgb color is gray. So note, out.r and out.b are NOT zero.

That should be fine. As long as the values of the red and blue channels are either constant or equal to green, there shouldn't be a problem (as you may have guessed already, what's actually important is for the rgb values to all lie on a line in RGB space, not that r and b are zero.) So what sort of artifacts are you seeing?

Moreover, I am not sure whether you coded things such that the extension of the individual tiles may remain .dds while of course in the .ctx file, TileType "dxt5nm". This would in principle be enough information to tell Celestia, about the special DXT5 format, without the additional work of renaming 2500 tiles

So how does it have to be?

As it's currently implemented, you have the change the file extension of all tiles to dxt5nm. I could modify the code so that if the TileType is dxt5nm, then the virtual texture tile loader will look for both dds and dxt5nm, but I guess that my preference would be to keep things simple: TileType equals file extension.

--Chris

[t00fri]

Moreover, I am not sure whether you coded things such that the extension of the individual tiles may remain .dds while of course in the .ctx file, TileType "dxt5nm". This would in principle be enough information to tell Celestia, about the special DXT5 format, without the additional work of renaming 2500 tiles

So how does it have to be?

As it's currently implemented, you have the change the file extension of all tiles to dxt5nm.
...

--Chris

OK, I couldn't imagine that you want to let the computer know TWICE about the dxt5nm format . That was the cause for the artefacts. So everything works fine now with my dxt5nm tiles.

For people with LINUX or Win32/CYGWIN, here is a trivial script 'ren' that comes handy to rename ~2500 tiles:

------------ ren ----------------

Code: Select all

#! /bin/sh
mv "$1" `basename "$1" .dds`.dxt5nm


--------------------------------

make that 'ren' script executable by typing

chmod a+x ren

and then place it into some directory where executable programs reside, like /bin, /usr/bin, /usr/local/bin or ~bin ...

Then you cd to the respective directory with the level n subdirectories and type

Code: Select all

find . -name "*.dds" -exec ren \{\} \;


that does the job quickly...

Bye Fridger