Normally, the triangles in each "square" of a height field are always the
lower left and upper right of the square. I've implemented a
"smart_triangulation" keyword which makes POV-Ray choose which way to
triangulate the squares better, often creating a smoother result. An example
of both methods is attached to this post. When used with the smooth height
field bug fix and my shadow line fix, this creates an extremely smooth
height field.

I *think* there's only one more feature that I want to attempt before I
release this.

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

Post a reply to this message

Attachments:
Download 'height_field_normal_triangulation.jpg' (47 KB) Download 'height_field_smart_triangulation.jpg' (44 KB)

Preview of image 'height_field_normal_triangulation.jpg'

Preview of image 'height_field_smart_triangulation.jpg'

> When used with the smooth height
> field bug fix and my shadow line fix, this creates an extremely smooth
> height field.

Like this. (I admit I slightly changed a small part of the height field that
was casting an ugly tiny shadow on itself.)

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

Post a reply to this message

Attachments:
Download 'smooth_hf_final.jpg' (30 KB)

Preview of image 'smooth_hf_final.jpg'

> smooth [0|1|2]


Heh, actually, I've already used this syntax to let the user choose between
POV-Ray 3.5's normal calculation (1) and a different type of normal
calculation that I came up with (2) which tends to look better overall.
(POV-Ray bases the normal of a vertex on the vertices diagonally across from
it; I base it off of the vertices adjacent to it.)

I thought of making this related to the 'smooth' keyword, but it probably
shouldn't be, IMO, since it's possible to use it without actually smoothing
anything.

> Since you are working on heightfields: One thing i wanted to try for some
> time (but what could possibly be quite difficult) is changing the
> heightfield code to calculate the normal vectors on the fly and not store
> them.  This would reduce memory use quite a lot and could therefore be
> useful for very large heightfields.

Hmm... not a bad idea. Syntax suggestions? *This* could be a part of the
smooth keyword... maybe

smooth [int[, int]]

the first int beging the smoothing type, and the second being the normal
calculation type.

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

Post a reply to this message

> I've implemented a "smart_triangulation" keyword
> which makes POV-Ray choose which way to
> triangulate the squares better

Oohh, you took my idea there.  ;o)  I did this in SDL a few months ago,
remember?  Very nice to see this will soon become native part of POV.

Thanks,
Hugo

Post a reply to this message

> Oohh, you took my idea there.  ;o)  I did this in SDL a few months ago,
> remember?  Very nice to see this will soon become native part of POV.


Was that you? =) I think I was simultaneously making my own mesh height
field function with the same feature, but after realizing that it was much,
much slower than the native height field code, I gave it up.

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

Post a reply to this message

"Slime" <slm### [at] slimelandcom> schreef in bericht
news:3db1c5c9@news.povray.org...
> > When used with the smooth height
> > field bug fix and my shadow line fix, this creates an extremely smooth
> > height field.
> Like this. (I admit I slightly changed a small part of the height field
that
> was casting an ugly tiny shadow on itself.)

Sorry, not good enough...  Look at my post a couple of months ago, where I
compare smooth height_fields with a mesh of smooth_triangles.  With a
height_field, you can still see the outline of the triangles, it looks like
the shading gets smoothed instead of the normals... it's hard to explain,
but I think it's pretty clear if you look at the images I posted.  (I would
look the post up

Don't get me wrong, I do appreciate your efforts in making the height_field
object better, but I would just really like that problem fixed.

cu!

whoops, update:

you wrote, in a reply to Christoph Hormann:
"Heh, actually, I've already used this syntax to let the user choose between
POV-Ray 3.5's normal calculation (1) and a different type of normal
calculation that I came up with (2) which tends to look better overall.
(POV-Ray bases the normal of a vertex on the vertices diagonally across from
it; I base it off of the vertices adjacent to it.)"

I think that's what I talking about.
If so: whoohoo!!!!!!!  Finally height_fields will be really useful!! :)
If not: :(((((
:)

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"Surely you've heard of silicon heaven?"

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in news:3db1c5c9@news.povray.org

Very nice :)
Keep up good work :)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

> > (POV-Ray bases the normal of a vertex on the vertices diagonally across
from
> > it; I base it off of the vertices adjacent to it.)"
> I think that's what I talking about.


It might be. While I base the normals off of the adjacent vertices in smooth
type 2, the normal interpolation is still done in squares. That is, with a
smooth mesh, the normals of each triangle are interpolated between on that
triangle. With a smooth height field, the normals of every *pair* of
triangles are interpolated between. This somewhat creates a grid effect.
However, I did originally attempt to make it look more like a smooth mesh,
and decided in the end that the height field interpolation type actually
looked better. It works slightly differently, but in the end I think it
produces a smoother looking result.

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

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3db1c90b$1@news.povray.org...
> > smooth [0|1|2]
>
>
> Heh, actually, I've already used this syntax to let the user choose
between
> POV-Ray 3.5's normal calculation (1) and a different type of normal
> calculation that I came up with (2) which tends to look better overall.
> (POV-Ray bases the normal of a vertex on the vertices diagonally across
from
> it; I base it off of the vertices adjacent to it.)
>
> I thought of making this related to the 'smooth' keyword, but it probably
> shouldn't be, IMO, since it's possible to use it without actually
smoothing
> anything.
>
> > Since you are working on heightfields: One thing i wanted to try for
some
> > time (but what could possibly be quite difficult) is changing the
> > heightfield code to calculate the normal vectors on the fly and not
store
> > them.  This would reduce memory use quite a lot and could therefore be
> > useful for very large heightfields.
>
> Hmm... not a bad idea. Syntax suggestions? *This* could be a part of the
> smooth keyword... maybe
>
> smooth [int[, int]]
>
> the first int beging the smoothing type, and the second being the normal
> calculation type.
>

I think an additional keyword would be better.  For some reason, someone may
want your triangulation method *without* having the HF smooth.

-tgq

Post a reply to this message

> > smooth [int[, int]]
> >
> > the first int beging the smoothing type, and the second being the normal
> > calculation type.
> >
>
> I think an additional keyword would be better.  For some reason, someone
may
> want your triangulation method *without* having the HF smooth.


I agree. The smooth[int[,int]] thing I suggested was for the possibility of
not precalculating normals, which would only occur in the case of a smooth
height field. For the triangulation feature, I've implemented a separate
keyword.

Maybe you knew that already and were just agreeing with me. Heh =)

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

Post a reply to this message