Celestia Forums

Since I recieved a handful of requests, I'm converting my 'Home Planet'
16k Earth textures I originally made for the Orbiter community to
Celestia .dds format.

While it could readily use any normal/cloud/light map, it makes a lot of
sense to package the specular map with the surface map because of how I
treated arctic and antarctic sea ice. It seems the ideal here is to
combine the two using the DXT1A format.

I'm aware of tools that would do this up to 8k, but for 16k I'm only aware
of nonmipmapped conversion using the bmp2dxt utility, which only does
DXT1C (not DXT1A, with alpha).

1) Does anyone have a suggestion re: handling alpha at 16k? Right now
I'm delving through the documentation of NVIDIAs binary package, but
thought somebody might have confronted this issue before.

2) As a second question, why is DXT3 recommended over DXT1c in [url]
http://www.celestiaproject.net/forum/viewtopic.php?t=2019[/url] for normal maps?
It would seem that normal maps have little use for alpha.

I was planning on using NVIDIA's 8-bit->normal Photoshop plug-in in
IrfanView, crossing my fingers that this will work on a 512MB system at
16k x 8k.

Actually, for the best result, dxt should not be used at all for normal maps, it produces ugly artefacts. Png is the best option. Of course this is a lot easier when using virtual textures instead of a single 16k texture... If you do want to use dxt, dxt3 has less of the blocky artefacts than dxt1c.

dxt1 has what, 17-18 effective/uncompressed bits per pixel, and if 6 are
taken up by the 'z' constituent of the surface normal, and effective range of x and y constituents is only 3-4 bits for each, that means a dxt1 normal map would look worse than a 6 bit bumpmap.

I installed Cygwin in any case so that I could try to compile the GIMP
normal map converter - looks like I'll just do .png VTs for everything (including the Moon) after all.

sombrehombre wrote:dxt1 has what, 17-18 effective/uncompressed bits per pixel, and if 6 are
taken up by the 'z' constituent of the surface normal, and effective range of x and y constituents is only 3-4 bits for each, that means a dxt1 normal map would look worse than a 6 bit bumpmap.

I installed Cygwin in any case so that I could try to compile the GIMP
normal map converter - looks like I'll just do .png VTs for everything (including the Moon) after all.

Well, a resolution as high as 16k starts being challenging;-)

DXT1A is ridiculous for that case. Forget it. DXT3 is just OK, but in principle you should start from 16bit for the RAW graychannel bumpmap and convert it with Chris' tool nm16 to a normal map with 8bit/RGB channel. Here, the trick is that the truncation to 8bit/channel is done only at the end, with all manipulations done at full 16bit/channel accuracy!

If you got a normal map already and just want to encode it into DXT3, DXT5,...then my tools are much superior to NVIDIA stuff, since they are based on the latest DEVIL-1.6.6 (patched) libs and compile perfectly under Linux, Cygwin and Windows (native). And they are "lightening fast" as compared to the nvidia tools. And they work for >8k files!

But it is not really clear to me what exactly you want to do...

Bye Fridger

I just wanted to keep my specular map and surface map together as
a logical unit, since they differ markedly from the other various flavors
of Blue Marble in how they handle sea-ice - and at 16k, they appear
a good deal more accurate than most spec maps on shorelines and
deep ocean islands.

It seemed that the logical way to do this, if I were to use 16k dds, would
be to use the 1 bit alpha flag in dxt1A - I know how to do this with
Microsoft's dxtex (in fact, since this POS converter is the one used by
Orbiter's pltex texture tool, my maps are tuned to avoid the stripe
artifacts dxtex produces do to its lousy dithering method), but I think
dxtex, like the NVIDIA tools, is hardcoded to only handle textures up
to 8k.

I believe I did use your bmp2dds tool for unmipmapped .dds on my 16k
Moon, but my understanding is that it only does dxt1c - which would mean
a separate spec map. The two-color .png is tiny, but I'm wary that it
wouldn't be particularly memory efficient at runtime in Celestia. Given I
already have significant slowdowns with .pngs larger than 2k, and the
environs of the Earth are memory intensive with all the textures required,
I just wanted a more runtime efficient way to handle this.

But, there is the consideration that the only advantage a 16k set of VT
textures would have for most users is a smaller total installation, and
possibly nicer colors, if they like mine - they still have to learn how to set
up VTs. It might make sense for a CD Celestia distribution, but that's
about it.

BTW, I've got everything up and running for a VT version, when I update
my Moon.

DXT1a will not work for specular maps. The DXT1a works is that the image gets divided into 4x4 blocks, with each block containing two 16-bit colors and 2 bits for each of the 16 pixels in the block. The two bits mean that each pixel in the block can have one of four colors:

00 - color1
01 - average of color1 and color2
10 - color2
11 - transparent

The problem is that you can't specify the color of the transparent bit--it's always black! This isn't a problem if the transparent pixels are actually invisible, but they're not in a specular map.

--Chris