 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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] student kuleuven ac be> 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] vip bg
TAG e-mail : pet### [at] tag povray org
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] student kuleuven ac be> 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] houston rr com>
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] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Christopher James Huff" <chr### [at] mac com> 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] peake42 freeserve co uk> 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] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |