MathGroup Archive 2001

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

Search the Archive

RE: Lost Line Directives in 3D Graphics

  • To: mathgroup at
  • Subject: [mg30174] RE: Lost Line Directives in 3D Graphics
  • From: "David Park" <djmp at>
  • Date: Wed, 1 Aug 2001 02:19:33 -0400 (EDT)
  • Sender: owner-wri-mathgroup at

Hi Tom,

I believe that this is more than just round off error, or an arbitrary
choice of what to display. The example I posted was just one of many similar
problems I encountered. I posted it because I wanted something that was
clean and unrelated to my own packages and code. So far, everyone who has
tried it sees the same effect. Nevertheless, let me describe some of the
other effects I have obtained.

I am trying to write a notebook that illustrates 3D rotation sequences. I
use an Arrow3D routine from my DrawingArrows package to draw axes. A 3D
arrow is composed of a line and a polygonal cone at the tip. I have another
routine which draws a book rotated about the origin by a rotation matrix.

In one animation, the three axes stay fixed and the book is rotated. In most
of the frame cells the arrow cone is missing from the y-axis (but not the x
and z axes). In a few frames the cone suddenly reappears. I am using a fixed
plot range and the cone itself is not rotating or changing in any way from
frame to frame. Nor is there any other element on top of or coincident with
the cone, in 3D or in perspective, in most of the bad frames.

In another animation I have two sets of axes. One set is colored and fixed.
The other set is black and rotates. Some, but not all, of the vectors in the
rotating axes pick up the color of the fixed axes. How and to what extent
they do this varies from frame to frame of the animation. The lines are not

In the same animation, if I set Boxed -> True, then for about half of the
frames, half of the bounding box lines pick up the color that I specified
for the fixed axes. The other half of the lines in the bounding box are
black. It is not my code that is drawing the bounding box so I am pretty
certain that this is a Mathematica error.

In one of the frames, an arrow shaft which should be entirely black, is
about 3/4 colored and 1/4 black. There is no coincident line drawn on top of

I am generally setting Lighting -> False in these animations. If I set it to
True, then some of the bad effects go away. But not always. The example I
posted had Lighting -> True.

I believe that there is a serious problem in the rendering of 3D graphics.
But if it is all so serious, why hasn't it surfaced before? I suspect that
there just aren't many people making 3D plots that have polygons and lines
with color or thickness directives. Or they brushed off or just didn't
notice the problem.

I would be glad to supply the package and notebook containing the examples
for anyone who is interested. I have been working on the notebook with a
friend and he sees the same effects.

David Park
djmp at

> From: Tom Burton [mailto:tburton at]
To: mathgroup at
> Hello,
> On Mon, 30 Jul 2001 01:29:09 +0000 (UTC), in
> comp.soft-sys.math.mathematica you wrote:
> >Dear MathGroup,
> >
> >Here is a case where it appears that Mathematica incorrectly renders the
> >postscript code for Graphics3D. I wonder if other people obtain the same
> >effect that I obtain.
> ...
> >The plot consists of a long thin black line, and a shorter thick
> red line on
> >top of it, with a three polygon cone at the end, but slightly
> detached from
> >the short line. The line directives for the short line are lost,
> so that it
> >also appears thin and black.
> ...
> I tried this with version 4.1.0 for Windows (11/2/2000) on
> Windows NT 4 service pack 6. I may be seeing the same thing you
> do, but I interpret it differently. The short line is not
> different in some frames; rather, it is entirely suppressed.
> When two lines coincide in a 3D graphic, the choice of which to
> display is undefined and therefore, I assume here, subject to the
> vagaries of numerical round-off accidents. So when I see that,
> sometimes the thick line is suppressed by the thin line and
> sometimes not, I am not surprised.
> As far as the presence or absense of the polygon is concerned,
> once I get into the realm of round-off accidents, all bets are off.
> I suggest that either you shorten the shorten the thin black line
> to keep it away from the thik red line.
> Tom Burton

  • Prev by Date: Re: SquareFreeQ vs. MoebiusMu
  • Next by Date: latex and Mathematica, problems
  • Previous by thread: Re: Lost Line Directives in 3D Graphics
  • Next by thread: RE: Lost Line Directives in 3D Graphics