Celestia Forums

It's been around 10 months since I last fiddled around with Celestia and it pleases me to say it's made some solid progress.

I just downloaded the 32k blue marble virtual texture, along with a few select level 6, 7, 8, 9 and 10 add-ons, and it looks great. This is a good arrangement as it allows us to optimize things accordingly, i.e. water/oceans are basically featureless; one single seamlessly repeatable, low-res texture would suffice using softlinks to create the appropriate filenames that all point to the same resource. However, while this is storage-efficient it is not memory-efficient; multiple copies will need to be stored in memory unless there is already code in place to avoid this. (If there isn’t yet, I’m sure it’s on the to-do list.)

Another problem exacerbated by virtual textures: massive file sizes. We’re looking at near exponential increases in file sizes with each additional detail level (although as stated previously, optimizations will help moderate this somewhat). This is bad for downloads and bad for storage requirements. There are a number of ways to partly address this issue, like distributing virtual textures in jpeg format, along with an easy-to-use utility to auto-convert them to the desired format (such as DDS). But why use DDS, at least why use that format for level 5+ virtual textures? Wouldn't it make more sense to use jpegs? It's true jpegs will take up more memory as they will need to be decompressed before Celestia can use them, but this is less important with virtual textures and limiting storage requirements has became more important. Something to consider.

There are a bunch of things I’m glad to see were introduced, like the ability to label locations for things on a sphere using latitude/longitude coordinates, and the ability to use “alternate textures” which, as an example, can be used to display non-topographical data.

But there is still much to do. A few examples follow:

1) The ability to specify more texture layers; why even leave the hardcoded “cloud layer” in, other than for legacy compatibility? Generalize it, and remove any theoretical limits on the number of layers that can be used, with various masking/composition options, etc.

2) Extensions to the current lat/long labeling system; instead of just labeling a single long/lat coordinate on the sphere, why not allow us to group multiple long/lat coordinates to specify, label and manipulate regions, paths, etc (i.e. draw political borders, with all sorts of masking options to change the presentation of the polygonal region).

3) A more powerful and flexible animation system…of course! :p

4) A system that allows more dynamic content (stuff that changes with time; not just the relative positions of celestial objects). For instance, the feature mentioned in number 2 above could change with time, i.e. sit back and watch as the political borders change over time. But you should not be restricted to just those sort of things, of course.

So much to do, so little time, eh Chris? I have no doubt you have a mile-long to-do list.

astrum aspicio,

With regard to #5, I presume you know that "page flipping" animations can be done now if you use the Beginning and Ending directives. Unfortunately, nobody's actually created one yet.

Actually I have made one for the Galileo spacecraft - you know with the probe attached, and then not. I've made a model of before the HGA was partially opened too, but I haven't put it up on the net yet. Might do that soon... I don't know of any other models set which does this yet, although there is a big set of ISS models which could have a page flipping effect soon!

astrum aspicio wrote:Another problem exacerbated by virtual textures: massive file sizes. We’re looking at near exponential increases in file sizes with each additional detail level (although as stated previously, optimizations will help moderate this somewhat). This is bad for downloads and bad for storage requirements. There are a number of ways to partly address this issue, like distributing virtual textures in jpeg format, along with an easy-to-use utility to auto-convert them to the desired format (such as DDS). But why use DDS, at least why use that format for level 5+ virtual textures? Wouldn't it make more sense to use jpegs? It's true jpegs will take up more memory as they will need to be decompressed before Celestia can use them, but this is less important with virtual textures and limiting storage requirements has became more important. Something to consider.

DDS textures have a lot of advantages . . . They require 1/8th the texture memory of normal RGB textures, and load a lot faster than JPEGs. On-the-fly conversion to DXT1 format is time consuming! Even with virtual textures, it's very important to keep texture memory usage to a minimum.
You suggestion to distribute a package with JPEG textures together with a utility to convert them to DDS makes some sense, as it could greatly reduce the size of the download. But you'd have to provide a version of the utility that would run on Mac OS X, Windows, and Linux . . . Or, perhaps Celestia could have the converter as part of some built in support for add-on installation.

1) The ability to specify more texture layers; why even leave the hardcoded “cloud layer” in, other than for legacy compatibility? Generalize it, and remove any theoretical limits on the number of layers that can be used, with various masking/composition options, etc.

This is something I've been meaning to get around to for quite some time.

3) A more powerful and flexible animation system…of course! :p

Yes . . . this is coming in the not-to-distant future. It's very important for spacecraft. Frame animation via multiple objects and beginning/ending time can work, but it's a bit clunky for anything more than the simplest animations.

--Chris

astrum aspicio wrote:along with a few select level 6, 7, 8, 9 and 10 add-ons,

May I inquire about where you downloaded these? I don't think i've ever seen them on the forum before.

>>DDS textures have a lot of advantages . . . They require 1/8th the texture memory of normal RGB textures, and load a lot faster than JPEGs. On-the-fly conversion to DXT1 format is time consuming! Even with virtual textures, it's very important to keep texture memory usage to a minimum.<<

I suppose I'm operating on the assumption that many will eventually be using detail textures greater than 32k for a good share of the surface. 32k is quite managable (although using 32k textures for a number of planets could take up a hefty chunk of space), and it's also quite usable and educational. But I do wonder if people will be content to just stop there. I'm not sure this is even worth stressing over however; if the need arises they'll do it. (Do virtual textures require the use of DDS currently?)

Regardless, storage capacity will continue to rise, as will memory, but network capacity will continue to remain an issue and for that there is a far simpler solution, as you go on to mention below.

>>You suggestion to distribute a package with JPEG textures together with a utility to convert them to DDS makes some sense, as it could greatly reduce the size of the download. But you'd have to provide a version of the utility that would run on Mac OS X, Windows, and Linux . . . Or, perhaps Celestia could have the converter as part of some built in support for add-on installation.<<

I read a thread a couple days ago pertaining to addon management; the above would seem like a worthy addition, as would support for gzip wrapped packages. Nicer, neater, and smaller. Where's the downside? :)

Thanks for responding.