![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I have posted two images to p.b.i showing an identical scene containing
one isosurface rendered using Megapov 0.4 One was on a RedHat 6.1 box,
the other on a Windows machine. As you can see, there is a quite marked
difference. I suspect the Windows version, the one without the white
regions, is the correct one, but am at a loss as to why. Both binaries
were pre-compiled, one by Nathan Kopp, the other by Mark Gordon. The
source to the scene is posted below. Can anyone else duplicate or
explain this?
-Alex V.
// Forgive the hideous function -- it was computer-generated (see
earlier image in p.b.i)
#version unofficial MegaPov 0.4;
isosurface{
function{((((sin(noise3d(x,x,y))/((0.0903843115083873*y)/(x+y)))*
((abs(y)+(y^0.308258313219994))+((y/z)^abs(x))))^abs((((z*0.434349831193686)
-(z+z))+(sin(z)-sin(0.309442261699587)))))^(((noise3d(sin(0.673113088589162),
noise3d(y,x,x),(x*z))/(sin(0.628716635052115)-
noise3d(0.81341931829229,x,0.655613251496106)))+(abs(abs(0.426932952366769))
+abs((z/z))))/noise3d(sin(((x+y)^(z^z))),sin(((0.947182392701507^z)*sin(z))),
sin(((z+x)^(y/z))))))}
contained_by {sphere{0,1}}
threshold .5 pigment {rgb 1} rotate <30,60,90>
}
light_source {<10, 50,15>, 1}
light_source {<10,-50,15>,.5}
camera {location <2,0,0> up y look_at <0,0,0>}
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Alex Vandiver wrote:
>
> I have posted two images to p.b.i showing an identical scene containing
> one isosurface rendered using Megapov 0.4 One was on a RedHat 6.1 box,
> the other on a Windows machine.
> function{((((sin(noise3d(x,x,y))/((0.0903843115083873*y)/(x+y)))*
Just a thought, with that many decimal places you may be getting round off
differences between the two platforms - maybe ?
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ken wrote:
> Just a thought, with that many decimal places you may be getting round off
> differences between the two platforms - maybe ?
P'haps, but that would probably just tweak the shape of the isosurface, not
cause the strange, intense brightening of certain areas. Or so I would hope..
-Alex V.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I tried this scene with my Solaris compile of Megapov 0.4 and it looks
like the second image.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Well, I can tell you that on OpenVMS the final image looks like the
first image.
If it's a floating point problem I can check this out by compiling
MegaPOV without ANSI_FLOAT and using the standard OpenVMS float mode and
see what the image looks like :}
--
+--------------------------+----------------------------------------+
| Robert Alan Byer | "I don't want to take over the world, |
| bye### [at] mail ourservers net | just my own little part of it." |
| Phone: (317)357-2724 | http://www.ourservers.net/~byer |
+--------------------------+----------------------------------------+
| Send an E-mail request to obtain my PGP key. ICQ #65926579 |
+-------------------------------------------------------------------+
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Well, I have found the culprit. In a way, it *IS* an accuracy problem -- more
specifically, it is a division by zero problem. The following code produces the
problem a little more handily:
#version unofficial MegaPov 0.4;
isosurface{
function{(1/0)}
contained_by {sphere{0,1}}
threshold .5 pigment {rgb 0} finish {ambient 0}
}
camera {location <2,0,0> up y look_at <0,0,0>}
Apparently the Solaris and Linux compiles freak out upon seeing the division by
zero and return white -- no matter the color they are "supposed" to return.
Interestingly, adding "method 2" to the above isosurface "fixes" the problem, but
probably only because of the low value of MaxGradient. Is there a test which
could be added to the method 1 section to stop infinite values from "whiting out"
the isosurface?
-Alex V.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |