Have you ever created a smooth height field with some flat areas? Noticed
how the smoothing around the flat areas, although looking rounded, doesn't
quite look entirely *smooth*? See the image in p.b.i.

I've dealt with this artifact for a while now, so now that I'm looking at
and fiddling with the source code, I took some time to look at it. That was
two days ago. I spent two days searching through the height field normal
functions, trying to find the bug, and in the end concluded that they worked
as they were supposed to. But the artifacts still seemed strange.

Then I noticed something about the smooth triangle normal function: it
doesn't transform the normal after interpolating it. Makes sense, I thought,
since transforms on a simple shape like a triangle can be applied
immediately - no need to transform the ray.

Then I thought, maybe this no-transformation-after-interpolation is a
necessity? So I went into the height field code and transformed the normals
*before* interpolation, and not after. Voila. See the second image in the
thread in p.b.i.

The reason? Height fields are extremely tall objects (internally). They're
65535 units tall by (image width) units wide by (image height) units deep.
The normals are calculated and interpolated between while the height field
is tall like this.

Then the height field is scaled down drastically to fit the unit box. This
has the effect that the normals, after interpolation, are stretched
*vertically* by a whole lot, after which they are normalized. This causes
any vectors that were interpolated between (anything) and <0,1,0> to be
almost always vertical. As a result, triangles near flat areas (where the
normal is <0,1,0>) end up thinking that they're almost entirely flat.

If you don't understand that (it wasn't the best explanation), you should
just remember that transforming normals after interpolation is a bad idea.
It causes some of the normals that were interpolated between to have more
weight than others.

Note that this doesn't fix the grid-like appearance of the height field, but
that's a natural artifact caused by the fact that height fields are, in
fact, grids.

(Oh, by the way: there is also another bug. The normals for the right-most
and up-most rows of triangle vertices aren't calculated (and end up being
<-32767,-32767,-32767> as a result). This was fixed by changing two < signs
to <= to signs in the for loops in the normal calculation function. This bug
normally isn't visible because of the smooth-triangle normal flipping bug
(see the last entry in the FAQ in the documentation).)

Am I making sense? =) See the thread in p.b.i for a graphical display of the
differences.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

> Then I thought, maybe this no-transformation-after-interpolation is a
> necessity? So I went into the height field code and transformed the
normals
> *before* interpolation, and not after.

I should have noted that I also normalized them after transforming and
before interpolating.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3da337e1$1@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:

> Have you ever created a smooth height field with some flat areas? Noticed
> how the smoothing around the flat areas, although looking rounded, doesn't
> quite look entirely *smooth*? See the image in p.b.i.

I agree that the image you show looks much better.  I am not familiar with
the hfield code, so I cannot comment on the correctness of your idea (also
it sounds very reasonable).

Where do I find the source code of your changes?


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Where do I find the source code of your changes?

Heh, it's sitting on my hard drive. I plan on releasing it with other
changes also, later on. But if you want the code for a particular reason
(such as inserting into the official version or something), I can describe
the change here. It's very simple.

(I can't just cut and paste the function's code, I'm afraid, since I also
made some other significant changes to it in the process of figuring out the
problem, so it wouldn't work at all through a direct copy. But it's just one
line commented out and about 6 added.)

If you want it, ask, and I'll post it.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3da35563@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:

> If you want it, ask, and I'll post it.

No need to rush.  I prefer code with little changes in order to be able to
track what was actually changed...

