How does POV-Ray smooth height_fields?  The results aren't really good in
any case.
At the left is an ordinary smoothed height_field, at the right the same
shape using smooth_triangles.
Wouldn't it be possible to use a better way of smoothing height_fields?  As
it is now, the smooth-keyword in height_fields isn't really useful...

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"You know what they say: No good deed goes unpunished."

Post a reply to this message

Attachments:
Download 'heightfield.jpg' (16 KB)

Preview of image 'heightfield.jpg'

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

I'm surprised the left result is so bad. But how did you make the right one?
Probably the difference is that more normals are averaged.

But you see, I'm really *fighting* with a macro to calc normals to a
triangle heightfield.. It's crazy, I code as "clean" as I can, and week
after week I return to my code to find the bugs, but ...argh... I know how
to calculate the normal of a triangle, but my macro construct the
heightfield in a (better) way that means, sometimes there are 3, 4, 5 or 6
faces connected to a vertex.

Any help will be appriciated!  It's a macro that I think would be generally
useful to many people.

Regards,
Hugo

Post a reply to this message

Zeger Knaepen wrote:
> 
> How does POV-Ray smooth height_fields?  The results aren't really good in
> any case.
> At the left is an ordinary smoothed height_field, at the right the same
> shape using smooth_triangles.
> Wouldn't it be possible to use a better way of smoothing height_fields?  As
> it is now, the smooth-keyword in height_fields isn't really useful...

I can't say for sure of course, but those two shapes really don't seem to
have the same geometry to me.  

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 can't say for sure of course, but those two shapes really don't seem to
> have the same geometry to me.
Believe me, they have :)

They're both the bozo-pattern on the xz-plane from x=0 to 1 and z=0 to 1.

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"The only thing that helps me maintain my slender grip on reality is the
friendship I share with my collection of singing potatoes."

Post a reply to this message

> I'm surprised the left result is so bad.
so am I...

> But how did you make the right one?
2 while loops.  The first one calculates a matrix of locations based on the
bozo-pattern, which is then used in the second loop to place triangles and
calculate normals.

> Probably the difference is that more normals are averaged.
maybe, but it almost looks like it just runs a smooth-filter on the final
image.  You can still see the edges of the triangles, but they're blurry.
Actually an interesting effect, but rather useless imho.

> But you see, I'm really *fighting* with a macro to calc normals to a
> triangle heightfield.. It's crazy, I code as "clean" as I can, and week
> after week I return to my code to find the bugs, but ...argh... I know how
> to calculate the normal of a triangle, but my macro construct the
> heightfield in a (better) way that means, sometimes there are 3, 4, 5 or 6
> faces connected to a vertex.
>
> Any help will be appriciated!  It's a macro that I think would be
generally
> useful to many people.
This is how I did it, but I don't think it would be of much help.  To
calculate the normal of one point of a triangle, I average the normals of
every triangle that shares that point.  It's easy to know which triangles
share that point in a simple matrix of triangles, but I'm not sure how you
would do it with what you're doing...

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"If you could see what I've seen with your eyes."

Post a reply to this message

Zeger Knaepen wrote:
> 
> > I can't say for sure of course, but those two shapes really don't seem to
> > have the same geometry to me.
> Believe me, they have :)
> 
> They're both the bozo-pattern on the xz-plane from x=0 to 1 and z=0 to 1.
> 

That's not what i meant, the triangle vertices need to be the same for
comparable 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

> That's not what i meant, the triangle vertices need to be the same for
> comparable results.
Maybe it's easier to compare this way: I mirrored one of them and moved the
light.

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"we will make spears twice as long as a man, but some men are longer than
others"

Post a reply to this message

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

Preview of image 'heightfield2.jpg'

I don't think that it's practical to write a smoothing macro for all meshes,
although I think Warp did one. The calculations just take too long and
require that the user construct specific types of arrays to put into the
macro(at least coding it in PoV.) It's so much faster to just create a
little algorithm for whatever case on which you happen to be working.

 -Shay

"Hugo" <hua### [at] post3teledk> wrote in message
news:3c8105e5@news.povray.org...

Post a reply to this message

> > Any help will be appriciated!  It's a macro that I think would be
> generally
> > useful to many people.
> This is how I did it, but I don't think it would be of much help.  To
> calculate the normal of one point of a triangle, I average the normals of
> every triangle that shares that point.  It's easy to know which triangles
> share that point in a simple matrix of triangles, but I'm not sure how you
> would do it with what you're doing...

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 your macro can handle this - please ! ...share it. :o)
Or if I didn't make myself clear, I can try again.

Regards,
Hugo

Post a reply to this message

Zeger Knaepen wrote:
> 
> > That's not what i meant, the triangle vertices need to be the same for
> > comparable results.
> Maybe it's easier to compare this way: I mirrored one of them and moved the
> light.
> 

This obviously does not change anything, to really judge whether the
heightfield smoothing is broken would require perfectly identical
geometry.

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

> 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

"Christopher James Huff" <chr### [at] maccom> wrote
>
> 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.
>

Its a bit late at night for me but do I understand that I could use
trace() on a vertex and use the returned normal as an average for all
other triangles in a mesh sharing that vertex? I'm referring to
MegaPov, not 3.5 and just starting to play with generating triangles
for the first time.

Alf

Post a reply to this message

In article <3c82b7fd@news.povray.org>,
 "Alf Peake" <alf### [at] peake42freeservecouk> wrote:

> Its a bit late at night for me but do I understand that I could use
> trace() on a vertex and use the returned normal as an average for all
> other triangles in a mesh sharing that vertex? I'm referring to
> MegaPov, not 3.5 and just starting to play with generating triangles
> for the first time.

