Long load times for 32k Earth textures

[CaptainValor]

Just curious, is it normal for there to be a significant delay when switching between levels of detail with the high-quality add-on textures in Celestia (such as those obtained from here?

I'm running a Radeon 9500 Pro and 512mb RAM. Celestia reports the texture limit as 2048.

[selden]

CaptainValor,

Can you watch your disk activity light?
Is it blinking like crazy when you change resolutions?

The time delay usually is caused by Celestia loading the texture image files. Naturally, larger files take longer to load. When you're using virtual textures, Celestia often has to load quite a few of the tiles, depending on your viewpoint. Locating all those files in their directories also takes a while.
In addition, if you don't have enough main memory to hold all of the surface texture images, then your system will page them out to its on-disk virtual memory, which can be very slow.

Celestia stresses all components of your system.
This is one reason for upgrading to as fast a disk as you can afford and as much main memory as you can afford.

[Cham]

Yes, Celestia really stresses ALL the computer. On my system, I very often ends with a huge slowdown because of the disk accesses, memory swapping and the *&?%$# video card which is crappy !

I know no other piece of software which put so much pressure on my computer as Celestia.

[CaptainValor]

Is there any way to get Celestia to preload all the textures, such as most PC games do?

[selden]

If you know which textures you'll want to look at, you can add lines to the startup script (start.cel) which look like

preloadtex { object "objectname" }

Where "objectname" is the full path name of the SSC object that should have its textures preloaded.
e.g.
preloadtex { object "Sol/Mars" }

However, I don't think this will cause VirtualTextures to be preloaded. VTs usually are hundreds of MegaBytes, much larger than the main memory of most personal computers. (The full set of BlueMarble VT textures totals about 1GB.)

Many people run Celestia with many Addons, so that if all textures were automatically preloaded, Celestia's total size would be much larger than their system's main memory. This would cause the system to be very slow because it would be paging madly to disk.

Added slightly later:
Of course, another way to preload the textures you need is to run a script which visits the viewpoints that you know you'll be visiting later.

[CaptainValor]

Well, I'll try this but I'd prefer if it would also load the VTs as well. Wouldn't that still be better than having to load them as-needed?

[Harry]

Well, I'll try this but I'd prefer if it would also load the VTs as well. Wouldn't that still be better than having to load them as-needed?

It's simply not feasible on current systems. Take my earth-texture as an example:
Each texture (surface, spec, nightlights) takes at least 340 MB as DDS DXT1 for a 32k VT. The normalmap is much worse (because it's JPG and must be decompressed before use): it would take 2 GB memory uncompressed.

So you need about 3 GB memory for the whole set. The loading time alone is prohibive, and any system with less than 3GB would have to swap out the texture anyway, making it really slow.

VTs make something possible which would otherwise be impossible: displaying very high resolution textures. Their whole point is that you don't load the whole texture into memory. However it would be nice if Celestia could load the textures in the background, and continue working using the lower resolution level until the higher resolution is available.

BTW, you may prefer a preshaded surface texture, like Jestr's Earth Mark II, which doesn't need a normalmap (I believe this specific texture already includes the specmap too, so one more texture you can get rid of). The normalmap not only uses a lot of memory, but it also must be decompressed from JPG to a format that's usable by your graphics card, which is very CPU intensive and may be slow, depending on your system. Unfortunately the much more efficient DDS format produces ugly results when used for the normalmap (no big surprise), I think some very new graphics cards (ATI only?) introduce a similar compression for normalmaps without the ugly artifacts, but this will take some years to be available to the average user.

Harald

[CaptainValor]

Thanks for the advice, I think I'll try that one out as well.

[Seb]

I have quite a fast system, and it still delays when jumping to other planets. Would be nice if Celestia texture loading can be swtich to run on an idle thread, as to start loading textures that it knows it will soon be needing.

eg. When jumping from Earth to Mars, an idle routine starts to load Mars in the background while the foreground thread starts moving the view away from Earth, when the Mars texture is required, it should change the priority of loading as to continue loading as it does currently. This would help to smoothen things while moving around.

Abit like Grant Theft Auto 3, where some very clever predictive disk loading keeps the game running very smoothly while being able to run around a very very large map.

[Kendrix]

The best solution would be asynchronous VT loading.

I'm a video game programmer and we use a lot of asynchronous loading streams because the PS2 has only 32 mo of ram.

So Celestia should launch a separate thread to load VT tiles and as long as a tile isn't loaded, the old one (lower res) stay visible, then Celestia draw the new one when it has finished loading.

With a system like this : no more lags !

You could even do a alpha-blending transition between tiles when there are loaded to avoid the "pop" effect.

[Guest]

*puts in GeForce 6800 Ultra*
Video lag? Loading times? Where?

[guest jo]

deleted

[maxim]

A double or trible RAID stripe set may help greatly. And it's cheaper than a new graphic card.

maxim