"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