My understanding has been that a degenerate triangle is
just three points that don't really make a triangle.
Could someone please explain why POV-Ray complains that
the following smooth_triangle is "degenerate"? (v1,v2, and v3
come out fine as a plain 'flat' triangle).

#declare v1=<116.50351, 37.28418, -14.46650>;
#declare n1=<-0.87727, -0.19526, 0.43849>;
#declare v2=<73.18535, 44.36221, -1.11751>;
#declare n2=<-0.90956, 0.27350, 0.31289>;
#declare v3=<123.66611, 65.86183, 12.58927>;
#declare n3=<-0.8777, -0.19526, 0.43849>;

smooth_triangle{
	v1,n1,
	v2,n2,
	v3,n3     
}

Thanks for any help.

Post a reply to this message

My understanding was that it was a duplicate triangle... in other words,
there is already one in the scene with the same co-ords.  But I could be
wrong.

I think there was a thread about it a few months back... on how to get rid
of them...

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch wrote:
> 
> My understanding was that it was a duplicate triangle... in other words,
> there is already one in the scene with the same co-ords.  But I could be
> wrong.

Well, I would believe this about duplicates except that POV is telling
me
that just that one triangle by itself is degenerate. 

> I think there was a thread about it a few months back... on how to get rid
> of them...

Thanks. I will have to try and find it.

Post a reply to this message

Hmm, interesting... Maybe it's a problem with the computed normal for the
triangle.

Anyone else got any ideas?

"Ken will know"

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch wrote:
> 
> Hmm, interesting... Maybe it's a problem with the computed normal for the
> triangle.
> Anyone else got any ideas?
> "Ken will know"

  It probably has something to do with the way it's parents raised it. 

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

A degenerate triangle is usually one where at least two of the points
are the same (so you get a line or a point instead of a triangle).
This particular triangle works just fine with POV 3.1 for me.

If you accidently typed something like:
smooth_triangle{
         v1,n1,
         v2,n2,
         v2,n3  // note this line
 }

then it would be degenerate.

-Nathan

david sharp wrote:
> 
> My understanding has been that a degenerate triangle is
> just three points that don't really make a triangle.
> Could someone please explain why POV-Ray complains that
> the following smooth_triangle is "degenerate"? (v1,v2, and v3
> come out fine as a plain 'flat' triangle).
> 
> #declare v1=<116.50351, 37.28418, -14.46650>;
> #declare n1=<-0.87727, -0.19526, 0.43849>;
> #declare v2=<73.18535, 44.36221, -1.11751>;
> #declare n2=<-0.90956, 0.27350, 0.31289>;
> #declare v3=<123.66611, 65.86183, 12.58927>;
> #declare n3=<-0.8777, -0.19526, 0.43849>;
> 
> smooth_triangle{
>         v1,n1,
>         v2,n2,
>         v3,n3
> }
> 
> Thanks for any help.

Post a reply to this message

he he he

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Ken wrote:
>> It probably has something to do with the way it's parents raised it.

  It cross-dresses as a primitive. Looks kinda cute, actually <g>.

- Alan

Post a reply to this message

Nathan Kopp wrote:
 
[ ... ]
> This particular triangle works just fine with POV 3.1 for me.

As a smooth_triangle?
I am using 3.1d, DOS version, and that smooth_triangle is
reported degenerate. The points and normals are generated by 
macros and if I at least knew why it was degenerate (or being
reported as such) I could do automate some 'detect and correct', 
like substituting a 'flat' triangle (which works fine with 
those coordinates). 

> If you accidently typed something like:
> smooth_triangle{
>        v1,n1,
>         v2,n2,
>         v2,n3  // note this line
> }

Well, in my case, this is actually the most likely cause, 
but I cutnpasted directly from the source.

Post a reply to this message

Using POV version 3.1d for DOS, this triangle is not 
reported as degenerate as part of a mesh{}, but it 
is reported degenerate if declared by itself or as 
part of a union{}. However the triangle is not 
rendered properly in any of these (in a mesh, by itself, 
or in a union).
By making random changes in the normals, sometimes I can get 
it rendered, but what changes in the normals is allowing it 
to be rendered is a mystery to me. Some changes work, and 
some don't.

If it is declared as a plain triangle 
	triangle{v1,v2,v3}
then it is rendered ok.

david sharp wrote:
> #declare v1=<116.50351, 37.28418, -14.46650>;
> #declare n1=<-0.87727, -0.19526, 0.43849>;
> #declare v2=<73.18535, 44.36221, -1.11751>;
> #declare n2=<-0.90956, 0.27350, 0.31289>;
> #declare v3=<123.66611, 65.86183, 12.58927>;
> #declare n3=<-0.8777, -0.19526, 0.43849>;
> 
> smooth_triangle{
>         v1,n1,
>         v2,n2,
>         v3,n3     
> }

Post a reply to this message

I think I know what's the problem.
  Render the following scene:

#declare v1=<116.50351, 37.28418, -14.46650>;
#declare n1=<-0.87727, -0.19526, 0.43849>;
#declare v2=<73.18535, 44.36221, -1.11751>;
#declare n2=<-0.90956, 0.27350, 0.31289>;
#declare v3=<123.66611, 65.86183, 12.58927>;
#declare n3=<-0.8777, -0.19526, 0.43849>;

triangle { v1,v2,v3 pigment { rgb z } }
sphere { v1,1 pigment { rgb x } }
sphere { v2,1 pigment { rgb x } }
sphere { v3,1 pigment { rgb x } }
cylinder { v1,v2,.5 pigment { rgb y } }
cylinder { v2,v3,.5 pigment { rgb y } }
cylinder { v3,v1,.5 pigment { rgb y } }
cylinder { v1,v1+n1*50,.5 pigment { rgb x+y } }
cylinder { v2,v2+n2*50,.5 pigment { rgb x+y } }
cylinder { v3,v3+n3*50,.5 pigment { rgb x+y } }

#declare CamLookat=(v1+v2+v3)/3;
#declare CamPos=CamLookat+x*100-z*25;
camera { location CamPos look_at CamLookat angle 35 }
light_source { <1000,1000,-1000> 1 }
light_source { <0,0,1000> 1 }

  The vertices of the triangle are red spheres, the edges green cylinders
and the normals yellow cylinders (and the interior of the triangle is blue).
  You can see from the image, that two of the normals are pointing to one
side of the triangle while the third is pointing to the other side. This may
be causing the problem. I think that all the normals have to be pointing to
the same side of the triangle.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

david sharp wrote:
> 
> Well, in my case, this is actually the most likely cause,
> but I cutnpasted directly from the source.

Hmmm... that's odd since I cut and pasted from your previous post and
it worked.  I tried it with 3.1a official and my latest compile of
UVPov and both worked just fine (is 3.1d broken here?).

-Nathan

Post a reply to this message

Nieminen Mika wrote:

[ ... ]
>   You can see from the image, that two of the normals are pointing to one
> side of the triangle while the third is pointing to the other side. This may
> be causing the problem. I think that all the normals have to be pointing to
> the same side of the triangle.

I will have to experiment with this, but that particular triangle
came from a list of thousands where I am pretty sure that are other 
places where the normals reverse from one end of a triangle to another
(but maybe not! I have to check), and all but that one rendered nicely.

Post a reply to this message

Nieminen Mika wrote:
>   You can see from the image, that two of the normals are pointing to one
> side of the triangle while the third is pointing to the other side. This may
> be causing the problem. I think that all the normals have to be pointing to
> the same side of the triangle.

This, in fact, seems to be, or was, the problem. That triangle was 
the only one,  of thousands, where the normals were reversed from 
one corner of the triangle to another, and it was the only triangle 
POV was not accepting. This is easy enough to detect and work around.

Thank you very much for your efforts and insights.

Now, my question is why does POV-Ray do that? What is wrong with
one normal pointing 'up' while two point 'down' (or vice versa)?

Post a reply to this message

david sharp wrote:
> 
> Nieminen Mika wrote:
> >   You can see from the image, that two of the normals are pointing to one
> > side of the triangle while the third is pointing to the other side. This may
> > be causing the problem. I think that all the normals have to be pointing to
> > the same side of the triangle.
> 
> This, in fact, seems to be, or was, the problem. That triangle was
> the only one,  of thousands, where the normals were reversed from
> one corner of the triangle to another, and it was the only triangle
> POV was not accepting. This is easy enough to detect and work around.
> 
> Thank you very much for your efforts and insights.
> 
> Now, my question is why does POV-Ray do that? What is wrong with
> one normal pointing 'up' while two point 'down' (or vice versa)?

  In effect you are twisting it into a fourth demension when you have
 two normals pointing in the opposite direction of each other on one
 object.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote:
> 
> david sharp wrote:
> >
[ ... ]
> > Now, my question is why does POV-Ray do that? What is wrong with
> > one normal pointing 'up' while two point 'down' (or vice versa)?
> 
>   In effect you are twisting it into a fourth demension when you have
>  two normals pointing in the opposite direction of each other on one
>  object.
> 

fourth dimension?
a ball doesn't have to twist into a fourth dimension to have
normals pointing in *every* direction.  

Since Nathan Kopp posted that at least that one triangle was OK with
POV-Ray 3.1a, I find this still mysterious.

Post a reply to this message

It does seem strange to me as well. In the particle system I am working on,
I'm using smooth triangles as the particles. I calculate normals that point
at 90 degrees to the average normal of the triangle. These normals are
parallel to the surface and have had no error mesages like this.

Any programmer types who get into the POV code care to explain in detail?

Thanks
Gordon

david sharp wrote in message <36F### [at] interportnet>...
>Ken wrote:
>>
>> david sharp wrote:
>> >
>[ ... ]
>> > Now, my question is why does POV-Ray do that? What is wrong with
>> > one normal pointing 'up' while two point 'down' (or vice versa)?
>>
>>   In effect you are twisting it into a fourth demension when you have
>>  two normals pointing in the opposite direction of each other on one
>>  object.
>>
>
>fourth dimension?
>a ball doesn't have to twist into a fourth dimension to have
>normals pointing in *every* direction.
>
>Since Nathan Kopp posted that at least that one triangle was OK with
>POV-Ray 3.1a, I find this still mysterious.

Post a reply to this message

I'm not a programmer type and I might be wrong, but there seems to be a
problem of ambiguity. This is how I envision it: the normals of a smooth
triangle are calculated via interpolation of its 3 corner normals. When one
normal is rotated more than 180 degrees in relation to the others, how
should POV know which way to do the interpolated rotation? Bad ASCII art:

 |   /
--- --- ---
         \

 |   \
--- --- --- ---
         /   \

The end result is the same, but the intermediate normals are different. As
long as the angle difference is less than 180 degrees there is no ambiguity.

Margus

Gordon wrote:
> 
> It does seem strange to me as well. In the particle system I am working on,
> I'm using smooth triangles as the particles. I calculate normals that point
> at 90 degrees to the average normal of the triangle. These normals are
> parallel to the surface and have had no error mesages like this.
> 
> Any programmer types who get into the POV code care to explain in detail?
> 
> Thanks
> Gordon
> 
> david sharp wrote in message <36F### [at] interportnet>...
> >
> >fourth dimension?
> >a ball doesn't have to twist into a fourth dimension to have
> >normals pointing in *every* direction.
> >
> >Since Nathan Kopp posted that at least that one triangle was OK with
> >POV-Ray 3.1a, I find this still mysterious.

Post a reply to this message

Upon furter meditation, this is not quite right. Ken's 4D argument is
correct. The sphere has normals pointing in all directions, but all normals
point to the same side of it's surface, by default the "outside". For an
object to have it's "inside" and "outside" on the same surface, it wold have
to be twisted in 4D (e.g. the Klein bottle, the 4D equivalent of the Moebius
band). This also happens when a smooth triangle's normals go from "up" at
one corner to "down" in the other.
The ambiguity problem I still applies, but a clearer definition is: when a
corner normal differs more than 90 degrees from the general normal (defined
by the corners of the triangle), POV cannot tell which way to do the
interpolation - is the surface concave? Or convex?

