Testing Chris' new, compressed normalmaps (part 2)

[t00fri]

EDIT: .ogg ==> .avi (for Windows fans )
14MB ==> 10.9 MB

[rra]

Fridger,

could you please tell me/us what codec you used for this AVI ,
my media player (or windows itself) doesn't have this codec onboard ?


Ren?©

[Christophe]

Nice. Oddly those ochre tones and golden reflections remind me of Klimt.

[Christophe]

Ren?©, the video codec is theora.

[t00fri]

Fridger,

could you please tell me/us what codec you used for this AVI ,
my media player (or windows itself) doesn't have this codec onboard ?


Ren?©

Yeah, I just realized it, too. I made the movie under Linux. Since AVI includes a number of compressed formats, unfortunately the Windows avi does not seem to be part of the show...

My Linux movie displayers (kaffeine, xine, mplayer) all work very well with mars.avi. I use a huge directory full of codecs (/usr/lib/win32) but can't tell you which one of these is applied.

Bye Fridger

[t00fri]

Ren?©, the video codec is theora.

Indeed the author of that Linux movie capture feature for Celestia

Yes, of course it's the libtheora that is used under Linux.

Bye Fridger

[Christophe]

You can download the ogg/theora directshow plugins here.

[rra]

I have it running , but I had to use the VLC player ,
for some reason the directshow plugin didn't work ,
or maybe I should reboot the system (windows ofcourse) .
But then lazy as I am ...

Ren?©


P.S. the AVI is a bit spooky but has nice "normap" mapping

[t00fri]

For some reason the directshow plugins also did not work for me with the Media Player 10.

Bye Fridger

[t00fri]

For me the VLC player from Christophe's URL does a pretty good job, in fact under Windows. Yes that mars.avi movie is MEANT to be a bit spooky

Actually VLC seems to be a neat slim and well working little player, e.g. also for the mp4 videos taken with my mobile phone camera etc.

Bye Fridger

[Christophe]

Actually VLC seems to be a neat slim and well working little player, e.g. also for the mp4 videos taken with my mobile phone camera etc.

Of course VLC is a neat video player! It's developped at ?‰cole Centrale Paris ;-)

[t00fri]

Actually VLC seems to be a neat slim and well working little player, e.g. also for the mp4 videos taken with my mobile phone camera etc.

Of course VLC is a neat video player! It's developped at ?‰cole Centrale Paris

Aha! Even better....

So I think this may be taken as an encouragement for Windows-Celestians to download this nice little player. Then they will also be able to view the video creations from the Linux-Celestians without hassle!

Bye Fridger

[neo albireo]

Don't know if this is the right thread to post as there are quite a few threads with nmtools-discussions.

Fridger,

I tried out your nmtools after reading the informations that are scattered on different threads. I can proudly say that even though I only have used the Terminal (Mac OS X) the first time last week (to download the Celestia source code from CVS) I basically managed to run everything smooth and quick as you promised and learned a lot about the Terminal. I ran the last step 5 times with a different parameter in order to get five folders (level0, level1... level5). Then I used the following earth-normal.ctx to lead to the textures:

Code: Select all

VirtualTexture
{
        ImageDirectory "earth-normal"
        BaseSplit 0
        TileSize 512
        TileType "ppm"
}

When viewing Earth in Celestia, the tools work and don't work at the same time
When zooming in, it looks good. However, I'm not sure if I did it correct as the difference to my previously used 4-level normal map is not so big.
So here comes the first question: After running resc2pow2 on srtm_ramp2.world.86400x43200.bin I runned halfsize on it. I thought I have to use all the tools in a row but then discovered that you don't need to use nms AND nmstiles but only one of them. Therefore I'm not sure if I really needed to reduce the size by half or if I should just have runned mnstiles directly after resc2pow2. A test to see if I did it right would be to tell me the size of tx_0_4.ppm in level5. Mine is 388 KB.

Now comes the strange part:
The NormalMaps work only on ca. 1/4 of the surface of Earth and on the rest even the surface maps disappear. I find some strange yin/yang-illumination-behaviour starting from the poles:



