It is currently Wed, 13-11-19, 16:51 GMT

All times are UTC




Post new topic Reply to topic  [ 196 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 14  Next
Author Message
 Post subject:
PostPosted: Sun, 23-09-07, 14:23 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
BTW, the color of those BMNG raw maps are free of the atmosphere effect, right? Any way to readjust them meanwhile Celestia is unable to simulate the effect of the atmosphere?


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 15:04 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
ElChristou wrote:
BTW, the color of those BMNG raw maps are free of the atmosphere effect, right? Any way to readjust them meanwhile Celestia is unable to simulate the effect of the atmosphere?


That is right Christophe. This is also the reason why the BMNG RGB maps appear too dark to some.
What can presently be done is to add some /effective/ atmospheric color effects via a coloration of the RGBA cloud layer. The Mie theory of atmospheres that is now implemented does already provide quite a number of non-trivial atmospheric scattering effects. But so far it does NOT allow to illuminate the surface with the sky color. See my respective thread in the Developer Talk forum@shatters.net

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 15:22 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
ElChristou wrote:
BTW, the color of those BMNG raw maps are free of the atmosphere effect, right? Any way to readjust them meanwhile Celestia is unable to simulate the effect of the atmosphere?


That is right Christophe. This is also the reason why the BMNG RGB maps appear too dark to some.
What can presently be done is to add some /effective/ atmospheric color effects via a coloration of the RGBA cloud layer. The Mie theory of atmospheres that is now implemented does already provide quite a number of non-trivial atmospheric scattering effects. But so far it does NOT allow to illuminate the surface with the sky color. See my respective thread in the Developer Talk forum@shatters.net

Cheers,
Fridger


Yep, but seems it's not tomorrow the planet rendering code will be rebuilt...

Now the cloud map trick seems odd to me... I mean not sure that what will be good to adjust the oceans color will be ok for lands (where we have green/beige tone)... :?


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 15:29 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
ElChristou wrote:
t00fri wrote:
ElChristou wrote:
BTW, the color of those BMNG raw maps are free of the atmosphere effect, right? Any way to readjust them meanwhile Celestia is unable to simulate the effect of the atmosphere?


That is right Christophe. This is also the reason why the BMNG RGB maps appear too dark to some.
What can presently be done is to add some /effective/ atmospheric color effects via a coloration of the RGBA cloud layer. The Mie theory of atmospheres that is now implemented does already provide quite a number of non-trivial atmospheric scattering effects. But so far it does NOT allow to illuminate the surface with the sky color. See my respective thread in the Developer Talk forum@shatters.net

Cheers,
Fridger


Yep, but seems it's not tomorrow the planet rendering code will be rebuilt...

Now the cloud map trick seems odd to me... I mean not sure that what will be good to adjust the oceans color will be ok for lands (where we have green/beige tone)... :?


No it's not odd really. I am doing this since > 5 years with some success ;-)
I am coloring a vertical light-bluish bi-gradient into the RGB cloud background. This emulates to some extent a global atmospheric illumination effect and should not differ appreciably between land and sea. Note, it's NOT due to a reflection of light in the sea!

Actually this discussion does not seem to belong into this thread ;-) , since my F-TexTools cannot change that problem.

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 15:39 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
...Actually this discussion does not seem to belong into this thread ;-) , since my F-TexTools cannot change that problem...


True... let's return on the topic...


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 15:49 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
DW,

today, I spent quite a bit of time with testing and debugging wrto our new fastfloor() and fastnint()
While full-size tests (85k) give a straight NULL in

nvimgdiff outfile16k-pre2.png outfile16k-pre3.png .........................(Example1) :D

for Windows XP on my Core 2 Duo notebook,

Linux does something different (wrong) such that nvimgdiff gives a significantly non-zero result.

I checked that your TWO-PASS optimization is fine throughout, and the problem is rather in BOTH
fastfloor() and fastnint()!

From fastint() the Max absolute error = 1.000000 in nvimgdiff
Same for fastfloor().

Example 1, involving both (tx2pow2 AND tx2half) gives : Max absolute error = 2.000000

I went through the code in detail and could not find any problem.

Moreover, I checked with nvimgdiff that Win32 and Linux outputs at the pre2 level were the same:

------------------------------------------------------------------------
nvimgdiff outfile16k-pre2.Linux.png outfile16k-pre2.Win32.png ==> NULL
------------------------------------------------------------------------

To get rid of the above-mentioned warning

tx2pow2.cpp:84: warning: dereferencing type-punned pointer will break strict-aliasing rules
tx2half.cpp:41: warning: dereferencing type-punned pointer will break strict-aliasing rules