I'm not sure what you mean here...if you trace a ray directly at a 
vertex of a mesh, there is no way to predict which triangle it will hit. 
POV certainly won't pick all the possible triangles and average their 
normals for you. If the mesh is non-smooth, the returned normal will be 
the normal of any one of the adjacent triangles. You have to compute a 
normal yourself. The POV 3.5 macros can do it accurately because they 
have access to the geometry of the surface around each vertex, not just 
the vertices. Averaging the normals of the triangles around the point 
usualy produces acceptable results as well, but trace() won't be very 
useful for this.

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

On Sun, 3 Mar 2002 10:54:44 +0100, "Hugo" <hua### [at] post3teledk> wrote:

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

I haven't had the time to look there, sorry. I'll trust you on this
one :)

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

Ditto, but I fear it is too late for such deep changes in the 3.5
code.

Having it as a macro in the distro could be useful, though.


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

Post a reply to this message

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

>Ditto, but I fear it is too late for such deep changes in the 3.5
>code.

But maybe it should be considered a bug.. There has been other recent
discussions about heightfields and several people have noticed strange
phenomenes like this.. I think we all agree it looks wrong.. I don't know
how complex the sourcecode is but Zeger's is only a few lines.. It's
probably more complex in C, but a bug like this shoudn't really be able to
hide for more than an evening or two.. imho.. (though I'm not skilled in C.)

Regards,
Hugo

Post a reply to this message

In article <npi78us6q6d2j26cb36bas87g60s17hhhv@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> >That's true, but a good guess, after all.. The native HF should be able to
> >look as good as Zeager's IMO.
> 
> Ditto, but I fear it is too late for such deep changes in the 3.5
> code.

I think it would depend on how hard it is to find and fix. It would be a 
bug fix, not a new feature...


> Having it as a macro in the distro could be useful, though.

Um, have you looked? The HF_Square() macro in shapes.inc doesn't use 
this method, but it should give better results, especially when using 
entirely procedural height fields.

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

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c82b7fd@news.povray.org>,
>  "Alf Peake" <alf### [at] peake42freeservecouk> wrote:
>
> > Its a bit late at night for me but do I understand that I could
use
> > trace() on a vertex and use the returned normal as an average for
all
> > other triangles in a mesh sharing that vertex? I'm referring to
> > MegaPov, not 3.5 and just starting to play with generating
triangles
> > for the first time.
>
> I'm not sure what you mean here...if you trace a ray directly at a
> vertex of a mesh, there is no way to predict which triangle it will
hit.
> POV certainly won't pick all the possible triangles and average
their
> normals for you. If the mesh is non-smooth, the returned normal will
be
> the normal of any one of the adjacent triangles. You have to compute
a

I'm trying to convert a non-rendered object, blueprints, but with with
known points on the surface. Inventing the wheel. At least I'll
understand the script ;-)  I was trying to figure ways to calculate
the average normal for smoothing.

Your comment made me think that after storing each _unique_ vertex in
an array indexed by the triangle's number I could use trace with each
vertex. It only needs to be used once per vertex and will cover all
triangles sharing that vertex.

#declare Average_Norm = <0,0,0>;
#declare Temp = trace( Object, Vertex*2, -Vertex, Average_Norm );

<wimper> Ahhh! The light dawns - I need Object in the first place. I
don't have it :( Excuse me while I arrange a brain transplant.
</wimper>

Alf

Post a reply to this message

> I think it would depend on how hard it is to find and fix. It would be a
> bug fix, not a new feature...
FYI: the image was rendered with POVMan, but I don't think the height_field
code has changed in POV3.5, so it would give the same problems.

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local
C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local
C=C+1
;#end#end
L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK
http://www.povplace.be.tf

Post a reply to this message

On Mon, 04 Mar 2002 17:06:31 -0500, Christopher James Huff
<chr### [at] maccom> wrote:

>Um, have you looked? The HF_Square() macro in shapes.inc doesn't use 
>this method, but it should give better results, especially when using 
>entirely procedural height fields.

Yeah, with a procedural it makes sense to produce better results. And
maybe no one thought of using it with an image as a source :)

I'll have to check whether it looks better with that macro using an
image as a source, with interpolation, of course. Just not today...


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

Post a reply to this message

Christopher James Huff wrote:
> 
> [...]
> >
> > Ditto, but I fear it is too late for such deep changes in the 3.5
> > code.
> 
> I think it would depend on how hard it is to find and fix. It would be a
> bug fix, not a new feature...
> 

I just had a look at the 3.1/megapov source and found there is some change
in megapov supplying new interpolation routines, but it isn't activated
(HField->smooth_type is always 1)

The normal calculation code seems fairly understandable although i don't
have time to check it right now.

BTW, i wonder how much slower it would be not to store the normals and
calculate them from the vertices during trace.  This could save a lot of
space when dealing with large heightfields.

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

> BTW, i wonder how much slower it would be not to store the normals and
> calculate them from the vertices during trace.  This could save a lot of
> space when dealing with large heightfields.
Actually, after a quick look at the code, I had the idea that that's how it's
done now...
But it was a *very* quick look! :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Zeger Knaepen wrote:
> 
> > BTW, i wonder how much slower it would be not to store the normals and
> > calculate them from the vertices during trace.  This could save a lot of
> > space when dealing with large heightfields.
> Actually, after a quick look at the code, I had the idea that that's how it's
> done now...
> But it was a *very* quick look! :)
> 

The normals for all vertices are calculated in 'smooth_height_field()' in
hfield.c, the code in 'HField_Normal()' only interpolates these normals.

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

> The normals for all vertices are calculated in 'smooth_height_field()' in
> hfield.c, the code in 'HField_Normal()' only interpolates these normals.
oh, I see :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message