Is this a limitation of my graphic card (RadeonX1600) or did I do something wrong?
Anyway, if you'll publish your step-by-step guide rather soon, I don't need an immediate answer on this post and I'll wait and try again. I justed wanted to show that there are actually people out there trying their best to understand how your tools are used...

[Fightspit]

Code: Select all

VirtualTexture
{
        ImageDirectory "earth-normal"
        BaseSplit 0
        TileSize 512
        TileType "ppm"
}

Celestia doesn't support ppm pictures, you must convert them in jpg or png or dds (dx3 or 5).

Don't forget that png or dds in dxt5 is better quality than jpg or dds in dxt3 in general.

[neo albireo]

Code: Select all

VirtualTexture
{
        ImageDirectory "earth-normal"
        BaseSplit 0
        TileSize 512
        TileType "ppm"
}

Celestia doesn't support ppm pictures, you must convert them in jpg or png or dds (dx3 or 5).

Don't forget that png or dds in dxt5 is better quality than jpg or dds in dxt3 in general.

Thanks a lot!
Then what was the normalmap-effect that I saw?
Looks like I have to clear out my hires-folder before I mess around...

[t00fri]

Hi Neo,

congratulations!

Actually by tomorrow, my tutorial in CelestialMatters will have been further completed with step-by-step working examples etc.

Yes, as Fightspit mentioned. I decided not to vaste my time on coding converter modules for the output format, since almost any graphics program can do this easily.

For Windows users NVIDIA's 'nvdxt' command-line tools are best to convert the .ppm format tiles directly into /compressed/ DXT5nm normalmap VT's. The nvdxt tools can work on whole directories. So it's "stupid" easy

For other OS, I recommend the 'nconvert' command-line tool from the XnView distribution. It exists both for Linux and MAC-OSX. It also supports STDIN/STDOT hence one can just pipe it after nmstiles and directly gets .png output for example.

Unfortunately nconvert does not support DXT5nm format. I am planning to code an output module that directly produces DXT5nm tiles. Yet I still want to convince myself by further testing whether the quality compromise is indeed insignificant. The best quality is certainly .png.

Bye Fridger

[neo albireo]

The best quality is certainly .png.

Thanks a lot!
I'm converting right now with Photoshop to .png and I'm looking forwards to the result.
If PNG is best for quality, what is best for speed (loading and performance)? Or does it not make any difference?