the gcc option
-fno-strict-aliasing
does the job. There is lots of respective talking in the net.

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 18:34 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
DW,

...I am kind of stuck, concerning Linux.

Nint() is known to be a generic problem. e.g. -ffast-math gives wrong results for nint() in gcc. I have also tried to substitute lround() for nint(). Lround() has been defined in C99 and should do what nint() is supposed to do. But again lround() gives even a bigger discrepancy.

Probably the problem goes back in some way to that "warning"

tx2pow2.cpp:84: warning: dereferencing type-punned pointer will break strict-aliasing rules
tx2half.cpp:41: warning: dereferencing type-punned pointer will break strict-aliasing rules

That is NOT harmless with more recent gcc's. If I don't add -fno-strict-alias the result is a black texture.

Lround() is not known in VS 2003.net.

Any ideas?

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 22:38 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
DW,

that fastfloor() I found here

http://lists.freedesktop.org/archives/c ... 04419.html

it works correctly for Linux! Havn't tested it otherwise yet. It's also somewhat slower due to the division by 2^16. This could be improved upon, I suppose.
Code:
inline int fastfloor(double val) {
   val = val + 103079215104.0;
#if 0
   return (int)((*(long long *)&val)>>16);
#else
   return (((int*)&val)[_xs_iman_]>>16);
#endif
}

Works for -32728 to 32727.99999236688
Requires IEEE floating point.
Rounds numbers greater than n.9999923668 to n+1 rather than n.
The alternative that uses long-long works for -2147483648 to
2147483647.999923688

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 23-09-07, 23:43 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 436
Location: South Korea
Several questions:
1. Is it just an issue with fastfloor() or also with fastnint()? (you can comment out either USE_FASTFLOOR or USE_FASTNINT)
[s]2. Is your Linux machine 64-bit by any chance?[/s]
3. Does this work? (may appear equivalent to my original code, but just in case it's a syntax issue..)
Code:
const double _floormagic_= 6755399441055744.0 - 0.5 + 1.5e-8;

inline int fastfloor( double x )
{
    x = x + _floormagic_;
    return ((int*)&x)[_xs_iman_];
}


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 8:00 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
dirkpitt wrote:
Several questions:
1. Is it just an issue with fastfloor() or also with fastnint()? (you can comment out either USE_FASTFLOOR or USE_FASTNINT)
[s]2. Is your Linux machine 64-bit by any chance?[/s]
3. Does this work? (may appear equivalent to my original code, but just in case it's a syntax issue..)
Code:
const double _floormagic_= 6755399441055744.0 - 0.5 + 1.5e-8;

inline int fastfloor( double x )
{
    x = x + _floormagic_;
    return ((int*)&x)[_xs_iman_];
}

    (1) Basically it is an inssue with both, in case of your magic-number based fastfloor() and fastnint(). Each gives a maximum error of 1, hence the sum =2 relative to the slow default versions.

    Yes, of course I traced this by running with USE_FASTFLOOR and USE_FASTNINT separately.

    (2) No, the Desktop machine where I run Linux is 32bit. My core2Duo notebook is 64bit, but runs with a 32bit Windows. Also there everything is perfect.

    (3) That I can only test tonight.


Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 14:28 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 2:32 GMT
Posts: 436
Location: South Korea
Fridger, I just finished a test with OpenSUSE Linux 10.2 (x86 64-bit).
The result is: error = 0 !
That is with my original magic number fastint() and fastfloor() that I sent you via mail (i.e., not the mods suggested in the previous post). Here's what I did:

1. Downloaded the 5-CD torrent set from www.opensuse.org
2. Made a suse64 VMWare 2.0.1 virtual machine and installed 64-bit OpenSUSE (note: my host OS is Win XP 32-bit, but cpu is a 64-bit Core 2 Duo)
3. Compiled inside Linux using the default Makefile but with -fno-strict-aliasing added
4. Ran Test1 (tx2pow2 / tx2half / bin2png), then ran it again without any optimizations. nvimgdiff confirmed error = 0
5. Just to be sure, also ran nvimgdiff against a reference png generated using my Mac. Error = 0

So this indicates the 2-pass and fast..() optimizations are usable on Linux and Windows running on a Core 2 Duo (Additionally it also proves that F-TexTools runs great as 64-bit). :)

Could this mean that the CPU that you're running Linux on has a hardware bug? Some Pentiums in the past have been known to have floating point bugs...
We can choose to work around this bug by somehow detecting it at runtime, but it depends on whether we should consider max 1.0 absolute error to be significant. What do you think?


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 18:51 GMT 
Offline
User avatar

Joined: Sun, 02-09-07, 16:06 GMT
Posts: 346
Location: Rome, Italy
Here some new examples and some doubts (I’m using the June texture):
1- I gave a look to some well known locations, and here are the three lakes, that we have seen a lot of times, but this is wonderful, IMHO;

Image

2- I see that as most of textures, the new one is missing the Northern ice covering.
I would like to know the reason. Anyhow, it’s a pity that it’s missing, the Earth looks very strange this way.

Image

Image

3- I was looking at Gran Canyon and Lake Meade, that I saw personally twice, both on ground and by air. I found the new image very nice, but something was almost missing: 50% of the lake disappeared from the previous image, and from what I saw on 2000.
This is using Jmii's 64k VT:

Image

and this using the NEW 64k VT:

Image

Just for curiosity, and supposing that this could be due to summer draught (remember, I’m using June map) I searched on the net and found this page:

http://earthobservatory.nasa.gov/Study/LakeMead/#

There is an image showing the lake on May 2000 (I was there on June same year), and crossing the cursor on the image you can see the reduced lake dimension on 2003, due to draught.
You can see it here:

Image

The lake is only a bit slimmer, but with almost its full length, not as shown in the Celestia map. :shock:
Someone can give me the reason why?
Is it possible to know the date of this image?
Tks a lot
Bye

Andrea :D

_________________
Andrea
WorldPoss Sn Team Member
Core 2 Quad Q6600 G0 3.6 GHz- 4 GB DDR2- DELL 2709W 1920x1200-WinXP 32 SP3- VISTA 64- ASUS P5K-E- 8800 GTX 768MB- SATA II 320-300 GB-IDE 1 TB- 169.21- Celestia1.4.1_patch3- 1.5.1-LUA Edu Tools


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 19:31 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
Hey Andrea! PERFECT!

that's all I can say. I am VERY happy to see this though your beautiful images...

Here is a little secret that I didn't tell around yet:

After many experiments, I found that the best normalmap 3D effects WIHOUT getting into a "plastic" look, happens when the land on the spec map is NOT black, but has a small amount, 12% , of rest light!
This brings out MANY more delicate features on the surface. That's what you implemented by using my prescriptions...

Cheers,
Fridger

PS: The BMNG surface maps are from June 2004.

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 19:45 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4657
Location: Hamburg, Germany
dirkpitt wrote:
Fridger, I just finished a test with OpenSUSE Linux 10.2 (x86 64-bit).
The result is: error = 0 !
That is with my original magic number fastint() and fastfloor() that I sent you via mail (i.e., not the mods suggested in the previous post). Here's what I did:

1. Downloaded the 5-CD torrent set from www.opensuse.org
2. Made a suse64 VMWare 2.0.1 virtual machine and installed 64-bit OpenSUSE (note: my host OS is Win XP 32-bit, but cpu is a 64-bit Core 2 Duo)
3. Compiled inside Linux using the default Makefile but with -fno-strict-aliasing added
4. Ran Test1 (tx2pow2 / tx2half / bin2png), then ran it again without any optimizations. nvimgdiff confirmed error = 0
5. Just to be sure, also ran nvimgdiff against a reference png generated using my Mac. Error = 0

So this indicates the 2-pass and fast..() optimizations are usable on Linux and Windows running on a Core 2 Duo (Additionally it also proves that F-TexTools runs great as 64-bit). :)

