 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:401cb209$1@news.povray.org Slime wrote:
> In
> any case, the normals of the rightmost and topmost vertices of height
> fields are not calculated, so seemingly random values from the
> allocated memory are used instead.
I subtracted two consecutive renders of your scene, in the resulting image
is a white line where the left and bottom edges of the HF are. So bug
confirmed
Athlon 1800+ 1.5GB Win2000.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I subtracted two consecutive renders of your scene, in the resulting image
> is a white line where the left and bottom edges of the HF are. So bug
> confirmed
The left and bottom? That's strange, I didn't have any problems with that
area.
The artifacts should be plainly visible - though as I said, you can't
necessarily see it immediately, since the uninitialized memory has to
already have been used for something else.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I subtracted two consecutive renders of your scene, in the resulting
image
> > is a white line where the left and bottom edges of the HF are. So bug
> > confirmed
>
>
> The left and bottom? That's strange, I didn't have any problems with that
> area.
After some thought, I suspect the white line you got in the difference was
caused by AA jittering, and not the bug I described.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have posted two example images in povray.beta-test.binaries.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:401d5275$1@news.povray.org Slime wrote:
> After some thought, I suspect the white line you got in the
> difference was caused by AA jittering, and not the bug I described.
>
Oops, that could be.
I don't get the artifacts as shown in the images you posted.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oops, that could be.
> I don't get the artifacts as shown in the images you posted.
It seems like you might have to first increase the height field size (to
like 40x40 or 64x64 or whatever) and then reduce it again. Just keep
changing the size and rendering and re-rendering and eventually you'll get
it.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> [...]
>
> If I remember correctly, this problem can be fixed simply by replacing two
> less-than signs with less-than-or-equal-to signs in the source code.
That seems correct, the Megapov patch changed this together with the
Smoothing problem but this was not in 3.6. Should be fixed in next beta.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> I have posted two example images in povray.beta-test.binaries.
I get the same kind of artefacts.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Strange, I don't get those artifacts.
However, what worries me the most is that this heightfield should
be smooth but isn't. The grid is clearly visible and shouldn't. There's
something wrong here.
It looks better than when rendered with 3.5, but I still think the grid
should not be visible.
Does anyone know what's going on here?
Compare it to this:
camera {
location <.8,1,-.5>
look_at <.5,0,.5>
}
#include "shapes.inc"
object
{ HF_Square(function {pattern{bozo scale 1/3}}, no, no, 32, yes, "", 0, 1)
scale <2,.5,2>/2
pigment {rgb 1}
}
light_source {
<.5,3.5,-.5>*0 + <-1,1,-1>*999
rgb 1
}
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Does anyone know what's going on here?
Well, the fundamental difference between height field smoothing and mesh
smoothing is that height field smoothing is done per-square and not
per-triangle. That may be the sole reason for the visibility of the squares.
That, plus the fact that our eyes are very good at picking up
discontinuities in the first and even second derivatives of gradients.
*looks at v3.5 source code*
OK, here's the relevant code:
At this point, x and z are values from 0 to 1, representing the coordinates
in the current square which is being interpolated:
x = stretch(x);
z = stretch(z);
u = (1.0 - x);
v = (1.0 - z);
Result[X] = v*(u*n[0][X] + x*n[1][X]) + z*(u*n[2][X] + x*n[3][X]);
Result[Y] = v*(u*n[0][Y] + x*n[1][Y]) + z*(u*n[2][Y] + x*n[3][Y]);
Result[Z] = v*(u*n[0][Z] + x*n[1][Z]) + z*(u*n[2][Z] + x*n[3][Z]);
Simple bilinear interpolation; except that x and z were first run through
this "stretch" function:
static DBL stretch (DBL x)
{
if (x <= 0.5)
{
x = 2.0 * x * x;
}
else
{
x = 1.0 - (2.0 * (1.0 - x) * (1.0 - x));
}
return(x);
}
Which pulls x and z closer to the edges of the square. I suspect that if
this function is not used, that the interpolation may appear more like the
image Warp provided. I think it's worth a shot to see if it looks better or
worse when this function is not used.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
