This script will allow you to first make a image consisting of pixel sized
black and white checkers. Then you can use it as a HF with the same image
mapped onto that.
In case you have never done a pixelized checker pattern you're in for a
treat, or a disappointment, when you see how well, or badly, your monitor
displays pixels. I clicked and dragged the resulting image around to see
the monitor corners too. I have a terrible display here, .39 dot pitch I
already knew, but it's awful.
Well, anyway, reason for all this is to see what a HF is made up of, at
least an attempt to. I looked from all sorts of vantage points and camera
angles and darned if I know yet what it is. Triangles perhaps? Well, if
you try this you may be surprised at what's going on. Don't just use the
camera settings I have put here, try several ways of looking at this. One
time I saw 3 levels (instead of one each) of white and black "stripes",
not the expected white peaks and black valleys. Maybe I'm doing this all
wrong. Here it is to check out.


// Persistence of Vision Ray Tracer Scene Description File
// File: pixels_hf.pov
// Vers: 3.1
// Desc: height field using B&W checkered pixel image map and how the pixels are
mapped
// Date: 99.43 
// Auth: Bob Hughes
// Note: Use +w500 +h500 +fn +oC:\Images\bw_pixel.png to create the initial image
// from then on set P to 2 and remove the above command line, use your usual INI
settings

//As is set up you will see the bottom-left corner of the HF. Watch for line wrap too.

#declare P = 2;  //1 to create pixelated image, 2 for height field using that image
#declare Zoom = .05; //HF viewing. less to magnify, more to zoom out [0.005 to 1]
#declare Center = 0; //HF centering. 0 to focus on bottom-left corner, 1 to center
#declare H = .1; //HF y axis height scale multiplier. 1 for cube, less for flattened
box

//light_source { <1.5,1.5,-1.5> color rgb 1.5 }

#switch (P)
#case (1)

global_settings { hf_gray_16 on }

camera {
 orthographic
  location  <0,0,-3>
  up 1*y right 1*x
  look_at   <0,0,0>
}

plane {z,0 pigment {checker color rgb 0 color rgb 1 scale .002 rotate -90*x}
 finish {ambient 1}}

#break
#case (2)

global_settings { hf_gray_16 off }

camera {
 //orthographic
  location  <0,0,-3>
  up Zoom*1*y right Zoom*1*x
  look_at   <0,0,0>
}

background {rgb <1,.5,.25>}

height_field {
  png "c:\images\bw_pixel.png" //smooth
  texture { pigment {
      image_map { png "c:\images\bw_pixel.png"
         map_type 0 //interpolate 2 once
         } rotate 90*x
    }
     finish {ambient 1}  //make visible
  }
   translate -.5*Center
    scale <1,1*H,1>
 //sawtooth pattern view (top of HF is turned 45 degrees toward the camera)
     rotate <-45,0,0>
 }

#end
//END

Post a reply to this message

On Mon, 07 Jun 1999 07:37:53 -0500, Bob wrote:
>Well, anyway, reason for all this is to see what a HF is made up of, at
>least an attempt to. I looked from all sorts of vantage points and camera
>angles and darned if I know yet what it is. Triangles perhaps?

Yes, triangles.  Each 'cell' in a heightfield is a pair of triangles
whose vertices are the values of the four pixels surrounding the cell.
The simplest case is when you have an image of 2x2 pixels.  In that
case, you get a heightfield of a single cell, composed of two triangles.

If you look at the heightfield from the +y direction with a sky of +z,
it will be constructed like this:

   z=1,x=0  x=z=1
    +------+
    |\     |
    | \    |
    |  \   |
    |   \  |
    |    \ |
    |     \|
    +------+
   0        x=1,z=0

Here's what you get with a 3x3 source image:
  
   +---+---+
   |\  |\  |   
   | \ | \ |   
   |  \|  \|   
   +---+---+
   |\  |\  |   
   | \ | \ |   
   |  \|  \|   
   +---+---+

In the absence of interference effects, a checkerboard like the one 
you're using will always be rendered as a series of diagonal ridges 
and valleys.