Could this mean that the CPU that you're running Linux on has a hardware bug? Some Pentiums in the past have been known to have floating point bugs...
We can choose to work around this bug by somehow detecting it at runtime, but it depends on whether we should consider max 1.0 absolute error to be significant. What do you think?


DW,

I am without words, after spending much time to locate and trace the problem with fastfloor() and fastnint() under Linux. But, I am still not convinced that your result is what would be seen on a native 32bit Linux installation! You do not know how the magic numbers get affected with 64bit. In any case the int specs are different now from what I use. Next you installed all this on a VM...

Since I frequently use my cpu for pofessional hard core number crunching, I checked after buying it that is did not have any of the known bugs. Also I never encountered any problems elsewhere.

I can install and benchtest the tools on my Linux machine in the office, a 2.8 GHz P4. Let's see what happens. Then my wife still has a 1GHz P3 upstairs, so again that should roughly perform like your PPC MAC. And using the 'dwarf' data set , the tests will be quick.

I'll keep you informed...

During the rest of the week we have our annual international Theory Workshop running at my lab

https://indico.desy.de/conferenceDisplay.py?confId=429

So I might be a bit busy due to my committments as a "host"...

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 24-09-07, 19:47 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
Andrea wrote:
2- I see that as most of textures, the new one is missing the Northern ice covering...


Off topic again (sorry :oops:) but indeed this is a bit annoying... :?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 196 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 14  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group