POV-Ray : Newsgroups : povray.general : Not-so-smooth height_field in POV 3.1 Server Time
5 Nov 2024 09:23:44 EST (-0500)
  Not-so-smooth height_field in POV 3.1 (Message 1 to 10 of 13)  
Goto Latest 10 Messages Next 3 Messages >>>
From: Bob
Subject: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 01:54:35
Message: <375B5E7E.FB6F17EF@aol.com>
Original post is quoted below my reply here.

Heightfields can be made to have no pixelization appear unless the camera
is right near the surface. I gather this is what you are doing though and
of course you would always see the individual "squares" if the camera
either zooms in or is real close no matter what the original resolution
was. Seems a problem of proximity if anything. Basically what you describe
you want to use is further refinement of the resolution or a enhanced
tesselation, ie. more division of the pixels, or more correctly the
vertexes. Since these would originally be flat squares I'm guessing the
production of a HF creates triangles having these as vertex points
instead; meaning a image used to make the HF, if black and white pixels in
a checkerboard pattern, would become a HF of as many peaks and valleys as
there are pixels. So it is feasible I would suppose to subdivide what
exists in some sort of interpolation manner.


Lummox JR wrote:
> 
> I'm using a height field in one of my scenes to simulate sand dunes--a
> nice enough effect, except for a problem I'm having with the diffuse
> reflection off the surface. Some of the triangles face the light source
> a little too directly, no matter where I put it, so that I get marching
> diagonal rows of light spots, shaped like checkerboard squares.
> The "smooth" keyword is present. The image does indeed look worse
> without it.
> Using multiple light sources and area lights does not improve the shiny
> checkerboard effect; if anything, it sometimes makes it worse by
> creating even more rows of light spots, though usually not as noticeable
> as the first row.
> I should mention that because the height field is simulating sand dunes
> from close up, it's scaled to <100,8,100> (as I recall).
> 
> I've played around a lot with the bit depth and size of the height field
> file I'm using. Increasing the resolution just makes the checkerboard
> areas smaller, but they do not go away. Currently I'm using the maximum
> bit depth of 16, with a 1200x1200 height field. The height field is a
> 1.9 MB PNG file, and anything 2400x2400 or larget is not only unwieldly,
> but still produces the same patterns (just a bit smaller).
> 
> With the smooth keyword on, there should be no noticeable light spots
> such as I'm getting, but they're there. I had an idea for preventing
> that.
> Since the smooth keyword seems only semi-effective, why not make it
> possible to use a numeric operator? Equate "true" to 1.0, the default
> value if "smooth" is used, and "false" to 0. Thus, something "smooth
> 5.0" would do even more smoothing, causing much more of a rounded
> appearance, while "smooth "0.5" would produce something more like the
> typical unsmoothed flat look, but with a bit of smoothing near the
> edges.
> 
> Lummox JR

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


Post a reply to this message

From: Ken
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 01:59:48
Message: <375B5D9B.F97C8819@pacbell.net>
Bob wrote:
> 
> Original post is quoted below my reply here.
> 
> Heightfields can be made to have no pixelization appear unless the camera
> is right near the surface. I gather this is what you are doing though and
> of course you would always see the individual "squares" if the camera
> either zooms in or is real close no matter what the original resolution
> was. Seems a problem of proximity if anything. Basically what you describe
> you want to use is further refinement of the resolution or a enhanced
> tesselation, ie. more division of the pixels, or more correctly the
> vertexes. Since these would originally be flat squares I'm guessing the
> production of a HF creates triangles having these as vertex points
> instead; meaning a image used to make the HF, if black and white pixels in
> a checkerboard pattern, would become a HF of as many peaks and valleys as
> there are pixels. So it is feasible I would suppose to subdivide what
> exists in some sort of interpolation manner.
> 

 Personaly I believe some simple adjustments to the finish statement itself
would resolve this problem. If you have a high diffused value specified then
you will of course have some portion of the HF object somewhere sending light
back towards the camera. Back off on the the diffuse value and pick up the
difference with an ambient component. Phong and specular highlights will also
cause this problem to occur. I don't see a need for these with sand though
and if present should be eliminated.


-- 
Ken Tyler

mailto://tylereng@pacbell.net


Post a reply to this message

From: Bob
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 07:03:02
Message: <375BA6C2.5DEA6B16@aol.com>
I've been taking a closer look at what the height field is, from a laymans
point of view anyhow. Please see the post "What is it?" in the p.t.s-f.
group for a little investigative pov script.


