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

Zeger Knaepen wrote:
> 
> > 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! :)
> 

The normals for all vertices are calculated in 'smooth_height_field()' in
hfield.c, the code in 'HField_Normal()' only interpolates these normals.

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

> The normals for all vertices are calculated in 'smooth_height_field()' in
> hfield.c, the code in 'HField_Normal()' only interpolates these normals.
oh, I see :)

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