Ron Parker wrote:
> Sorry, no, that's not what it does.  It calculates the normal at each
> corner, then linearly interpolates between corners.  There is no
> "plane normal."  The normal vector varies continuously across the
> surface of the object.  Whatever you're seeing, it's not due to
> normals.

Ah, I see. Of course, that's similar to what I thought it was doing
anyway.
At any rate, a "smooth <value>" keyword could be used to change from
linear interpolation to a non-linear value. It could be applied as an
exponent, for example, with 1.0 being the linear default. A higher
exponent would mean more smoothing.
For example, if the current routine interpolates between vectors based
on d and 1-d, the distance from each corner, then d^2 and (1-d)^2 would
tend to cause a lot more biasing toward the edges.
A simple interpolation (obviously not what the triangles use, but just
an example) might look like this:

(v1*d + v2*(1-d))/(d+(1-d))

If an exponent was added, it could be like this:

(v1*d^2 + v2*(1-d)^2)/(d^2+(1-d)^2)

Thus the weights in the average change in a non-linear fashion.

Lummox JR

Post a reply to this message

I have (finally) a more intelligent response regarding the smoothing
function.
In my last post I mentioned some pseudocode that would do what I was
suggesting for the textures. Now I finally have some *actual* code that
describes what I want to do with the height fields.
----------------------------------------------------------------------
This is an example of the height_field code in hfield.c, modified to
allow a more user-defined smoothing function. Although it won't produce
results as accurate as Peter Popov's adaptive-sampled bicubic idea,
because the surfaces are still flat, it should still allow the user to
increase or decrease the amount of smoothing. I took a look at the
superpatch source code, here, though I imagine exactly the same changes
would apply to the original POV-Ray 3.1 executable.

Naturally, changes are also required in parse.c to allow the smooth
keyword to accept a numeric value (or to use 1.0 as a default if the
keyword is found). The change would go something like this:

height_field {
    ...
    smooth [float value]
    }

The float value is smooth_exponent, a value used in the normal
calculation process. If this is just 1.0, then linear interpolation of
the corner vectors (the current default) is still used, and the
original code is called for the sake of speed. If it's not 1.0, the
exponent is applied and used to warp the u, v, x, and z values.

----------------------------------------------------------------------
Segment of original HField_Normal() code (for smoothed normals):

    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]);

Segment of proposed new code:

    x = stretch(x);
    z = stretch(z);

    u = (1.0 - x);
    v = (1.0 - z);

    /*
        smooth_exponent is a part of the height field structure itself,
        and div should be declared in the beginning of this function.
        Some error checking may be required when calling the pow()
        function, since it could cause numerical underflow or overflow.
     */

    if(smooth_exponent==1.0) {
        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]);
        }
    else {
        x=pow(x,smooth_exponent);
        z=pow(z,smooth_exponent);
        u=pow(u,smooth_exponent);
        v=pow(v,smooth_exponent);
        div=(x+u)*(z+v);
        Result[X] = (v*(u*n[0][X] + x*n[1][X]) + z*(u*n[2][X] +
x*n[3][X]))/div;
        Result[Y] = (v*(u*n[0][Y] + x*n[1][Y]) + z*(u*n[2][Y] +
x*n[3][Y]))/div;
        Result[Z] = (v*(u*n[0][Z] + x*n[1][Z]) + z*(u*n[2][Z] +
x*n[3][Z]))/div;
        }

----------------------------------------------------------------------

A higher exponent causes the x and u values, and z and v, to diverge
farther from each other, thus biasing the result to favor the corners
more heavily. Since the normal will now be seen as if it was further
toward the edge, the triangle will have a much more rounded appearance.

Naturally, a lower exponent will have the opposite effect, converging
the values toward each other, and thus away from the corners. A low
smoothing value should cause a semi-faceted look, with smooth edges
but a flat center.

Zero should produce a very flat surface--but interestingly, it will
remove the two-triangle appearance caused by no smoothing at all.
Bizarre effects could come of using negative values, because the
normals for all the corners will be effectively swapped.


Lummox JR

Post a reply to this message

Wish I had spoken up earlier, this topic should really be carried out in the
povray.programming newsgroup. Building up quite a case for a change in the
'height_field' here and just isn't the right place to discuss it when there's a better
place.

Post a reply to this message

On Sun, 13 Jun 1999 23:58:46 -0400, Lummox JR wrote:
>Zero should produce a very flat surface--but interestingly, it will
>remove the two-triangle appearance caused by no smoothing at all.

This is true.  It's because the normal is interpolated (or in this
case, averaged) across the square, not across the two triangles.  
The triangles end up being rendered with a different normal than 
they actually have.  This is interesting code, but I'm not sure
whether 'smooth' is the right word for what it does.

Post a reply to this message

Ron Parker wrote:
> 
> On Sun, 13 Jun 1999 23:58:46 -0400, Lummox JR wrote:
> >Zero should produce a very flat surface--but interestingly, it will
> >remove the two-triangle appearance caused by no smoothing at all.
> 
> This is true.  It's because the normal is interpolated (or in this
> case, averaged) across the square, not across the two triangles.
> The triangles end up being rendered with a different normal than
> they actually have.  This is interesting code, but I'm not sure
> whether 'smooth' is the right word for what it does.

Well, I posted it in the povray.programming group as well, touting it as
a possible superpatch addition. Personally, I'd be thrilled if you
decided to throw it in there--it'd save me the work of trying to make
the necessary modifications myself, since I know very little about
working with the source code.

Lummox JR

Post a reply to this message