Margus

Margus Ramst wrote:
> 
> I'm not a programmer type and I might be wrong, but there seems to be a
> problem of ambiguity. This is how I envision it: the normals of a smooth
> triangle are calculated via interpolation of its 3 corner normals. When one
> normal is rotated more than 180 degrees in relation to the others, how
> should POV know which way to do the interpolated rotation? Bad ASCII art:
> 
>  |   /
> --- --- ---
>          \
> 
>  |   \
> --- --- --- ---
>          /   \
> 
> The end result is the same, but the intermediate normals are different. As
> long as the angle difference is less than 180 degrees there is no ambiguity.
> 
> Margus
>

Post a reply to this message

Margus Ramst wrote:
> 
> Upon furter meditation, this is not quite right. Ken's 4D argument is
> correct. The sphere has normals pointing in all directions, but all normals
> point to the same side of it's surface, by default the "outside". For an
> object to have it's "inside" and "outside" on the same surface, it wold have
> to be twisted in 4D (e.g. the Klein bottle, the 4D equivalent of the Moebius
> band). This also happens when a smooth triangle's normals go from "up" at
> one corner to "down" in the other.
> The ambiguity problem I still applies, but a clearer definition is: when a
> corner normal differs more than 90 degrees from the general normal (defined
> by the corners of the triangle), POV cannot tell which way to do the
> interpolation - is the surface concave? Or convex?
> 
> Margus

  I was taking a shot in the dark with that reply but it just so happens
that I was reading up on the klien bottle last night before I responded
and that is what prompted me to think that it might be a case of twisting
it being twisted in a "4th" dimension. I can't think of any other way to
have two opposing sides of a flat surface connected to each other. Looks
like I got lucky this time.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Well, yes and no. Remember, we are dealing with surface normals _only_ in
this case. The triangle has no inside/outside. In theory the normals could
flip from one side of the triangle to the other, POV wouldn't give a damn.
It would simply result in a strange jump in lighting.
By the way, CSG objects often have surface normals pointing both in and out
(as a result of the difference operation). This creates problems only in
very specific cases, like using the trace() funcion to do something based on
the surface normal (creating furry CSG is a bitch :)
The Julia fractal is a 4D object. Rendering 4D objects isn't all that
difficult, but it would have to be a 3D "slice" of the object, so result are
hard to predict.

I think the real problem is that of ambiguity, which I described.

Also, I notice that I'm in a talkative mood today.

Margus

Ken wrote:
/.../
> have two opposing sides of a flat surface connected to each other. Looks
> like I got lucky this time.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote:
[ ... ]
>				 I can't think of any other way to
> have two opposing sides of a flat surface connected to each other. Looks
> like I got lucky this time.


The normals are at different corners, not the same place.
The normals are, 'by definition', coming out of the same side of the 
triangle. If they are going in opposite directions, that, I thought,
is just supposed to mean that the expected surface (not the actual
triangle
defined by the vertices) bends around that much.

Post a reply to this message

david sharp wrote in message <36F### [at] interportnet>...
>Ken wrote:
>[ ... ]
>> I can't think of any other way to
>> have two opposing sides of a flat surface connected to each other. Looks
>> like I got lucky this time.
>
>
>The normals are at different corners, not the same place.
>The normals are, 'by definition', coming out of the same side of the
>triangle. If they are going in opposite directions, that, I thought,
>is just supposed to mean that the expected surface (not the actual
>triangle
>defined by the vertices) bends around that much.

That was also my interpretation. The image I have in mind is a short piece
of ribbon twisted so that one end is 180 degress to the other.

Gordon

Post a reply to this message

Gordon wrote:

[ ... ]
>			The image I have in mind is a short piece
> of ribbon twisted so that one end is 180 degress to the other.


Which is what motivated the question in the first place!:
	http://www.interport.net/~dsharp/
(about the middle of the page)

Post a reply to this message

On Sun, 21 Mar 1999 18:47:47 -0500, david sharp <dsh### [at] interportnet> wrote:
>Now, my question is why does POV-Ray do that? What is wrong with
>one normal pointing 'up' while two point 'down' (or vice versa)?

I guess I should reply to this one, since I submitted the bug 
report that got these classified as degenerate triangles. :)
The problem is, those triangles cause division by zero errors
on Alpha processors.  There is no way to have the normal go 
from "positive" to "negative" without going through zero, so 
there is always a curve on such a triangle where the normal
is undefined.  Since POV always needs a valid normal to compute
shading, that's a bad thing.  

If you want to see the original discussion that caused this, 
you'll have to go back a few months on povray.programming.

Post a reply to this message

Ken wrote:
> I can't think of any other way to
> have two opposing sides of a flat surface connected to each other.

How about a muebius strip (spelling?), the band with only one surface.
Perhaps the problem is that if you interpolate normals pointing to
different
sides of the surface there will exist a point on the triangle with the
normal <0,0,0> which of course messes things up....

/ Mathias Broxvall

Post a reply to this message

Ron Parker wrote:
[ ... ]
> The problem is, those triangles cause division by zero errors
> on Alpha processors.  There is no way to have the normal go
> from "positive" to "negative" without going through zero, so
> there is always a curve on such a triangle where the normal
> is undefined.  Since POV always needs a valid normal to compute
> shading, that's a bad thing.


Hmmmm, I just assumed that POV was rotating the normals from one 
triangle corner to the next, in which case I don't see any 'zero' 
normal. 
Your comment makes me believe that what POV does is interpolate the 
vector coefficients independently.
(ie, n1.x -> n2.x, n1.y -> n2.y, n1.z -> n2.z linearly, not rotating
the normal).
(or does this question just demonstrate my complete misunderstanding)

Post a reply to this message

On Tue, 23 Mar 1999 12:47:37 -0500, david sharp <dsh### [at] interportnet> wrote:
>Ron Parker wrote:
>[ ... ]
>> The problem is, those triangles cause division by zero errors
>> on Alpha processors.  There is no way to have the normal go
>> from "positive" to "negative" without going through zero, so
>> there is always a curve on such a triangle where the normal
>> is undefined.  Since POV always needs a valid normal to compute
>> shading, that's a bad thing.
>
>
>Hmmmm, I just assumed that POV was rotating the normals from one 
>triangle corner to the next, in which case I don't see any 'zero' 
>normal. 
>Your comment makes me believe that what POV does is interpolate the 
>vector coefficients independently.

It's good that that's what it makes you believe, for that is indeed what it 
does.  Below are the nice ASCII-art comments from the relevant spot in 
triangle.c.  The normalization step is what causes the division-by-zero error 
in some cases.  There may also be lighting code that is sensitive to normals
that are exactly perpendicular to the ray.  The solution to the problem is to 
specify your geometry more precisely by creating more triangles.  The 
difference between the normals at the corners of a smooth triangle shouldn't 
be large, anyway, because the Phong approximation works best for smallish 
angles.  I will admit, though, that if the new code is based on my original 
thoughts on this matter, it might be a bit more sensitive to this problem 
than is strictly necessary.

If you're trying to create a twisted-ribbon type of thing, perhaps you 
would find more success and realism with bicubic patches.  

*   Calculate the Phong-interpolated vector within the triangle
*   at the given intersection point. The math for this is a bit
*   bizarre:
*
*      -         P1
*      |        /|\ \
*      |       / |Perp\
*      |      /  V  \   \
*      |     /   |    \   \
*    u |    /____|_____PI___\
*      |   /     |       \    \
*      -  P2-----|--------|----P3
*                Pbase    PIntersect
*          |-------------------|
*                         v
*
*   Triangle->Perp is a unit vector from P1 to Pbase. We calculate
*
*   u = (PI - P1) DOT Perp / ((P3 - P1) DOT Perp).
*
*   We then calculate where the line from P1 to PI intersects the line P2 to P3:
*   PIntersect = (PI - P1)/u.
*
*   We really only need one coordinate of PIntersect.  We then calculate v as:
*
*        v = PIntersect[X] / (P3[X] - P2[X])
*   or   v = PIntersect[Y] / (P3[Y] - P2[Y])
*   or   v = PIntersect[Z] / (P3[Z] - P2[Z])
*
*   depending on which calculation will give us the best answers.
*
*   Once we have u and v, we can perform the normal interpolation as:
*
*     NTemp1 = N1 + u(N2 - N1);
*     NTemp2 = N1 + u(N3 - N1);
*     Result = normalize (NTemp1 + v(NTemp2 - NTemp1))
*
*   As always, any values which are constant for the triangle are cached
*   in the triangle.