And one general question.. I read in august or september (was traveling since then, so I don't know what happened in the relevant threads) that Chris followed your suggestion and implemented a feature that allows to reduce the size of textures (or the number of textures) towards the poles. Sorry if I don't use the right words, but I understand what it's generally about. So your nmtools do already make use of that and don't produce Gigabytes of data around the poles, right? Now what about the other maps (surface, spec, night)? Will there be similar tools available to produce the adequate for these maps? My computer is able to use a lot of data, but the loading time of the texture files is too big (probably because it's a laptop). So I'm very interested in having textures that are optimized in every aspect. I read in the post of Fightspit on Celestial Matters that he used the tool of RVS to do something (if not exactly) like that. I then found the relevant post in this forum, but it's a tool for Windows

Your work is very appreciated and I'm looking forward to the step-by-step guide! I especially like that you pay a lot of attention on cross-platform compatibility!

[t00fri]

The best quality is certainly .png.

Thanks a lot!
I'm converting right now with Photoshop to .png and I'm looking forwards to the result.
If PNG is best for quality, what is best for speed (loading and performance)? Or does it not make any difference?

Photoshop is of course OK, but e.g. the command-line tool nconvert (XnView distribution) is much more effective for .png conversion!

And one general question.. I read in august or september (was traveling since then, so I don't know what happened in the relevant threads) that Chris followed your suggestion and implemented a feature that allows to reduce the size of textures (or the number of textures) towards the poles. Sorry if I don't use the right words, but I understand what it's generally about. So your nmtools do already make use of that and don't produce Gigabytes of data around the poles, right?

As far as I know Chris did not automatically reduce the tile resolution near the poles. In any case an external high-quality reduction is far superior. The nmtools do that for normalmaps (without loss of quality).

Now what about the other maps (surface, spec, night)? Will there be similar tools available to produce the adequate for these maps?

++++++++++++++++++++++++++++++++++
Quite some time ago, I wrote a neat script that does that for any kind of /existing/ VT tiles! That script will also be discussed and published in CelestialMatters VERY soon...
++++++++++++++++++++++++++++++++++

My computer is able to use a lot of data, but the loading time of the texture files is too big (probably because it's a laptop). So I'm very interested in having textures that are optimized in every aspect. I read in the post of Fightspit on Celestial Matters that he used the tool of RVS to do something (if not exactly) like that. I then found the relevant post in this forum, but it's a tool for Windows

I have also coded (but not yet published) similar cross-platform tools for fast generation of other types of textures. It's a very simple extension of the nmtools.

Since RVS (Robert Skuridin) was impatient and sent around his FORTRAN-based Windows programs privately without my consensus and before publication of our joint official distribution (that I coded in C++ for cross-platform use), I have decided to stop collaborating/communicating with him...

Bye Fridger

[neo albireo]

Photoshop is of course OK, but e.g. the command-line tool nconvert (XnView distribution) is much more effective for .png conversion!

That's definitely true: It took my MacBook Pro 3 hours just for level5. But now I can say:

Yippie, it works!!! Fantastic! As I exaggerated the effect by the suggested factor, it is more clear than the texture I previously used and gives a fantastic appearance to mountain ranges.

But before I try my luck with level0-level4, I want to know if I did right when reducing the size of the file by half after resc2pow2 (I think now that I should only have used two tools: resc2pow2 and nmstiles). Maybe the textures I have now (that are already very impressing) are still not the full resolution. I will find out when the tutorial is continued...

As far as I know Chris did not automatically reduce the tile resolution near the poles. In any case an external high-quality reduction is far superior. The nmtools do that for normalmaps (without loss of quality).

Yes, that's what I meant. Chris just implemented something that allows that enables the use of reduced maps, not a reduction inside the program.

++++++++++++++++++++++++++++++++++
Quite some time ago, I wrote a neat script that does that for any kind of /existing/ VT tiles! That script will also be discussed and published in CelestialMatters VERY soon...
++++++++++++++++++++++++++++++++++

GREAT!!!

[t00fri]

Hi Neo and friends,

here is a little help before my tutorial is ready in the next 1-2 days:

The following resc2pow2 command assumes that you have previously unpacked the 84k heightmap. In principle it is NOT necessary though. gzip works also with STDIN/STDOUT and can be piped just before resc2pow2! This saves lots of harddisk storage in case people are short of it...


resc2pow2 86400 < srtm_ramp2.world.86400x43200.bin > srtm_ramp2.world.64k.bin

+++++++++++++++++++++++++++
NOTE: this is correct ONLY for big-endian MAC's. For little-endian machines like PC's (Win32, Linux, Intel-MAC) you need to replace the resc2pow2 command by

resc2pow2 86400 1 < srtm_ramp2.world.86400x43200.bin > srtm_ramp2.world.64k.bin

The additional byteswap =1 option accounts for the fact that the big-endian storage mode of the 16bit integer height values differs from the storage mode of the used machine!

All the following commands are the same for all machines!
++++++++++++++++++++++++++++

Move srtm_ramp2.world.64k.bin to level5 dir AFTER executing this command:

halfsize 65536 < srtm_ramp2.world.64k.bin > srtm_ramp2.world.32k.bin

Move srtm_ramp2.world.32k.bin to level4 dir AFTER executing this command:

halfsize 32768 < srtm_ramp2.world.32k.bin > srtm_ramp2.world.16k.bin

...

and so on.

Then you work with 'nmstiles' on each of the big powerof2 sized heightmaps in each levelx directory.

Of course these steps can be easily arranges into a simple batch script, whence you can drink a beer while the script executes

Bye Fridger