Ken wrote:
> 
> Bob wrote:
> >
> > Original post is quoted below my reply here.
> >
> > Heightfields can be made to have no pixelization appear unless the camera
> > is right near the surface. I gather this is what you are doing though and
> > of course you would always see the individual "squares" if the camera
> > either zooms in or is real close no matter what the original resolution
> > was. Seems a problem of proximity if anything. Basically what you describe
> > you want to use is further refinement of the resolution or a enhanced
> > tesselation, ie. more division of the pixels, or more correctly the
> > vertexes. Since these would originally be flat squares I'm guessing the
> > production of a HF creates triangles having these as vertex points
> > instead; meaning a image used to make the HF, if black and white pixels in
> > a checkerboard pattern, would become a HF of as many peaks and valleys as
> > there are pixels. So it is feasible I would suppose to subdivide what
> > exists in some sort of interpolation manner.
> >
> 
>  Personaly I believe some simple adjustments to the finish statement itself
> would resolve this problem. If you have a high diffused value specified then
> you will of course have some portion of the HF object somewhere sending light
> back towards the camera. Back off on the the diffuse value and pick up the
> difference with an ambient component. Phong and specular highlights will also
> cause this problem to occur. I don't see a need for these with sand though
> and if present should be eliminated.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

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


Post a reply to this message

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 13:26:57
Message: <375C0161.4913@aol.com>
Ken wrote:
>  Personaly I believe some simple adjustments to the finish statement itself
> would resolve this problem. If you have a high diffused value specified then
> you will of course have some portion of the HF object somewhere sending light
> back towards the camera. Back off on the the diffuse value and pick up the
> difference with an ambient component. Phong and specular highlights will also
> cause this problem to occur. I don't see a need for these with sand though
> and if present should be eliminated.

One would think that would fix it, but nope, I've tried everything.
Taking out too much of the diffuse value and putting in more ambient
makes the picture worse, because even though it helps with the square
effect, there is no longer any appearance of decent shading on the
dunes. Shading the dunes correctly is important to me; but the
pixelation simply shouldn't be happening at all.
Phong and specular are not used. I did try to alter the brilliance
value, but either I run across the problem above of too little shading,
or else the contrast becomes even greater.

Lummox JR


Post a reply to this message

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 13:38:13
Message: <375C0403.257B@aol.com>
Bob wrote:
> 
> Heightfields can be made to have no pixelization appear unless the camera
> is right near the surface. I gather this is what you are doing though and
> of course you would always see the individual "squares" if the camera
> either zooms in or is real close no matter what the original resolution
> was. Seems a problem of proximity if anything. Basically what you describe
> you want to use is further refinement of the resolution or a enhanced
> tesselation, ie. more division of the pixels, or more correctly the
> vertexes. Since these would originally be flat squares I'm guessing the
> production of a HF creates triangles having these as vertex points
> instead; meaning a image used to make the HF, if black and white pixels in
> a checkerboard pattern, would become a HF of as many peaks and valleys as
> there are pixels. So it is feasible I would suppose to subdivide what
> exists in some sort of interpolation manner.

Yes, the camera is indeed close to the surface. The height field extends
actually a little above the camera, so that the camera is within the
field itself. This is necessary to create the sand dune effect I want.
Even so, it's not proximity that's the *heart* of the problem (though it
is bringing it out, so to speak), but rather the renderer's poor
smoothing options.
The resolution of the height field, as I mentioned before, really isn't
the problem. Going to a larger height field with more resolution only
makes those checkerboard reflective spots smaller, but it by no means
eliminates them. Ideally, if the renderer would itself interpolate the
pixels according to a quadratic function or some such, instead of
relying on a larger height field, I suspect the problem would solve
itself. Using such a method, triangles wouldn't even be needed at all;
the surface itself would be dynamic and rounded.
Low bit depth of the height field was a problem in some early images,
but 12 bits or more per pixel takes care of that; and I'm using 16 now.

Since it seems the simplest way for the renderer to draw a height field
is to produce those triangles, I guess we're stuck with them until some
better option comes along. But as long as we have to live with the
triangles, there needs to be some way of solving this proximity problem.
Those checkerboard reflection patterns *can* be smoothed out with simply
a more aggressive smoothing algorithm, one that can be made to produce
more rounded-looking surfaces, or flatter.
No other type of object I know of will produce the dune effect I want,
or else I'd try it; I may be an algebraphile, but I shudder at the
thought of producing a 7th-order polynomial to fit the bill. Plus, I've
already positioned the other objects within the scene--replacing the
height field at this late date would bring on problems innumerable.

Lummox JR


Post a reply to this message

From: Bob
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 20:43:29
Message: <375C670F.98E4D8C4@aol.com>
Too bad you hadn't tried the iso surface function in Super Patch instead. I haven't
used
it myself but it would have probably been a good replacement.
I'm not in-the-know about HFs at all but from what I can make out about them they are
peculiar it seems. I was guessing all wrong when I said before that maybe they have
peaks and valleys at the white and black pixels (centrally that is), of course they
don't really I suppose, otherwise any single white pixel from the image used would
create a high point within itself. This does not seem to be the case. In fact, I
cannot
really discern what is going on. The test HF I tried out showed several confusing
"faces" to the thing. From one vantage there appeared to be 3 stepped levels of white
and black, and another suggests a double triangle for each pixel. I expected to get
either of two things, a spike and anti spike or a square high plateau and low one.
Even though I'm still not certain I'm now guessing it's a pair of triangles to divide
each pixel, which is strange because how does it get its orientation? Unless its
actually 4 triangles for each, and in that case there should be a central peak (or
vertex at least).


