 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Another example of an object very similar to a height field which is
capable of nice vertical edges. This time I left the wire frame off to
show how nice the normals can look without the stretched triangles of a
true height field. The mesh is low resolution, so the triangle lighting
issue is very visible (I need to download SlimePov), but the normals are
still accurate. The true height field is on the left. My variant is on
the right. Both use the same function and contain roughly the same
number of vertices.
-Shay
Post a reply to this message
Attachments:
Download 'comparesmooth.jpg' (11 KB)
Preview of image 'comparesmooth.jpg'
|
|
| |
| |
|
|
From: Andrew Wilcox
Subject: Re: Heightfield with rounded and diagonal objects.
Date: 11 Jun 2003 16:21:58
Message: <3ee78f66$1@news.povray.org>
|
|
|
| |
| |
|
|
Well that, is interesting.
Could it still do a mountain?
Andrew Wilcox
Post a reply to this message
|
|
| |
| |
|
|
From: Zeger Knaepen
Subject: Re: Heightfield with rounded and diagonal objects.
Date: 11 Jun 2003 16:50:33
Message: <3ee79619$1@news.povray.org>
|
|
|
| |
| |
|
|
This looks very interesting. How does it know when an edge is supposed to be
vertical? Some threshold value or something like that?
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
|
|
| |
| |
|
|
From: Shay
Subject: Re: Heightfield with rounded and diagonal objects.
Date: 11 Jun 2003 16:53:42
Message: <3ee796d6@news.povray.org>
|
|
|
| |
| |
|
|
"Andrew Wilcox" <awi### [at] unpuzzled com> wrote in message
news:3ee78f66$1@news.povray.org...
| Well that, is interesting.
|
| Could it still do a mountain?
|
|
Yes. It could even do a *SHINY* mountain. Or even better, a TRANSPARENT,
MEDIA-FILLED mountain!!!!!!!
OMFG!!! SQUIRT SQUIRT SQUIRT!!!!
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3ee79619$1@news.povray.org...
| This looks very interesting.
Thank you.
| How does it know when an edge
| is supposed to be vertical? Some threshold
| value or something like that?
|
Yes, The value used here is a change in height greater than the width of
a square. This would allow for something like a craggy stone area with a
castle tower protruding. Of course, there are better ways to do that.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
From: Ace
Subject: Re: Heightfield with rounded and diagonal objects.
Date: 12 Jun 2003 03:58:26
Message: <3ee832a2@news.povray.org>
|
|
|
| |
| |
|
|
"Shay" <sah### [at] simcopartscom> wrote in message
news:3ee796d6@news.povray.org...
>
> "Andrew Wilcox" <awi### [at] unpuzzledcom> wrote in message
> news:3ee78f66$1@news.povray.org...
> | Well that, is interesting.
> |
> | Could it still do a mountain?
> |
> |
>
> Yes. It could even do a *SHINY* mountain. Or even better, a TRANSPARENT,
> MEDIA-FILLED mountain!!!!!!!
> OMFG!!! SQUIRT SQUIRT SQUIRT!!!!
>
> -Shay
>
>
Realy? OK now I think its interesting. :-)
Gary
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wohoo! :o)
POV means now Progress - Of - Vision. I love it!
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, I have a question: Does this work with an image_map as source for your
heightfield? You mention that you're using a function, i.e. the resolution
is infinite.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Another example of an object very similar to a height
> field which is capable of nice vertical edges.
This sure is interesting. At first when I saw it I was completely mystified
how your algorithm could make the vertical edges so perfect, since I'd
think it be roughly as difficult as creating vector graphics from bitmaps,
which is certainly not trivial. However, if (which is still not completely
clear to me) the HF take a function as base, and not a bitmap, then this is
a completely different matter, and much easier to understand. Still
impressive though.
Rune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] runevisioncom> wrote in message
news:web.3ee8f43bb3d14fcd32619ff80@news.povray.org...
Thanks to both of you. Huge, the smooth parts of my macro do use the
selective quad splitting which you introduced on this board.
The reason I called this a height-field is that it does work like one. A
function, a bitmap, traced rays, whatever could be used to generate the
data. A bitmap is of course really only a group of squares, so as the
resolution of the mesh got closer and closer to the resolution of the
bitmap, this fact would become more and more apparent, just like any
bitmap.
It would be straight forward, however, to code in corrections for bitmap
jaggedness. The macro can easily keep track of the borders between
distinct objects and could be made to smooth out those borders without
any difficulty. I'm done working on this, however, as I coded it in
order to make a picture, and the macro can already do everything I need
it to do. The picture is actually similar in appearance to the first
example I posted.
That example is actually much more sophisticated than the second. The
reason is that the second example gets only data from the function, the
first example, however, takes into account my human knowledge about the
shape of the elements. This allows the macro to assume things about the
shape of the mesh, even when it does not have information about small
details. In exact terms for this example, that means that the macro
knows to expect corners between areas of changes in height. Even when
the function in not sampled directly on a corner, the macro knows that
the corner should be there and builds that corner.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