Post a reply to this message

Ron Parker wrote:
[ ... ]
>				 The solution to the problem is to
> specify your geometry more precisely by creating more triangles.  The
> difference between the normals at the corners of a smooth triangle shouldn't
> be large, anyway, because the Phong approximation works best for smallish
> angles.  

It now seems to me, after a few similar problems, that the solution
always ends up being '*more* triangles!'

[ ... ]
> If you're trying to create a twisted-ribbon type of thing, perhaps you
> would find more success and realism with bicubic patches.

oh thats probably true, but then I would have to figure them out.
Aren't bicubic patches those things you specify with huge arrays of
numbers that don't make any sense?

Post a reply to this message

On Tue, 23 Mar 1999 14:52:36 -0500, david sharp <dsh### [at] interportnet> wrote:
>Ron Parker wrote:
>[ ... ]
>> If you're trying to create a twisted-ribbon type of thing, perhaps you
>> would find more success and realism with bicubic patches.
>
>oh thats probably true, but then I would have to figure them out.
>Aren't bicubic patches those things you specify with huge arrays of
>numbers that don't make any sense?

No, those are those things you specify with 4x4 arrays of numbers that
make perfect sense once you understand them. :)  The best understanding
I've been able to formulate for a bicubic patch is that the four corners
of a patch are always on the surface of the patch.  The other eight edge
points are "control points" analogous to the "handles" on Bezier curves
in programs like Corel Draw, Freehand, or Illustrator in that they define
the beginning and ending direction of the curves that define the edges of 
the patch, as well as the "tension" at the corners.  These eight points 
also specify the surface normals at the four corners, sorta indirectly.

The four points in the middle of the patch are the hardest to understand, 
but I tend to visualize them as the same sort of "control points," except
that the "anchors" they are associated with are not actually on the 
surface of the patch.  In a sense, they control how the surface slopes 
away from the edge curves, though their exact effect might not be 
immediately or intuitively obvious.

An alternate view (less precise, more "artsy") is to just visualize the 
sixteen points as a simple mesh of quadrilaterals, like a wire screen. 
Bend it and stretch it however you will, and the resultant patch will do 
its best to approximate that shape while remaining smooth (though it will 
only actually touch any of the grid points at the corners, in most cases.)

If you want to play, grab the source to my IRTC entry for the latest 
round and check out the source to the bedsheet.  Some of the commented-out
code in that file allows you to visualize the control mesh that governs
the final shape of the sheet.

Post a reply to this message

While we are on the(off the) topic of tirangles, patches and so on..
I'm working on a small landscape generator macro, and I'm not very satisfied
with the extreme high triangle count I'll need to make it visualised.

I have the points in a 2D array, each storing a height value(sorta like a
heightfield) I know all points are declared, so there are no such problems.

Yes, I guess I could use smooth_triangle, but i don't know where the normals
would be, since I only have height data.
I guess I could try and point all the normals UP, but that wouldn't be really
useful, would it?

I came to think of using patches, but then... I'd have to use a loop to split
the big grid into smaller pieces, and then use four as corners, and the rest as
control points, I know it'd be looking nice, but there would be a mess to set it
up for me.

Any tips/ideas ??
My current render has a triangle count of :
38416+355216 triangles....



-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Spider,

Have a look at the code for my Simple Surface Macros in
binaries.scene-files. If you look through the code, you will see that it
calculates the normals. The key is that you need to average the normals of
the 6 (or whatever) triangles that meet at a particular corner. If you then
use this normal for that corner on each of the triangles, they will all be
smooth. In order to ensure you always get normals on the same side of the
surface, make sure that you do the cross products in the same order for
every corner.

