# “The function DiscretizeGraphics is not implemented for GraphicsComplex” confusion

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}]]];
DiscretizeGraphics[p1]


But this does not

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

(*The function DiscretizeGraphics is not implemented for \
GraphicsComplex[{{0.9999999999998993,4.487989505128125*^-7,*)


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

Here is the FullForm for p1

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

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.

http://reference.wolfram.com/language/ref/DiscretizeGraphics.html?q=DiscretizeGraphics

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?

-

## 2 Answers

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

DiscretizeGraphics[Cylinder[]]


-
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? mathematica.stackexchange.com/questions/85592/… – 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}]


Now we discretize:

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


-