BTW, there is a list at <http://www.povray.org/download/3.5-bugs.php> and as
you seem to have plenty of time (aren't there any midterms at RPI?) .....

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> No need to rush.  I prefer code with little changes in order to be able to
> track what was actually changed...

OK. I don't plan on undoing all the changes, but some of them. If you want
it before I release it, just ask.

> BTW, there is a list at <http://www.povray.org/download/3.5-bugs.php> and
as
> you seem to have plenty of time (aren't there any midterms at RPI?) .....

Oh, you mean like the 4-hour midterm I have tomorrow? Heh heh heh... =)

(How do you know I go to RPI?)

I thought I would work on the triangle mesh 'bugs' described in the FAQ
first. (Actually, working on the normal flipping bug is what brought me to
this one.) Some of those bugs on the known bugs page are pretty obscure, and
I haven't seen them myself. But I'll look into some of them eventually, I'm
sure. I figure that a lot of them will disappear when 4.0 is created,
though.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3da35b36@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:

>> BTW, there is a list at <http://www.povray.org/download/3.5-bugs.php> and
>> as you seem to have plenty of time (aren't there any midterms at RPI?) .....
>
> Oh, you mean like the 4-hour midterm I have tomorrow? Heh heh heh... =)

Well, good luck!  What is your major?

> (How do you know I go to RPI?)

I know, you don't even say on your page :-)  But it is easy to find out.  On
your page (where I looked for the source code) you mentioned a career fair,
so I knew you are at a university.  Then your message header helps a lot,
too...

> NNTP-Posting-Host: 128.113.149.150
> X-Original-NNTP-Posting-Host: 128.113.149.150
> Message-ID: <3da35b36@news.povray.org>

A reverse DNS lookup of the IP 128.113.149.150 yields:
<vaporeon-06.dynamic.rpi.edu>

> I thought I would work on the triangle mesh 'bugs' described in the FAQ
> first. (Actually, working on the normal flipping bug is what brought me to
> this one.) Some of those bugs on the known bugs page are pretty obscure, and
> I haven't seen them myself. But I'll look into some of them eventually, I'm
> sure. I figure that a lot of them will disappear when 4.0 is created,
> though.

At least the blob bug(s) and superellipsoid bug should be possible to find
given enough time ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3da35e1a@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

>> (How do you know I go to RPI?)
>
> I know, you don't even say on your page :-)  But it is easy to find out.  On
> your page (where I looked for the source code) you mentioned a career fair,
> so I knew you are at a university.  Then your message header helps a lot,
> too...
>
>> NNTP-Posting-Host: 128.113.149.150
>> X-Original-NNTP-Posting-Host: 128.113.149.150
>> Message-ID: <3da35b36@news.povray.org>
>
> A reverse DNS lookup of the IP 128.113.149.150 yields:
> <vaporeon-06.dynamic.rpi.edu>

BTW, never underestimate the amount of information that is available online
about you.  I.e. address and name at <http://opensrs.org/cgi-bin/whois.cgi>.

But I won't ask how you had the idea for your nickname, it would be
off-topic... ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Well, good luck!  What is your major?


Electronic Media Arts and Communication. EMAC. But I plan on dualing with
Comp Sci as soon as I finish my Data Structures and Algorithms class.

> > (How do you know I go to RPI?)
>
> I know, you don't even say on your page :-)  But it is easy to find out.
On
> your page (where I looked for the source code) you mentioned a career
fair,
> so I knew you are at a university.  Then your message header helps a lot,
> too...
>
> > NNTP-Posting-Host: 128.113.149.150
> > X-Original-NNTP-Posting-Host: 128.113.149.150
> > Message-ID: <3da35b36@news.povray.org>
>
> A reverse DNS lookup of the IP 128.113.149.150 yields:
> <vaporeon-06.dynamic.rpi.edu>

Haha, I'm glad you didn't go to great lengths to figure this out =)

> BTW, never underestimate the amount of information that is available
online
> about you.  I.e. address and name at
<http://opensrs.org/cgi-bin/whois.cgi>.

Mmm, good point.

> But I won't ask how you had the idea for your nickname, it would be
> off-topic... ;-)

Old NES game, long story =)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

This is cool.
  I have fought with this problem as well, and always thought that it's
probably some mistake in the hf code (since it doesn't happen with smooth
meshes).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message