For example, if you have a triangle with corners A, B, C defined in a
clockwise direction. Normal at A is vnormalize(vcross(B-A,C-A)), normal at B
is vnormalize(vcross(C-B,A-B)), and at C it is vnormalize(vcross(A-C,B-C)).
Note that the order of the corners is clockwise in each call, the normals
may be on the "top" or "bottom" but all will be on the same side.. Draw it
and see!

If this is not clear, let me know and I will try to explain in more detail,
with an example.

Regards
Gordon
<gtb### [at] birdcameroncomau>

Spider wrote in message <36F83193.8091B4A5@bahnhof.se>...
>While we are on the(off the) topic of tirangles, patches and so on..
>I'm working on a small landscape generator macro, and I'm not very
satisfied
>with the extreme high triangle count I'll need to make it visualised.
>
>I have the points in a 2D array, each storing a height value(sorta like a
>heightfield) I know all points are declared, so there are no such problems.
>
>Yes, I guess I could use smooth_triangle, but i don't know where the
normals
>would be, since I only have height data.
>I guess I could try and point all the normals UP, but that wouldn't be
really
>useful, would it?
>
>I came to think of using patches, but then... I'd have to use a loop to
split
>the big grid into smaller pieces, and then use four as corners, and the
rest as
>control points, I know it'd be looking nice, but there would be a mess to
set it
>up for me.
>
>Any tips/ideas ??
>My current render has a triangle count of :
>38416+355216 triangles....
>
>
>
>--
>//Spider
>        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
>What I can do and what I could do, I just don't know anymore
>                "Marian"
>        By: "Sisters Of Mercy"

Post a reply to this message

The calculation of the normals is also explained in detail in my
triangle mesh smoother, http://iki.fi/warp/PovUtils/smooth.html

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I'll look at it. Thanks.

<snipping the help>

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Ok, thanks, I'll look at this as well.

Nieminen Mika wrote:
> 
>   The calculation of the normals is also explained in detail in my
> triangle mesh smoother, http://iki.fi/warp/PovUtils/smooth.html
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

On Wed, 24 Mar 1999 01:28:03 +0100, Spider <spi### [at] bahnhofse> wrote:
>I have the points in a 2D array, each storing a height value(sorta like a
>heightfield) I know all points are declared, so there are no such problems.
>
>Yes, I guess I could use smooth_triangle, but i don't know where the normals
>would be, since I only have height data.
>I guess I could try and point all the normals UP, but that wouldn't be really
>useful, would it?

A reasonable normal is the cross product of a vector pointing uphill at the 
steepest possible angle[1] and a vector pointing along a contour line.[2] 
If your height data is dense enough, you should be able to approximate those 
well enough.  

One problem you'll have with patches is that if you don't have enough data to 
generate the normals for a smooth triangle, you don't have enough to make the 
control points for a patch, either.

[1] Its projection in 2d would be the gradient, so if you add the the (x,y) 
gradient vector to the derivative of the height over that vector, times z, 
then normalize, you'll have the "uphill" vector.

[2] Its projection in 2d is perpendicular to the gradient, and its z component 
is zero by definition.  So it is just the gradient vector rotated by 90 degrees
about the z axis.

Post a reply to this message

Ron Parker wrote:
>						    The best understanding
> I've been able to formulate for a bicubic patch is that the four corners
> of a patch are always on the surface of the patch.  The other eight edge
> points are "control points" analogous to the "handles" on Bezier curves
> in programs like Corel Draw, Freehand, or Illustrator in that they define
> the beginning and ending direction of the curves that define the edges of
> the patch, as well as the "tension" at the corners.  These eight points
> also specify the surface normals at the four corners, sorta indirectly.
> 
> The four points in the middle of the patch are the hardest to understand,
> but I tend to visualize them as the same sort of "control points," except
> that the "anchors" they are associated with are not actually on the
> surface of the patch.  In a sense, they control how the surface slopes
> away from the edge curves, though their exact effect might not be
> immediately or intuitively obvious.

Thanks. This makes bicubics less intimidating.

Post a reply to this message