On Sun, 29 Aug 1999 09:18:52 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>Remco de Korte wrote:
>> 
>> I don't know if this'll alway work but I would calculate a 'middle'-point (M)
>> (adding up aal points in the object and dividing them by the amount of points)
>> then step through the row of points connecting two consecutive points to this M
>> (creating a triangle.
>
>If the polygon is planar, there is no benefit to this approach.  If the
>polygons are approximations of curved surfaces or the vertices are
>points on a curved surface, picking a point in the middle and
>reevaluating the surface function at that point does make some sense. 
>If adding points isn't necessary, then adding points will increase the
>number of triangles and thereby decrease performance.  If the polygon is
>planar, just pick an existing vertex and draw edges to all the other
>points. If all the narrow angles cause acne or something due to loss of
>precision, though, your idea may be worth a shot.  I haven't actually
>tried it.
>
I think what I'm going to ahve to do is write a "face preview"
facility in OBJuvPOV I think. So that I can *see* what the program's
encountering to help me evaluate which tack might work (I'm not good
at math - I've not the first idea how to work out if a face is planar
given just the verteces - unless they happen to lie along one of the
axes, of course!).


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Cliff Bowman wrote:
> 

> I think what I'm going to ahve to do is write a "face preview"
> facility in OBJuvPOV I think. So that I can *see* what the program's
> encountering to help me evaluate which tack might work (I'm not good
> at math - I've not the first idea how to work out if a face is planar
> given just the verteces - unless they happen to lie along one of the
> axes, of course!).

Any three points define a plane.  Derive an equation of that plane from
the vertices, and test the other points to see whether they lie on that
plane.  Actually, you should expect a little deviation from the plane on
account of finite precision, so test whether the point is within some
small distance epsilon of the plane.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote:
: If the polygons are not convex, recursively lop off pointy bits as
: triangles until they are.

  If you take any three points of the polygon, how can you be sure that
the triangle defined by them is completely inside the polygon?

-- 
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

Nieminen Juha wrote:
> 
> Mark Gordon <mtg### [at] mailbagcom> wrote:
> : If the polygons are not convex, recursively lop off pointy bits as
> : triangles until they are.
> 
>   If you take any three points of the polygon, how can you be sure that
> the triangle defined by them is completely inside the polygon?

I made implicit reference to a "pointy bit test" ... yeah, that's right.
;-)

Assume the polygon is defined as a sequence of points on its periphery. 
A triplet of points on the edge of the polygon forms a "pointy bit" (my
jargon) if the interior angle formed at the second point (as measured in
the plane defined by the three points) is less than 180 degrees.  If the
interior angle formed at the second point is greater than 180 degrees
it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
well remove the middle point as redundant.

Conversion to radians is left as an exercise for the reader. ;-)

Pardon me for being a bit punchy - didn't get much sleep.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

On Mon, 30 Aug 1999 07:52:45 -0500, Mark Gordon wrote:
>Nieminen Juha wrote:
>> 
>> Mark Gordon <mtg### [at] mailbagcom> wrote:
>> : If the polygons are not convex, recursively lop off pointy bits as
>> : triangles until they are.
>> 
>>   If you take any three points of the polygon, how can you be sure that
>> the triangle defined by them is completely inside the polygon?
>
>I made implicit reference to a "pointy bit test" ... yeah, that's right.
>;-)
>
>Assume the polygon is defined as a sequence of points on its periphery. 
>A triplet of points on the edge of the polygon forms a "pointy bit" (my
>jargon) if the interior angle formed at the second point (as measured in
>the plane defined by the three points) is less than 180 degrees.  If the
>interior angle formed at the second point is greater than 180 degrees
>it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
>well remove the middle point as redundant.