Post a reply to this message

Hey, great to see this explained. The POV-Ray Scene help file shows this too, I
finally
looked it up there (again). This is what I wasn't quite getting about it, the fact
that
only a pair of triangles gets made from 4 pixels of the originating image. The
vertexes
are centrally based then after all, but not a pair of triangles per pixel as I was
thinking of it. This explains the sawtooth form my hf testing script was taking, since
they "stepped" from one to the other as a group of 4, or you could even say as a
"pair"
of black and white pixels (high and low points). Which would create only a slope.
Interesting thing is the slope appears to be made from one direction, I suppose
starting
from the origin <0,0,0>.
This certainly has given me new insight to this, thanks Ron.
I was seeing black and white stripes in one view which had 3 levels of height as a
group, might this be a direct cause and effect due to the pixel sized checkers and
something inherent to the way a HF is calculated as well? Makes me wonder....
The person originally wondering about "smoothing" a HF further would seem correct then
about possibly interpolating via spline between the intitial triangle creation and
producing a further tessalation. I could also see where this would also produce more
work for the parser and yet still amount to just making yet smaller triangles still
visible when viewed up close.
Not an idea to totally throw out I guess none the less.


Ron Parker wrote:
> 
> Each 'cell' in a heightfield is a pair of triangles
> whose vertices are the values of the four pixels surrounding the cell.
> The simplest case is when you have an image of 2x2 pixels.  In that
> case, you get a heightfield of a single cell, composed of two triangles.
> 
> If you look at the heightfield from the +y direction with a sky of +z,
> it will be constructed like this:
> 
>    z=1,x=0  x=z=1
>     +------+
>     |\     |
>     | \    |
>     |  \   |
>     |   \  |
>     |    \ |
>     |     \|
>     +------+
>    0        x=1,z=0
> 
> Here's what you get with a 3x3 source image:
> 
>    +---+---+
>    |\  |\  |
>    | \ | \ |
>    |  \|  \|
>    +---+---+
>    |\  |\  |
>    | \ | \ |
>    |  \|  \|
>    +---+---+
> 
> In the absence of interference effects, a checkerboard like the one
> you're using will always be rendered as a series of diagonal ridges
> and valleys.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

On Mon, 07 Jun 1999 21:19:54 -0500, Bob wrote:
>I was seeing black and white stripes in one view which had 3 levels of height as a
>group, might this be a direct cause and effect due to the pixel sized checkers and
>something inherent to the way a HF is calculated as well? Makes me wonder....

I think it might have been an interference pattern you were seeing.

>The person originally wondering about "smoothing" a HF further would seem correct
then
>about possibly interpolating via spline between the intitial triangle creation and
>producing a further tessalation. 

An interesting idea would be to implement a heightfield as a mesh of bicubic 
patches.  It'd be a memory hog, but it would probably look very good.

Post a reply to this message

On 8 Jun 1999 11:48:55 -0400, par### [at] fwicom (Ron Parker) wrote:

>An interesting idea would be to implement a heightfield as a mesh of bicubic 
>patches.  It'd be a memory hog, but it would probably look very good.

How about adaptive subdivision based on screen resolution and using
bicubic interpolation?


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> How about adaptive subdivision based on screen resolution and using
> bicubic interpolation?

I think that would do just dandy. I'm having a problem smoothing a
height field myself, and I think adaptive interpolation would be the
ideal solution. Too bad that's not already in there, because I can't
think of any way I could implement it in my scene, which desperately
needs it.

Lummox JR

Post a reply to this message

Ron Parker wrote:
> On Mon, 07 Jun 1999 21:19:54 -0500, Bob wrote:
[snip]
> >The person originally wondering about "smoothing" a HF further would seem correct
then
> >about possibly interpolating via spline between the intitial triangle creation and
> >producing a further tessalation.

