The Povray doc says (in many places) that scaling bumps affects
only the horizontal size of them, not their height.

OTOH, the source [normal.c, function bumps()] computes essentially
the derivative (i.e. an additive term for the surface normal)
of "unit" bumps, taken at the inversely scaled location.
(Unless I misunderstood it.)

Unfortunately, scaling and taking the derivative
(which is what creates the surface normal from the height)
are not exchangeable. Scaling first and deriving then multiplies
the derivative with the inverse of the scaling factor,
which gets lost if the operations are permuted.

This gives an (IMHO) unrealistic look if the
bump normal is scaled anisotropically.

E.g. the following scene gives a bright region (consisting
of horizontal bright spots) in an otherwise black image:

//start
#declare here=<0,0,-4>
light_source { here color rgb 1 }
camera { location here look_at 0 }

plane { -z,-1
  texture {
    pigment { color rgb 1 }
    finish { ambient 0 diffuse 0 phong 0
             specular 1 roughness 0.01
    }
    normal { bumps 0.1 scale <0.3, 0.03, 1> }
    // the anisotropy is 0.3 != 0.03
 }
}
//end

The bright spots in this central region are wide in the
x-direction and narrow in the y-direction (as expected).

Now, the problem is that the bright region as a whole should be
much larger in the y-direction than in the x-direction, instead
of being circular. (Theoretically, it should be an ellipse with
approximately the inverse x-y-ratio as that of the individual bumps.)

I believe that this behavior (whilst unphysical (see below))
is intended - it just disagrees with the manual.

After looking for some time at this image, one gets a strange
feeling - there *is* just no surface which might look like this
picture.

Doing the math shows why: The surface normal of a real surface
is a vector field which fulfills some differential equation
(A x (rot A)=0, where "x" is the vectorial product), called
surface orthogonality (it just means that the vector A is parallel
to some gradient). Now, the "normal" in the picture is not orthogonal
to any imaginable surface, since it violates that equation.

Is this a known problem?

