On Sun, May 31, 2009 at 4:47 AM, Fridger Schrempp <firstname.lastname@example.org>
Now that most Devs will have definitely switched to VC++ 2008 Express, could
Chris Laurel wrote:
> I uploaded a Win32 binary package of 1.6.0 RC 3:
> The main change is that this version is built with MSVC++ 2008 instead
> of 2005. I was having trouble getting the right DLLs when building with
> 2005. My install of VC++ 2005 appears to be damaged, and the Express
> Edition of the compiler doesn't appear to be supported. It seemed easy
> just to move ahead to using 2008, which we'd want to do eventually
> anyway (among other things, the Eigen library supports vectorization
> instructions with VC++ 2008 but not 2005.) I took care to rebuild all of
> the libraries with VC++ 2008: zlib, pnglib, libjpeg, lua, and SPICE (the
> gettext libraries we're built with a pre-2005 compiler, so shouldn't
> introduce any runtime dependencies.) In order to build Celestia with VC
> 2008, I had to make a modification to celestia.rc to remove the
> dependency on afxres.h (an MFC file), which is long overdue.
you please make the respective libs available in order that we all use the
Yes, I will definitely do this. In fact, I suggest that we should commit the libraries to SVN and save people the trouble of having to download them.
Moreover, I infer that you are actually now working with the *commercial*
release of VC++ 2008 rather than the Express version? While having the
commercial version available from my lab, I have switched to VC++ 2008
*Express*, since you made supporting statements some time ago about giving
preference to a compiler that is available generally ...
I am still using VC++ 2008 Express Edition, not the commercial version of the compiler.
I found that there are significant incompatibilities between the two releases.
E.g. The commercial version cooperates with C# in solution files, while the
Express version doesn't. This makes project files potentially incompatible
etc. Ignacio Castano's new NV-tools 2.0.x are examples thereof.
I encounter no problems with the reference to afxres.h in celestia.rc. I have
simply added an Include/mfc dir in the MS SDK containing afxres.h. Of course
the path has to be added in the VC++ IDE.
Yes, I know about this workaround. However, while the MFC headers are present in the SDK I'm using with VC++ 2005, the are not in the SDK I'm using for VC++ 2008. In any case, Celestia doesn't use MFC, so there's no need for this dependency. It's also caused unnecessary headaches for people who have tried building Celestia--search the forums for afxres.h. Best to get rid of it and replace it with this:
#define IDC_STATIC -1
What are we supposed to do with this "anonymous" link?
Umm... nothing? It was a quick experiment, nothing more. But, since you asked...
Who did the texture with which modifications relative to the original BMNG?
The blue of the sea looks different, for example...
The image was taken directly from the Blue Marble site. I personally find the blues in the texture to be unrealistically vivid.
What DXT compression tools
I used the latest version NVTextureTools2. I found some artifacts when using the CUDA version of the DXT3 compressor, so I switched to the non-CUDA version.
As can be checked with the 'nvimgdiff' tool, the most recent
(squish-based) algorithms have significantly fewer losses than the earlier NV
compressors..Moreover cartrite's SWBD based watermask is a completely
different class compared to the spec mask in your earth.dds.
I did use cartrite's SWBD based mask.
Also was DXT5 used rather than DXT3? For RGBA textures DXT5 gives a
significantly better quality in the compression of the *alpha channel* at
equal file size than DXT3.
It is not the case that DXT5 is always better than DXT3. I used DXT3, and the choice was deliberate. DXT5 is generally better for images with smooth variations in the alpha channel, while DXT3 can be a better option when the opacity changes quickly. DXT3 seems like the natural choice for something like a specular mask, where the transitions from land to water areas are very sharp.
For exmaple, a 2k RGBA test earth (RGB + specular) gives of course the same
root mean squared error for the RGB base texture part, but for the alpha
channel with DXT5: => 1.24 compared to => 1.76 with DXT3. The peak
signal-to-noise ratio for the alpha channel with DXT5 is 46.25 db compared to
only 43.6 db with DXT3. This is getting quite relevant once an improved
watermask with many details (rivers etc) is employed as the spec texture.
Interesting. I'm surprised to see DXT5 outperform DXT3 here, and I suspect it may have something to do with using a low resolution texture where downsampling gives more intermediate values.
And so on...
I tire of your persistent subtly insulting tone.
> ...but I think we should take more care in tuning and optimizing a new
> Earth texture. It's a task that I think is best deferred until 1.6.1.
Perhaps worth adding:
Already quite some time ago, I have composed, a modified set of Mie parameters
that seems to improve the appearance of Earth from space quite a bit,
according to the people who are using it. Of course, the present
implementation is still far from photorealistic...
Rayleigh [ 0.0008121 0.0020775 0.00375 ]
Absorption [ 0.00057 0.0004 0.0 ]
compared to SVN:
Rayleigh [ 0.001 0.0025 0.006 ]
However, I should say that the tuning depends to some extent on my own
textures... The overall result looks like this at relatively low resolution,
about equivalent to a 4k texture...
I do like the appearance of your Earth better than one in the current version of Celestia. What about switching to this new set of Mie parameters and Earth texture simultaneously in 1.6.1?