Mathematica Stack Exchange is a question and answer site for users of Mathematica. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why does DiscretizeGraphics seems to work on one GraphicsComplex and not the other? Here is an example that works:

v = {{1, 0}, {0, 1}, {-1, 0}, {0, -1}};
p1 = Graphics[GraphicsComplex[v, Polygon[{1, 2, 3, 4}]]];

But this does not

p2 = Graphics3D[First@ParametricPlot3D[{Cos[t],  Sin[u], c Sin[t]}, 
   {u, 0, 2 Pi}, {t, 0, 2 Pi}]];

(*The function DiscretizeGraphics is not implemented for \

But p2 is a GraphicsComplex? Looking at FullForm[p2]

Mathematica graphics

Here is the FullForm for p1

Mathematica graphics

Are not p1 and p2 both GraphicsComplex ? p1 is 2D and p2 is 3D, but are they not both considered GraphicsComplex?

Mathematica graphics

It will good to know exactly what can and what can not be discretized. I tried to find this, but could not. All what I see are examples of usages so far.


Mathematica graphics

I also looked at possible issues, and did not notice anything about this. Only one that came close is this multiple volume primitives is not supported. Is this the case here?

share|improve this question
up vote 9 down vote accepted

In the end this is a bug and I filed that.

Now, what is going on: If you extract the coords and polygons from the GraphicsComplex and try to set up a MeshRegion you get a warning:

gc = First@
   ParametricPlot3D[{Cos[t], Sin[u], Sin[t]}, {u, 0, 2 Pi}, {t, 0, 
     2 Pi}];
ply = Cases[(gc)[[2]], _Polygon, Infinity]
MeshRegion[gc[[1]], ply]
MeshRegion::coplnr: "The vertices in the polygon Polygon[{{1129,1621,705,100}}] are not coplanar."

I guess that is what is happening internally and then the conversion is rejected. It could have given a better message, though.

All of the Graphics(3D) functions were written before the MeshRegion functionality became available and used their own mesh format. For graphics it is not too important that the underlying mesh is of a good quality (e.g. no non coplanar elements). They human eye is very forgiving in that sense. But for computations over meshes it is essential that the underlying mesh has a reasonable quality. In this case the ParametricPlot3D needs to get rid of those non coplanar elements.

To get a discretized cylinder could use


enter image description here

share|improve this answer
Have you asked to have your account merged with your previous account, or are you content to start over? – rcollyer Jul 17 '14 at 1:29
@rcollyer, thanks for the suggestion. I hope that when I deleted the old account that is was deleted proper ;-) but it probably would be possible... right now I have enough rep. to vote, comment and write answers, that's enough. – user21 Jul 17 '14 at 5:54
I still find traces of it now and again, so likely they could be merged. However, I'm likely the only one who's noticed. – rcollyer Jul 17 '14 at 13:11
If a mesh is made of element with faces non coplanar (to some extent) the PDE solutions I compute with that mesh can be affected?… – unlikely Mar 6 at 0:37
@unlikely, possibly, that might introduce errors at the boundary that ruin the solution; but that's hard to say without seeing an example. – user21 Mar 6 at 9:18

Here is a workaround for this I've been using:

p2 = Graphics3D@First@ParametricPlot3D[{Cos[t], Sin[u], Sin[t]}, {u, 0, 2 Pi}, {t, 0, 2 Pi}]

Mathematica graphics

Now we discretize:

DiscretizeGraphics[Normal[p2 /. (Lighting -> _) :> Lighting -> Automatic]]

Mathematica graphics

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.