> This obviously does not change anything, to really judge whether the
> heightfield smoothing is broken would require perfectly identical
> geometry.
I really don't understand what you mean.  These two object have exactly the
same geometry, haven't they?  They are derived from the same pattern, they
have the same shape, the same height, and in this image the same shading,
only the way they are smoothed is different.  If you still don't believe me
this 2 objects have the same shape, maybe I should post an unsmoothed
version, then you'll see they are exactly the same (which they should be),
but with smoothing, they are not (which is not good of course :)

Hmmm, I just rendered this, and they are indeed not exactly the same :)

Oh, I see, I forgot the hf_gray_16 in the height_field.  Here is the
smoothed version *with* the hf_gray_16.  Still rather ugly compared to the
right one, I think.  But this time the unsmoothed version seems to be
exactly the same!

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"Brace yourself for a bit of a shock, Lister, but I just saw you die."

Post a reply to this message

Attachments:
Download 'heightfield3.jpg' (15 KB)

Preview of image 'heightfield3.jpg'

> I'm only after a macro that average normals based on a matrix, like in
> ordinary heightfields. The tricky thing is that the faces can be connected
> in 2 ways, based on what serves the curvature best.. I don't know the
> mathematical names for it.. I call them "quad faces".. Two faces form a
> square, but this can happen in 2 ways.. I use both ways and I need a macro
> to smooth that matrix.. I think, ordinary heightfields also swap the
> quad-faces depending on the curvature..
if that is true, the geometry of my own height_field-like object still isn't
the same as the real height_field.
But, Christoph: *if* it's true what Hugo says here, the results of the real
height_fields should be *better* than those of my own version, which it
clearly isn't.

> If your macro can handle this - please ! ...share it. :o)
> Or if I didn't make myself clear, I can try again.
:)
At the moment there isn't really a macro (yet), but I'll post my code to
p.b.s-f

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"It's my duty; my duty as a complete and utter bastard."

Post a reply to this message

Zeger Knaepen wrote:
> 
> I really don't understand what you mean.  These two object have exactly the
> same geometry, haven't they?  They are derived from the same pattern, they
> have the same shape, the same height, and in this image the same shading,
> only the way they are smoothed is different.  

I would suggest you render a lower resolution version without smoothing so
you can see the single triangles and compare the results. 

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> I would suggest you render a lower resolution version without smoothing so
> you can see the single triangles and compare the results.
Ok, they are not 100% the same.  But close enough.  The smoothed versions
should not be that different.

I made a mistake in my scene.  The height_field had a resolution of 1 less
than the other version.  I fixed it, and now they *really* have the same
geometry, as you can see in the first attached image...  But still, the
smoothed height_field doesn't look as good as it should, as you can see in
the seconde attached image...

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"I want my baby back, baby back, baby back ribs"

Post a reply to this message

Attachments:
Download 'heightfield4.jpg' (19 KB) Download 'heightfield5.jpg' (12 KB)

Preview of image 'heightfield4.jpg'

Preview of image 'heightfield5.jpg'

Zeger Knaepen wrote:
> 
> Ok, they are not 100% the same.  But close enough.  The smoothed versions
> should not be that different.
> 
> I made a mistake in my scene.  The height_field had a resolution of 1 less
> than the other version.  I fixed it, and now they *really* have the same
> geometry, as you can see in the first attached image...  But still, the
> smoothed height_field doesn't look as good as it should, as you can see in
> the seconde attached image...
> 

All right, this seems suited for comparison, it's surely worth having a
look at the heightfield normal calculation code.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Sat, 2 Mar 2002 17:38:38 +0100, "Zeger Knaepen"
<zeg### [at] studentkuleuvenacbe> wrote:

>How does POV-Ray smooth height_fields?  The results aren't really good in
>any case.

What do you expect? It's only a guess at the normals, after all.

>At the left is an ordinary smoothed height_field, at the right the same
>shape using smooth_triangles.

Yeah, and how do you know the normals of those triangles? By
interpolating between vertex positions (which is the only info
available to the hf code) or are you using info from the generating
pattern?

>Wouldn't it be possible to use a better way of smoothing height_fields?

Aside from a different kind of interpolation (higher order), not
really.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

> Yeah, and how do you know the normals of those triangles? By
> interpolating between vertex positions (which is the only info
> available to the hf code) or are you using info from the generating
> pattern?

Zeager posted his code in p.b.s-f
The normals are derived from the vertices.

>>How does POV-Ray smooth height_fields?  The results aren't really good in
>>any case.
>What do you expect? It's only a guess at the normals, after all.

That's true, but a good guess, after all.. The native HF should be able to
look as good as Zeager's IMO.

Regards,
Hugo

Post a reply to this message

<blabla>
> Zeager posted his code in p.b.s-f
<blabla>
> look as good as Zeager's IMO.
Just for the record: my name is Zeger, not Zeager :)

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"Two hits: me hittin' you, you hittin' the floor."

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c80ffa5@news.povray.org...
> How does POV-Ray smooth height_fields?  The results aren't really good in
> any case.

I'm not sure how PoV does it, but it sure runs a lot faster than my
smoothing algorithms. I think that the new height-field macros in shapes.inc
3.5 use a smoothing algorithm more like the one you used. Haven't tried them
yet, though. Anyway, they will write out the vertices so you can do whatever
you like with them.

 -Shay

Post a reply to this message

In article <3c8260ea$1@news.povray.org>, "Shay" <shi### [at] houstonrrcom> 
wrote:

> I'm not sure how PoV does it, but it sure runs a lot faster than my
> smoothing algorithms. I think that the new height-field macros in shapes.inc
> 3.5 use a smoothing algorithm more like the one you used. Haven't tried them
> yet, though. Anyway, they will write out the vertices so you can do whatever
> you like with them.

The macros don't do any sort of normal averaging at all. The method I 
used is actually closer to that used for normal perturbation in 
textures, the  macros sample the function used to generate the height 
field to determine the normal. This might apply to image-based height 
fields as well, if interpolation is used, but I haven't tested it.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message