That person was me, incidently. I have a post in povray.bugreports
(didn't know a the time where else to post), and Bob and I have further
conversed about it in povray.general.
My problem is that I'm using a large-scaled height field to simulate
sand dunes, and the camera is down within the height field itself. This
proximity apparently aggravates a nasty problem with the surface normals
of the triangles, causing some to shine out brightly because they face
the light; they look like marching diagonals of checkerboard squares.
Smoothing only blurs them; it doesn't eliminate them, as it should.

> An interesting idea would be to implement a heightfield as a mesh of bicubic
> patches.  It'd be a memory hog, but it would probably look very good.

I had proposed a more aggressive smoothing algorithm which would do the
job for me--simply making the triangles look even less flat, causing
more bending toward the outer normals. But even better, I like Peter
Popov's idea of adaptively sampling the height field and
interpolating--indeed, I suggested something similar myself in the
thread on povray.general (Not-so-smooth height field).
Although I've considered changing to something like bicubic patches, the
problems in that are many. The height values would have to be
individually calculated from the existing height field data (how, I have
no idea) and thrown into the scene file as text; for a 1200x1200 height
field (which, granted, I could probably scale down considerably if I
used bicubics), that's a bit excessive.
It seems to me that some sort of automatic interpolation function--only
used when called for, of course, to speed rendering time--would greatly
improve the quality of height fields without requiring that kind of
effort. Or, even something as simple as more smoothing would do the
trick, at least in my case.

Lummox JR

Post a reply to this message

On Wed, 09 Jun 1999 20:05:18 -0400, Lummox JR wrote:
>It seems to me that some sort of automatic interpolation function--only
>used when called for, of course, to speed rendering time--would greatly
>improve the quality of height fields without requiring that kind of
>effort. 

Depending on what sort of "automatic interpolation function" you're 
planning on, you might as well use the bicubic patches.  They're the
end result you'd get with a bicubic interpolation, for example.
Adaptive interpolation would certainly be nice, but if you're going
to implement it, do it for all bicubic patches.

>Or, even something as simple as more smoothing would do the
>trick, at least in my case.

I don't think there's such a thing as "more smoothing."  It's either 
smooth or it isn't - the 'smooth' version doesn't actually displace
any points; it just mucks with the normal vectors to make it look
smoother.

Post a reply to this message

Ron Parker wrote:
> Depending on what sort of "automatic interpolation function" you're
> planning on, you might as well use the bicubic patches.  They're the
> end result you'd get with a bicubic interpolation, for example.
> Adaptive interpolation would certainly be nice, but if you're going
> to implement it, do it for all bicubic patches.

Well, I've never mucked around with the source code anyway, so that's
sort of out.

> >Or, even something as simple as more smoothing would do the
> >trick, at least in my case.
> 
> I don't think there's such a thing as "more smoothing."  It's either
> smooth or it isn't - the 'smooth' version doesn't actually displace
> any points; it just mucks with the normal vectors to make it look
> smoother.

Ah, but that's just what I mean: Those normal vectors can be displaced
even further, or less far, depending on the smoothness desired by the
user. There has to be a function which tells the smoothing algorithm how
much of one corner to use, how much of another corner, etc., and how
much of the plane normal. The way I see it, the big problem with my
scene is that the triangles don't use the edge/corner normal vectors
nearly enough, and instead use too much of the plane normal. Thus, the
triangles still have a somewhat "flat" appearance, except at their very
edges, when instead they should look flat only very close to the middle.
An altered "smooth" keyword would be key, here, so "smooth 1.0" could be
the default smooth function, whereas "smooth 5.0" would tend to perturb
the normals more in favor of the corners.

Lummox JR

Post a reply to this message

On Fri, 11 Jun 1999 16:19:18 -0400, Lummox JR wrote:
>Ron Parker wrote:
>> I don't think there's such a thing as "more smoothing."  It's either
>> smooth or it isn't - the 'smooth' version doesn't actually displace
>> any points; it just mucks with the normal vectors to make it look
>> smoother.
>
>Ah, but that's just what I mean: Those normal vectors can be displaced
>even further, or less far, depending on the smoothness desired by the
>user. There has to be a function which tells the smoothing algorithm how
>much of one corner to use, how much of another corner, etc., and how
>much of the plane normal. 

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.

Post a reply to this message