My Mars Page
My Mars Page
I've managed to get some space to host some textures so i put up a mars page.
http://www.electronics.dit.ie/dbrady/celestia/index.htm
enjoy
http://www.electronics.dit.ie/dbrady/celestia/index.htm
enjoy
Slan
Seldon,
You seem to be using a larger font size then standard in explorer. I did not take this into account when designing the webpage. The pictures are in an absolute position so dont move in accordance with font size.
This is my first ever webpage though so i guess i have alot to learn.
Also I dont have direct access to modify my page, so it may be awhile before i update it. I apologise for any inconvenience it causes in the meantime.
On another note has anyone tried to download anything yet. I'm curious as to the speeds you may be getting?
You seem to be using a larger font size then standard in explorer. I did not take this into account when designing the webpage. The pictures are in an absolute position so dont move in accordance with font size.
This is my first ever webpage though so i guess i have alot to learn.
Also I dont have direct access to modify my page, so it may be awhile before i update it. I apologise for any inconvenience it causes in the meantime.
On another note has anyone tried to download anything yet. I'm curious as to the speeds you may be getting?
Slan
I have IE's text size set to "Medium"
Don't forget that you need to design Web pages to allow for those with poorer than average eyesight. There are quite a few sites which have forced me to use the "Tools/InternetOptions/General/Accessability/" menu and set all of the "Ignore" options. (Microscopic dark blue lettering on a black background just doesn't work for me.) In other words, relative positioning is a better choice than absolute positioning.
You might want to consider using a table with the text in one column and the pictures in another.
Don't forget that you need to design Web pages to allow for those with poorer than average eyesight. There are quite a few sites which have forced me to use the "Tools/InternetOptions/General/Accessability/" menu and set all of the "Ignore" options. (Microscopic dark blue lettering on a black background just doesn't work for me.) In other words, relative positioning is a better choice than absolute positioning.
You might want to consider using a table with the text in one column and the pictures in another.
Selden
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
DBrady wrote:Seldon,
You seem to be using a larger font size then standard in explorer. I did not take this into account when designing the webpage. The pictures are in an absolute position so dont move in accordance with font size.
This is my first ever webpage though so i guess i have alot to learn.
Also I dont have direct access to modify my page, so it may be awhile before i update it. I apologise for any inconvenience it causes in the meantime.
On another note has anyone tried to download anything yet. I'm curious as to the speeds you may be getting?
DBrady,
yes, I did download your 32k normalmap tiles this afternoon in order to compare with what I got. I am just preparing a detailed comparison.
Unfortunately, I think the quality of your tiles that uses DXT3 encoding is far from satisfactory/optimal. This is probably not your fault, since you used the right steps for sure. On the other hand, to really exploit fully the incredibly detailed information contained in the 16bit/channel 128pix/deg MOLA data, innovative ways beyond DXT3 encoding are urgently required! I am collaborating again actively with Mario Rossi/Space Graphics, to make significant progress in that direction.
In order to increase again the "signal/noise" ratio in this forum (quote=> Christophe in the Textures/Mercury thread;-)), we might e.g. contemplate an email "workshop" among people being both knowledgable and interested in these challenging and important issues...
* Even the most expensive HI-FI set is not worth much without excellent loudspeakers
* Even the most sophisticated Celestia code is not worth much without excellent textures;-)
I can see several points that might be suboptimal in your case:
-- you used the Devil-1.6.5 lib to do the DXT3 encoding, right? Beyond DXT1 this lib was /terribly buggy/.
Meanwhile there is version Devil-1.6.6 with major improvements in DXT encoding. I have recently composed a much improved Devil-1.6.6CVS version that eliminates /many/ leftover bugs! If people are interested, I can make my TextureTools and the new Devil library available at the TextureFoundry. Notably, my Devil-lib (with modified configure.in) compiles out of the box in Windows/Cygwin which I have installed, of course!
-- But clearly, DXT3 has its limitations at the level we are talking about. What I did with great results is to use tiles in PNG format of 4k size. My high-end graphics card can deal with this and the quality is an order of magnitude better than DXT3! But obviously, we need to find a scheme that works for more people than just me;-).
Bye Fridger
PS: Also with my system, your nice WEB page was displayed with significant parts of the text covered by your plates...
I agree totally. It is however an order of magnitude better then any available normal maps at the moment.
My method for making the tiles did involve devIL - but not for the conversion to dxt3 - It was simply to convert and name change each ppm tile to tga for subsequent conversion to dxt3 by nvdxt.
I wrote a wee program to output a rather large .bat script for this.
Example file generated...
pamdice -outstem=tx -width=2048 -height=2048 mola32k.ppm
FileConverter tx_00_00.ppm tx_0_0.tga
FileConverter tx_00_01.ppm tx_1_0.tga
FileConverter tx_00_02.ppm tx_2_0.tga
FileConverter tx_00_03.ppm tx_3_0.tga
FileConverter tx_00_04.ppm tx_4_0.tga
FileConverter tx_00_05.ppm tx_5_0.tga
FileConverter tx_00_06.ppm tx_6_0.tga
. .
. .
. .
FileConverter tx_07_10.ppm tx_10_7.tga
FileConverter tx_07_11.ppm tx_11_7.tga
FileConverter tx_07_12.ppm tx_12_7.tga
FileConverter tx_07_13.ppm tx_13_7.tga
FileConverter tx_07_14.ppm tx_14_7.tga
FileConverter tx_07_15.ppm tx_15_7.tga
nvdxt -file *.tga -norm -dxt3
Fileconverter is of course made from the devIL library.
I believe this leads to the best normal map possible for dxt3 format. Would you disagree?
I myself had a brief experiment with png (and i mean brief).
below is the only pic i could find on my hard drive of it...
As you can see it has a horrible glazed look which is not
evident in u888 which is |best| quality...
I abandoned png after this, perhaps a bit hastly, and went with u888 so i could be secure in the knowledge that i could not possibly have a better texture. This was however when i thought i would never be able to release any of my textures so size and speed was not that important - at least not to me.
Now perhaps it is a different story and i look forward to seeing your detailed comparision.
The reason i choose dxt3 as a release format was to satisfy the 'noise' who may have heard the many references to dxt3 format as the best format for normal maps. I had hoped that maybe they could be content in the knowledge that they had the best texture possible, for a while at least.
I think now you may have wrecked the illusion : ).
It is also fairly fast of course.
P.s i think i'll have to redesign my web page so.
My method for making the tiles did involve devIL - but not for the conversion to dxt3 - It was simply to convert and name change each ppm tile to tga for subsequent conversion to dxt3 by nvdxt.
I wrote a wee program to output a rather large .bat script for this.
Example file generated...
pamdice -outstem=tx -width=2048 -height=2048 mola32k.ppm
FileConverter tx_00_00.ppm tx_0_0.tga
FileConverter tx_00_01.ppm tx_1_0.tga
FileConverter tx_00_02.ppm tx_2_0.tga
FileConverter tx_00_03.ppm tx_3_0.tga
FileConverter tx_00_04.ppm tx_4_0.tga
FileConverter tx_00_05.ppm tx_5_0.tga
FileConverter tx_00_06.ppm tx_6_0.tga
. .
. .
. .
FileConverter tx_07_10.ppm tx_10_7.tga
FileConverter tx_07_11.ppm tx_11_7.tga
FileConverter tx_07_12.ppm tx_12_7.tga
FileConverter tx_07_13.ppm tx_13_7.tga
FileConverter tx_07_14.ppm tx_14_7.tga
FileConverter tx_07_15.ppm tx_15_7.tga
nvdxt -file *.tga -norm -dxt3
Fileconverter is of course made from the devIL library.
I believe this leads to the best normal map possible for dxt3 format. Would you disagree?
I myself had a brief experiment with png (and i mean brief).
below is the only pic i could find on my hard drive of it...
As you can see it has a horrible glazed look which is not
evident in u888 which is |best| quality...
I abandoned png after this, perhaps a bit hastly, and went with u888 so i could be secure in the knowledge that i could not possibly have a better texture. This was however when i thought i would never be able to release any of my textures so size and speed was not that important - at least not to me.
Now perhaps it is a different story and i look forward to seeing your detailed comparision.
The reason i choose dxt3 as a release format was to satisfy the 'noise' who may have heard the many references to dxt3 format as the best format for normal maps. I had hoped that maybe they could be content in the knowledge that they had the best texture possible, for a while at least.
I think now you may have wrecked the illusion : ).
It is also fairly fast of course.
P.s i think i'll have to redesign my web page so.
Slan
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
DBrady wrote:I agree totally. It is however an order of magnitude better then any available normal maps at the moment.
My method for making the tiles did involve devIL - but not for the conversion to dxt3 - It was simply to convert and name change each ppm tile to tga for subsequent conversion to dxt3 by nvdxt.
I wrote a wee program to output a rather large .bat script for this.
Example file generated...
pamdice -outstem=tx -width=2048 -height=2048 mola32k.ppm
FileConverter tx_00_00.ppm tx_0_0.tga
FileConverter tx_00_01.ppm tx_1_0.tga
FileConverter tx_00_02.ppm tx_2_0.tga
FileConverter tx_00_03.ppm tx_3_0.tga
FileConverter tx_00_04.ppm tx_4_0.tga
FileConverter tx_00_05.ppm tx_5_0.tga
FileConverter tx_00_06.ppm tx_6_0.tga
. .
. .
. .
FileConverter tx_07_10.ppm tx_10_7.tga
FileConverter tx_07_11.ppm tx_11_7.tga
FileConverter tx_07_12.ppm tx_12_7.tga
FileConverter tx_07_13.ppm tx_13_7.tga
FileConverter tx_07_14.ppm tx_14_7.tga
FileConverter tx_07_15.ppm tx_15_7.tga
nvdxt -file *.tga -norm -dxt3
Fileconverter is of course made from the devIL library.
I believe this leads to the best normal map possible for dxt3 format. Would you disagree?
I myself had a brief experiment with png (and i mean brief).
below is the only pic i could find on my hard drive of it...
As you can see it has a horrible glazed look which is not
evident in u888 which is |best| quality...
I abandoned png after this, perhaps a bit hastly, and went with u888 so i could be secure in the knowledge that i could not possibly have a better texture. This was however when i thought i would never be able to release any of my textures so size and speed was not that important - at least not to me.
Now perhaps it is a different story and i look forward to seeing your detailed comparision.
The reason i choose dxt3 as a release format was to satisfy the 'noise' who may have heard the many references to dxt3 format as the best format for normal maps. I had hoped that maybe they could be content in the knowledge that they had the best texture possible, for a while at least.
I think now you may have wrecked the illusion : ).
It is also fairly fast of course.
P.s i think i'll have to redesign my web page so.
DBrady,
also I agree entirely with what you write.
I am happy to read that you used nvdxt for DXT3 conversion, because Devil-1.6.5 was simply not able to do it adequately...
I agreed from the beginning that you did the best job that could be done with DXT3. Now I even know that you chose a good encoder.
You rose a very interesting point: png vs. u888. These are both /lossless/ formats and thus it should not happen that one format has artifacts which the other one does not show!? On the other hand I vaguely remember that png encoding was also said to be buggy in various bug reports.
In any case the logical next step is to compare carefully u888 vs png. PNG is even somewhat slow on my card. Unfortunately, devil does not yet do u888, so the whole thing takes time...I made some early u888 studies quite some time ago aned gave it up for other reasons. I definitely shall get back to it.
Indeed, I also noticed some unlpeasant glacing color
color effects in my PNG displays. Your u888 comparison looks clearly way better!
An interesting new point of view for sure.
Bye Fridger
With the knowledge that you also had the 'glazed' effect with png
I'm quite convinced that dxt3 is probably the only viable
distribution format, as a full u888 distribution would be simply colossal.
Upto to 32k at dxt3 is 2.65GB while, if you're really trying to get the very best out of the mola data, the 64k folder is 8GB.
Even just up to 32k zipped would probably be around 1GB(Guesstimate).
Perhaps an alternate solution would be just to release a few u888 tiles along with my dxt3 map maybe around olympus mons, valles mariner and other well known spots and exploit the fact that the dxt encoding is irrelevant in chris's VT code.
Also,
How did you fill in the 2 degree's missing from the polar region. In mine it is a purely flat band added to the top and bottom of the mola data.
Just curious if you filled it in with some lesser resolution data from somewhere.
I'm quite convinced that dxt3 is probably the only viable
distribution format, as a full u888 distribution would be simply colossal.
Upto to 32k at dxt3 is 2.65GB while, if you're really trying to get the very best out of the mola data, the 64k folder is 8GB.
Even just up to 32k zipped would probably be around 1GB(Guesstimate).
Perhaps an alternate solution would be just to release a few u888 tiles along with my dxt3 map maybe around olympus mons, valles mariner and other well known spots and exploit the fact that the dxt encoding is irrelevant in chris's VT code.
Also,
How did you fill in the 2 degree's missing from the polar region. In mine it is a purely flat band added to the top and bottom of the mola data.
Just curious if you filled it in with some lesser resolution data from somewhere.
Slan
DBrady wrote:On another note has anyone tried to download anything yet. I'm curious as to the speeds you may be getting?
I'm getting about 150KB/sec to my system at home at 7PM EST (midnight GMT). That's quite respectable.
I suspect the font size difference may be caused by the DPI setting and the screen resolution. I'm running at 1600x1200 on a 21" screen with 120DPI both at work and at home. The DPI setting is configured on the menu Display Properties/Settings/Advanced/General. The comment there says "125% normal size (120DPI)"
The text is not overlayed by the pictures if I set IE's text size to "smaller".
Selden
-
- Developer
- Posts: 944
- Joined: 18.07.2002
- With us: 22 years 3 months
- Location: Lyon (France)
DBrady wrote:Seldon,
You seem to be using a larger font size then standard in explorer. I did not take this into account when designing the webpage. The pictures are in an absolute position so dont move in accordance with font size.
You should use
Code: Select all
<div style='float:right'>...</div>
instead of
Code: Select all
<div style='position:fixed;left:...;top:...'>...</div>
to prevent this from hapening and keep your site width adjustable.
Christophe
-
- Posts: 1034
- Joined: 16.12.2002
- With us: 21 years 10 months
- Location: People's Republic Of Cork, Ireland
DBrady,
I was in an internet cafe in town yesterday, and along with about a doen other hi-res textures, I downloaded everything off your page in 45 mins. It's FANTASTIC!
The only problem I have is bad jerkyness when going from one level to another, but this can easily be solved with more RAM. (Roll on christmas... )
I was in an internet cafe in town yesterday, and along with about a doen other hi-res textures, I downloaded everything off your page in 45 mins. It's FANTASTIC!
The only problem I have is bad jerkyness when going from one level to another, but this can easily be solved with more RAM. (Roll on christmas... )
Thanks jack, I find it goes particularly well with some of your models : ).
On an more down beat note i've now become unhappy with my textures - even with my uncompressed u888 64k mars normal map!
For today i downloaded one of the MOC tiles from
http://www.msss.com/mgcwg/mgm/
just to take a look.
t00fri,
I dont know if this is one of the things you may have been working on but if it isn't i think you should probably change direction.
Below is a pic of Valles Mariner made with my aforementioned 64k NM map.
Not bad at all is it - until you see the MOC data...
This data is 256 pixels per degree - twice that of mola! The above image has gone through some processing in photoshop but i am quite happy with the colour i settled on.
Which brings me to another point. The picture also only contains 256 colours! If a full VT map was produced with this data it would probably be a candidate for the dds -p8 (paletted 8-bit) format that Jim is always asking for. I imagine it would probably be super smooth using this format.
On an more down beat note i've now become unhappy with my textures - even with my uncompressed u888 64k mars normal map!
For today i downloaded one of the MOC tiles from
http://www.msss.com/mgcwg/mgm/
just to take a look.
t00fri,
I dont know if this is one of the things you may have been working on but if it isn't i think you should probably change direction.
Below is a pic of Valles Mariner made with my aforementioned 64k NM map.
Not bad at all is it - until you see the MOC data...
This data is 256 pixels per degree - twice that of mola! The above image has gone through some processing in photoshop but i am quite happy with the colour i settled on.
Which brings me to another point. The picture also only contains 256 colours! If a full VT map was produced with this data it would probably be a candidate for the dds -p8 (paletted 8-bit) format that Jim is always asking for. I imagine it would probably be super smooth using this format.
Slan
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
DBrady wrote:Thanks jack, I find it goes particularly well with some of your models : ).
On an more down beat note i've now become unhappy with my textures - even with my uncompressed u888 64k mars normal map!
For today i downloaded one of the MOC tiles from
http://www.msss.com/mgcwg/mgm/
just to take a look.
t00fri,
I dont know if this is one of the things you may have been working on but if it isn't i think you should probably change direction.
Below is a pic of Valles Mariner made with my aforementioned 64k NM map.
This data is 256 pixels per degree - twice that of mola! The above image has gone through some processing in photoshop but i am quite happy with the colour i settled on.
Which brings me to another point. The picture also only contains 256 colours! If a full VT map was produced with this data it would probably be a candidate for the dds -p8 (paletted 8-bit) format that Jim is always asking for. I imagine it would probably be super smooth using this format.
DBrady,
just arrived at home from a conference trip...( 1 am over here).
Tomorrow I expect a quiet day (for a change) and certainly will look into the MOC data. They look according to my taste;-) Notably also the noise-freedom!
Bye Fridger
Is the normal map inverted again though? Maybe I'm experiencing some sort of optical illusion but compared with the old NM screencap the craters and the valley look raised above the surface. Both screencaps are illuminated from the right-hand side, yes?
Am I going mad? Am I the only one seeing it like this?
Am I going mad? Am I the only one seeing it like this?