MathGroup Archive 2000

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Mathematica bug in Graphics3D ??

  • To: mathgroup at
  • Subject: [mg22245] Re: [mg22213] Mathematica bug in Graphics3D ??
  • From: Hartmut Wolf <hwolf at>
  • Date: Sat, 19 Feb 2000 01:33:46 -0500 (EST)
  • Organization: debis Systemhaus
  • References: <> <>
  • Sender: owner-wri-mathgroup at

I'd like to publish part of a following up conversation between Axel and
me (with some additions). I had written:

Hartmut Wolf schrieb:
> Axel Kowald schrieb:
> >
> > Hello,
> >
> > I'm using Mathematica under NT4 and when I try:
> >
> > Show[Graphics3D[Polygon[{{2.5, Sqrt[3]/2, 0}, {3.5, Sqrt[3]/2, 0},
> > {4, Sqrt[3], 0}, {3, 2*Sqrt[3], 0}, {2, 2*Sqrt[3], 0},
> > {3, Sqrt[3], 0}} ]], Axes -> True]
> >
> > Mathematica draws a polygon with only 5 corners where the last point
> > {3,Sqrt[3],0} is missing. Am I doing something wrong here or what is
> > going on ?
> >
> Hallo Axel,
> this is a problem encountered very often. When you name g1 to your
> Graphics3D and then do (with some knowledge of the rainbow) ...
> pp = Transpose[{Hue /@ (0.15 (Range[Length[g1[[1, 1]]]]-1)),
>                 Point /@ g1[[1, 1]]}]
>     ~Prepend~PointSize[0.05];
> Show[g1, Graphics3D[pp]]
> ... you'll see that your last point of the Polygon lies within its
> plane. So it cannot be closed correctly. Just move the points around
> (keeping their cyclical order of course)
> Show[RotateRight[g1, {0, 0, 1}], Graphics3D[pp]]

Axel now answered (translation is mine):

> Does this mean _Mathematica_ can only draw convex polygones?
Certainly not, since after the repair above you have the non-convex
polygon drawn "correctly" -- we will have to see what this means!

> What shall I do with a program generating hundreds of polygons? Write a routine, 
> that takes considerable effort to test which is the correct sequence of the points 
> to be specified for Polygon?

Well Axel, the problem is more difficult. Giving a sequence of points
(modulo cyclic permutation) means specifying the (directed) borderline
of the polygon. In 2 dimensions this defines the polygon unambiguously.

Not so for 3 dimensions! Take as a simple example the points at the
corners of a regular tetraeder. The sequence given defines a path along
the edges of the tetraeder -- along 4 edges of 6. Two edges are not
travelled. Now you have two choices to span the 3 dim Polygon: each
choice includes *one* of the unused edges, the other edge is left
Mathematica can't know which possibility is the right one, so it makes a
choice by its algorithm: the points 1-2-3 span one triangle surface, the
points 1-3-4 span the second.
You can inspect this:

quad = {{-1, 0, -1}, {0, -1, 1}, {1, 0, -1}, {0, 1, 1}}

    Graphics3D[{EdgeForm[Thickness[0.01], Hue[0.3]], Polygon[quad]}, 
      PolygonIntersections -> False]]]

...and after rotation of the points you get the second possibility

    Graphics3D[{EdgeForm[Thickness[0.01], Hue[0.3]], 
        Polygon[RotateRight[quad]]}, PolygonIntersections -> False]]]

(Better use Option PolygonIntersections -> False to see that more
clearly; also you might view the object from different viewpoints.)

For Polygons of higher order you get increasingly more possibilities.
And so I guess _Mathematica_'s algorithm works incrementally as such:
first it takes 1-2-3 to make up the first triangle, then 1-3-4 for the
second, then 1-4-5, ...  This would explain the appearance of your
misshaped polygon. (And some (plane) polygons can never be drawn
"correctly" with this algorithm -- yet the algorithm certainly works for
convex (plane) polygons.)

Now you might argue: since the points all lie in a plane Mathematica
should detect that case,... But the points are specified by imprecise
numbers, so with what tolerance should they be given?

Mathematica cannot know, yet you, i.e. your application does. Best
specify only the triangles with edges drawn (EdgeForm[]) and specify the
edges seperately as a Line primitive. There is an obvious algorithm to
do so incrementally for the plane: just avoid internal lines cross the
edges (in the plane) _and_ each edge must rest with one side "open",
exteriour and one side "closed", interiour. You see this works for a
plane and only for a plane.

In the true 3 dim case specifying the sequence of points for the edges
is just not enough, so then build up your Graph from triangles and edge
lines. How to do that must come out of your basic algorithm.

Kind regards, Hartmut

  • Prev by Date: Re: export graphics
  • Next by Date: Re: Simple Problem (I suppose...)
  • Previous by thread: Re: Mathematica bug in Graphics3D ??
  • Next by thread: Re: Mathematica bug in Graphics3D ??