Unfortunately, it's not quite that easy.  You can't lop of just any
pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
the center of the base.  Move that vertex upward, so what you get looks
like a rather angular version of the Federation emblem from Star Trek.
Note that the angle surrounding the topmost vertex qualifies as a 
"pointy bit" yet the resulting triangle is neither inside nor outside
the polygon.

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote:
: Assume the polygon is defined as a sequence of points on its periphery. 
: A triplet of points on the edge of the polygon forms a "pointy bit" (my
: jargon) if the interior angle formed at the second point (as measured in
: the plane defined by the three points) is less than 180 degrees.  If the
: interior angle formed at the second point is greater than 180 degrees
: it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
: well remove the middle point as redundant.

  This doesn't work. A vertex of the polygon may lie inside the triangle.
If this is so, the triangle will be partially outside the polygon.
  Think about an 'L' made of 6 vertices. Now take the upper left vertex,
the lower left vertex and the lower right vertex. The triangle they define
"seems" to be inside the polygon, but it doesn't.

-- 
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

Ron Parker wrote:
> 
> Unfortunately, it's not quite that easy.  You can't lop of just any
> pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
> the center of the base.  Move that vertex upward, so what you get looks
> like a rather angular version of the Federation emblem from Star Trek.
> Note that the angle surrounding the topmost vertex qualifies as a
> "pointy bit" yet the resulting triangle is neither inside nor outside
> the polygon.

Point well taken.  Like I said, I was a bit sleep deprived.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Hi,

>I wonder if Thomas has had similar problems. I have noticed that when converting
>some models with 3DWin that no matter what the smoothing angle specified there
>are some times a few to several triangles that are still represented as simple
>triangles instead of as smooth triangles.

Hmm, current 3DWin import of OBJ files is very simple. It processes
only face information (no normals or uv faces). Smoothing is done in a
seperate stage. 

I have found and tested some very strange OBJ files with missing
vertices, wrong face to vertex links, double faces and lots of
degenerated faces.

3DWin tries to fix this errors and throws out such faces.

-Thomas

Post a reply to this message

On Wed, 01 Sep 1999 06:11:34 GMT, NOS### [at] ibmnet (Thomas
Baier) wrote:

[snip]
>I have found and tested some very strange OBJ files with missing
>vertices, wrong face to vertex links, double faces and lots of
>degenerated faces.
>
>3DWin tries to fix this errors and throws out such faces.
>
OBJ files do seem to be annoyingly... poorly written, don't they?
Degenerate faces is the first problem that surprised me (closely
followed by faces with 26 verteces - which I think I've now sussed).
the number of degenerate faces the average .OBJ contains is almost
depressing.

Double faces I think I know the reason for. A lot of modellers seem to
get the normals *wrong* and so users sometimes make a copy of the
model, flip the normals, and combine the two sets of meshes.

Dirty, and probably works in many cases (i.e. patches holes) but time
and memory are both wasted. I can't help but feel it'd cause some
renderers to cough and splutter too  - though as I've not knowingly
come across this yet I don't know how much POV "likes" or dislikes it.

I'd expect there to be "coincident faces" (is that the term?) problems
though.


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Tue, 31 Aug 1999 21:17:41 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>Ron Parker wrote:
>> 
>> Unfortunately, it's not quite that easy.  You can't lop of just any
>> pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
>> the center of the base.  Move that vertex upward, so what you get looks
>> like a rather angular version of the Federation emblem from Star Trek.
>> Note that the angle surrounding the topmost vertex qualifies as a
>> "pointy bit" yet the resulting triangle is neither inside nor outside
>> the polygon.
>
>Point well taken.  Like I said, I was a bit sleep deprived.
>

It would appear from empiracle evidence that .OBJ writers are using
the many-verteces face as a space saving technique (obviously 20-odd
coplanar triangles take less file space when expressed as a single
face than as numerous triangles). I have yet to find a face which
isn't convex, or one that isn't co-planar. As such I've got a simple
solution in place just waiting for a .OBJ file with the right
deficiencies to make the program translate incorrectly <eg>

Please - no one build a .OBJ in a text editor just to break the
program!


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message