Lummox JR wrote:
> 
> No other type of object I know of will produce the dune effect I want,
> or else I'd try it; I may be an algebraphile, but I shudder at the
> thought of producing a 7th-order polynomial to fit the bill. Plus, I've
> already positioned the other objects within the scene--replacing the
> height field at this late date would bring on problems innumerable.
> 
> Lummox JR

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


Post a reply to this message

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 7 Jun 1999 21:54:05
Message: <375C783C.5090@aol.com>
Bob wrote:
> 
> Too bad you hadn't tried the iso surface function in Super Patch instead. I haven't
used
> it myself but it would have probably been a good replacement.
> I'm not in-the-know about HFs at all but from what I can make out about them they
are
> peculiar it seems. I was guessing all wrong when I said before that maybe they have
> peaks and valleys at the white and black pixels (centrally that is), of course they
> don't really I suppose, otherwise any single white pixel from the image used would
> create a high point within itself. This does not seem to be the case. In fact, I
cannot
> really discern what is going on. The test HF I tried out showed several confusing
> "faces" to the thing. From one vantage there appeared to be 3 stepped levels of
white
> and black, and another suggests a double triangle for each pixel. I expected to get
> either of two things, a spike and anti spike or a square high plateau and low one.
> Even though I'm still not certain I'm now guessing it's a pair of triangles to
divide
> each pixel, which is strange because how does it get its orientation? Unless its
> actually 4 triangles for each, and in that case there should be a central peak (or
> vertex at least).

I believe the orientation is arbitrary, but the height field is indeed
divided into 2 triangles per pixel.

Lummox JR


Post a reply to this message

From: Bob
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 8 Jun 1999 01:10:48
Message: <375CA5B2.D7F905A8@aol.com>
Hmmm, not according to Ron Parker and the POV-Ray Scene help (from what I can make out
of about it). Seems it is 2 triangles per 4 pixels. Of course if you mean that a pixel
is apparently divided in two by a pair of triangles I guess that would be correct.
Please have a look at Rons fine explanation at the p.t.s-f. newsgroup in reply to my
"What is it? HF checkers" post if you haven't already. And actually the POV Help file
does a good job as well, I just fail to understand things easily.


Lummox JR wrote:
> 
> the height field is indeed
> divided into 2 triangles per pixel.
> 
> Lummox JR

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


Post a reply to this message

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 9 Jun 1999 20:11:28
Message: <375F0333.5CA9@aol.com>
Bob wrote:
> 
> Hmmm, not according to Ron Parker and the POV-Ray Scene help (from what I can make
out
> of about it). Seems it is 2 triangles per 4 pixels. Of course if you mean that a
pixel
> is apparently divided in two by a pair of triangles I guess that would be correct.
> Please have a look at Rons fine explanation at the p.t.s-f. newsgroup in reply to my
> "What is it? HF checkers" post if you haven't already. And actually the POV Help
file
> does a good job as well, I just fail to understand things easily.

Well yes, more aptly it's really 2 triangles per 4-pixel group, not per
pixel. But when you consider that all but the edge pixels are part of 4
different groups, for large height fields it's close enough to 2
triangles per pixel as to make little difference.
I thought his mention of the bicubic idea was interesting, but still
more interesting was Peter Popov's response to that, suggesting bicubic
interpolation--similar to what I'd mentioned.


Post a reply to this message

From: Ken
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 9 Jun 1999 20:16:35
Message: <375F011B.B7D9A467@pacbell.net>
Lummox JR wrote:
> 
> Bob wrote:
> >
> > Hmmm, not according to Ron Parker and the POV-Ray Scene help (from what I can make
out
> > of about it). Seems it is 2 triangles per 4 pixels. Of course if you mean that a
pixel
> > is apparently divided in two by a pair of triangles I guess that would be correct.
> > Please have a look at Rons fine explanation at the p.t.s-f. newsgroup in reply to
my
> > "What is it? HF checkers" post if you haven't already. And actually the POV Help
file
> > does a good job as well, I just fail to understand things easily.
> 
> Well yes, more aptly it's really 2 triangles per 4-pixel group, not per
> pixel. But when you consider that all but the edge pixels are part of 4
> different groups, for large height fields it's close enough to 2
> triangles per pixel as to make little difference.
> I thought his mention of the bicubic idea was interesting, but still
> more interesting was Peter Popov's response to that, suggesting bicubic
> interpolation--similar to what I'd mentioned.

I wonder if you might not have some success by applying your HF image to a
plane as an image map with using interpolation and then use use the resulting
image for you HF image. That or try smoothing the image with a blurring or
softening filter in a paint program prior to applying it as a HF object.

-- 
Ken Tyler

mailto://tylereng@pacbell.net


Post a reply to this message

Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.