9
$\begingroup$

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]

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.

reference: http://www.wolfram.com/mathematica/new-in-10/data-and-mesh-regions/discretizing-graphics.html

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

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?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
11
$\begingroup$

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

enter image description here

Improve this answer
$\endgroup$
2
  • $\begingroup$ 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/… $\endgroup$ Commented Mar 6, 2016 at 0:37
  • $\begingroup$ @unlikely, possibly, that might introduce errors at the boundary that ruin the solution; but that's hard to say without seeing an example. $\endgroup$ Commented Mar 6, 2016 at 9:18
5
$\begingroup$

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

Improve this answer
$\endgroup$
0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.