(Btw., I'd prefer to see povray being changed in order to fit
the manual rather than the other way around, but this probably
would break many other peoples' code).

I just tried wrinkles and dents - they have the same problem.

Ralf

Post a reply to this message

Ralf Muschall <rmu### [at] t-onlinede> wrote:
: Unfortunately, scaling and taking the derivative
: (which is what creates the surface normal from the height)
: are not exchangeable.

  Are you sure?

by definition:

  d(a*f(x))/dx = a*d(f(x))/dx

-- 
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

Nieminen Mika schrieb:
> Ralf Muschall <rmu### [at] t-onlinede> wrote:
> : Unfortunately, scaling and taking the derivative
> : (which is what creates the surface normal from the height)
> : are not exchangeable.

>   Are you sure?

> by definition:

>   d(a*f(x))/dx = a*d(f(x))/dx

This is not the problem, since it is not scaling (your a is
the parameter which is to be written after the keyword "bumps",
i.e. what the manual thinks it were the _height_ of the bumps).

Scaling affects the _argument_ of the function, and

(D g)(x) = b*(D f)(b*x)                 [1]

where
g(u):=f(b*u), and the operator D takes the derivative of
the function wrt. its argument.
[1] is essentially the chain rule, where the inner function
is the multiplication by a constant.

My b is the inverse of the parameter after the keyword
"scale". POV's (or my) problem is that the first "b*" on the
right hand side of equation [1] is missing (or left out
intentionally).

Ralf

Post a reply to this message

Ralf Muschall wrote:

> The Povray doc says (in many places) that scaling bumps affects
> only the horizontal size of them, not their height.

    I'm going to assume that you've got the correct understanding of `height'
(height not being equal to y-size), and that you're dealing with typical
right-handed POV-space (rather than cartesian space)....

> [...]

> Unfortunately, scaling and taking the derivative
> (which is what creates the surface normal from the height)
> are not exchangeable. Scaling first and deriving then multiplies
> the derivative with the inverse of the scaling factor,
> which gets lost if the operations are permuted.

    I can understand this, but I /don't/ understand how this relates to the
example code that you've given, or the `problem' stated immediately after it--

> //start
> #declare here=<0,0,-4>
> light_source { here color rgb 1 }
> camera { location here look_at 0 }
>
> plane { -z,-1
>   texture {
>     pigment { color rgb 1 }
>     finish { ambient 0 diffuse 0 phong 0
>              specular 1 roughness 0.01
>     }
>     normal { bumps 0.1 scale <0.3, 0.03, 1> }
>     // the anisotropy is 0.3 != 0.03
>  }
> }
> //end
> [...]
> Now, the problem is that the bright region as a whole should be
> much larger in the y-direction than in the x-direction, instead
> of being circular. (Theoretically, it should be an ellipse with
> approximately the inverse x-y-ratio as that of the individual bumps.)

    I really don't understand your reasoning, here--as far as the `bright spot'
is concerned, it doesn't matter how you scale the normal-perturbation, because
the bright spot is the result of the light-source, which /is circular/ (even if
you apply a scaling transformation to the light-source, it'll still be
circular, because, as you know, you can't really change the form of a
point--you can just move it).
    Perhaps you could explain /why/ the sphere of illumination (or, rather, the
circular intersection of the sphere and the plane) should be scaling when you
scale the bumps on the plane(?). I'm really not seeing why--my thinking is
(partially) explained by the this scene, rendered with clock values between...
umm... .01 and 3 (+KI0.01 +KF3) (generate however many frames you want):

//start
camera {
  location -z*6
  angle 30
  look_at 0
  rotate <30, -30, 0>
}

light_source {
  <.35, .35, .35>
  rgb 1
}
light_source {
  <5, 5, 5>
  rgb 1
}

sphere {
  0, 1
  clipped_by {
    plane {
      -z, 0
      scale <clock, 1, 1>
    }
  }
  pigment {
    rgb 1
  }
  finish {
    specular .2
    roughness .01
  }
}
//end

    Now, if you were to move that `scale' expression out of the plane, into the
main body of there sphere, you'd have something that exhibited the behaviour
that it looks like you're expecting, but, of course, that's from scaling the
sphere.

> Is this a known problem?

    I don't think that it's a problem, let along a known problem, but, pleas,
help understand your thinking, if I've misunderstood it.

> I just tried wrinkles and dents - they have the same problem.

    I'd expect the same family of things to behave the same (or, at least,
similarly)


                    -Rozzin.

Post a reply to this message

Rozzin wrote:
>     I'm going to assume that you've got the correct understanding of `height'
> (height not being equal to y-size), and that you're dealing with typical
> right-handed POV-space (rather than cartesian space)....
I guess you mean "left-handed" here (left is POV, right is normal,
both are just different *names* for the same space).

I did not mention the coordinate stuff and kept my posting pure
mathematical
(which is what I feel more at home with than with graphics, being a
physicist).

>     I can understand this, but I /don't/ understand how this relates to the
> example code that you've given, or the `problem' stated immediately after it--

It is all the same problem: Let's assume POV's coordinates, have the
plane {-z,-1} as in my example (e.g. the outer normal points towards
the camera), and bumps on it, which peak into the negative z-direction
(which I call "up" for now). E.g. I call +x "east", +y "north",
and +z "down". (This can be made to agree with the usual interpretation
of the POV manual, if you imagine the *person* holding the camera
lying on his back, with the feet pointing in the +z direction (and
lifting the head in order to look at the feet).
Then the manual's interpretation holds for the camera, and my
sentence holds for the person. Neither of them is important here -
it is all math which doesn't care about what names we give to
the directions).

Since I scaled those bumps anisotropically, they have still the given
height
(i.e. "-z"), but a wide east-west-extension ("x"), and are rather narrow
north-south-wise ("y"). (At least they should if the manual chapter
about
bumps were right.)

Now, if we have a hill with a given height, which is long
east-west-wise,
but narrow north-south-wise, the wall on its north side has to be much
steeper than the one on the east side (they have to cover the same
height,
but the latter does so over a longer baseline).

OTOH, a steeper slope means that reflected light differs more from what
an ideal plane would reflect, e.g. hills which are located very far in
the north should still be visible, but hills far in the east should
should
not be. This would give the elliptical bright region which I asked for
(and
got a circular instead).

>     I really don't understand your reasoning, here--as far as the `bright spot'
> is concerned, it doesn't matter how you scale the normal-perturbation, because
> the bright spot is the result of the light-source, which /is circular/ (even if
> you apply a scaling transformation to the light-source, it'll still be
> circular, because, as you know, you can't really change the form of a
> point--you can just move it).

The bright region (I avoided the word spot to avoid confusion with
the appearance of the single hills) has nothing to do with the
shape of a sphere - it is just the set of those points on the
textured plane where the perturbed surface reflects light from
the source into the camera. If such points on the plane exist 
far away, we get a large region, otherwise a small one.

What you could try instead of my textured plane is the following:

Make a heightfield of anistropic bumps and use that instead of
the bumpy plane. Then the x/y ratio of the diameters of the
bright region is approximately the *inverse* of the x/y-ratio of
the shape of the single bumps, whereas POV's faked normals
always give a ratio of 1 for the former, independently of the latter.

Your source example:
[camera and lightsources deleted]

> sphere {
>   0, 1
>   clipped_by {
>     plane {
>       -z, 0
>       scale <clock, 1, 1>
IMHO scaling a (not yet textured) plane along a direction which 
lies *in* the plane should not have eny effect at all (and every
other operation on a plane should be equivalent to a pure movement).
>     }
>   }
>   pigment {
>     rgb 1
>   }
>   finish {
>     specular .2
>     roughness .01
>   }
> }
> //end

Your scene (which I did not render yet, since I'm posting from 
another machine) seems to show me the inner side of a hemisphere.

OTOH, I intensionally avoided anything which might destroy
the symmetry of my scene (except the bumps themselves, of course)
in order to avoid any unwanted effects. Therefore I had
a plane (which is the same no matter how one looks at it),
and the lamp and camera both on the axis of the rotational
symmetry of the whole scene. In this situation, every
asymmetry could only come from the texture (but none came :-(
).

>     Now, if you were to move that `scale' expression out of the plane, into the
> main body of there sphere, you'd have something that exhibited the behaviour
> that it looks like you're expecting, but, of course, that's from scaling the
> sphere.

This would deform the sphere, but not its texture.
But what I really want is to get the physically correct appearance
of a bumpy surface whose bumps are elongated.

Ralf

Post a reply to this message