POV-Ray : Newsgroups : povray.general : Not-so-smooth height_field in POV 3.1 Server Time
11 Aug 2024 21:18:44 EDT (-0400)
  Not-so-smooth height_field in POV 3.1 (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
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

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 11 Jun 1999 16:11:38
Message: <37616DFE.7BD6@aol.com>
Ken wrote:
> 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.

Ah, but all these solutions get us back to the same problem: Some
triangles will still face the light source, so the undesired diffuse
reflection effect will still happen. And again, increasing the
resolution of the height field does nothing but make those reflective
spots a little smaller, and slow down the render--it doesn't eliminate
them.

Lummox JR


Post a reply to this message

From: Ken
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 11 Jun 1999 20:11:36
Message: <3761A2F5.BB04D98F@pacbell.net>
Lummox JR wrote:
> 
> Ken wrote:
> > 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.
> 
> Ah, but all these solutions get us back to the same problem: Some
> triangles will still face the light source, so the undesired diffuse
> reflection effect will still happen. And again, increasing the
> resolution of the height field does nothing but make those reflective
> spots a little smaller, and slow down the render--it doesn't eliminate
> them.
> 
> Lummox JR

 Then I am forced to reply that if the results you are recieving with
your current scene elements are unacceptabel change them until they
are. Try changing the location of your light sources or change the
finish statement.

-- 
Ken Tyler

mailto://tylereng@pacbell.net


Post a reply to this message

From: Lummox JR
Subject: Re: Not-so-smooth height_field in POV 3.1
Date: 13 Jun 1999 01:51:47
Message: <3763477C.419@aol.com>
Ken wrote:
>  Then I am forced to reply that if the results you are recieving with
> your current scene elements are unacceptabel change them until they
> are. Try changing the location of your light sources or change the
> finish statement.

Been there, done that. Light source changes do nothing except move the
light spots to a different area, and the finish statement can do nothing
to improve the smoothing.
The entire core of the problem is that the engine is not doing *enough*
smoothing toward the corners and edges of each triangle, and as far as I
understand the concept, it should be a trivial matter (for the authors)
to modify the smoothing function to supply a single value that controls
the degree of smoothing.

Lummox JR


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

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