What are the design principles, or other explanations, as to why one needs to apply DiscretizeRegion to obtain a graphical representation of a derived region, rather than Graphics or Graphics3D? (It's not what I expected.)

For example, Disk[{0,0}, 1] and Disk[{2,0},1] are displayed if you wrap each in Graphics. Why must one then use

DiscretizeRegion[RegionUnion[Disk[{0,0}, 1], Disk[{2,0}, 1]]]

rather than the corresponding expression with Graphics instead of DiscretizeRegion.

The same issue arises with derived regions that are 3-dimensional, where one might expect to display them with Graphics3D but in fact must use DiscretizeRegion again.

  • 4
    $\begingroup$ A derived region cannot always be represented in terms of Graphics(3D) primitives. It can, however, be visualized with RegionPlot(3D). On the other hand, mesh regions always can, so they typeset as graphics by default. $\endgroup$ – ilian Jul 16 '15 at 21:16
  • $\begingroup$ That's a question I also was curious about. @ilian could you possibly explain this in more details, to understand, why it "cannot always be represented..." ? May be you could formulate it then as a regular answer? $\endgroup$ – Alexei Boulbitch Jul 17 '15 at 7:24
  • $\begingroup$ @Alexei Posted slightly expanded comment as an attempted answer. $\endgroup$ – ilian Jul 17 '15 at 16:26

As ilian pointed out in a comment, you are not limited to DiscretizeRegion for visualizing a region. There is also RegionPlot, which may be more to your liking.


r = RegionUnion[Disk[{0, 0}, 1], Disk[{2, 0}, 1]];



RegionPlot[r, AspectRatio -> Automatic]


  • $\begingroup$ Still the whole situation doesn't yet fit together for me: Using RegionPlot to visualize RegionUnion[Disk[{0, 0}, 1], Disk[{2, 0}, 1]] makes perfect sense. However, RegionProduct[Disk[{0, 0}, 1], Line[{{0}, {1}}]] has head Cylinder, so just Graphics3D[RegionProduct[Disk[{0, 0}, 1], Line[{{0}, {1}}]]] works to see it. And RegionProduct[Disk[], Line[{{0}, {1}}]] has head Cylinder, but wrapping that with Graphics3D fails to display it whereas wrapping it with RegionPlot3D does display it. $\endgroup$ – murray Jul 17 '15 at 16:22
  • $\begingroup$ @murray Yes, that's an inconsistency. RegionProduct[Disk[], Line[{{0}, {1}}]] could (and probably will, in a future version) autosimplify to a Cylinder. But it is a perfectly valid region even with head RegionProduct. $\endgroup$ – ilian Jul 17 '15 at 16:41
  • $\begingroup$ My personal opinion is that people use DiscretizeRegion way too much as an expression for visualizing regions. RegionPlot is really the way to go; discretization has a side effect of producing something visual, but it is really ought to be used when actual discretized property of a region approximation itself is the goal. Sadly both of these functions have had some problems, among others consistently crashing the kernel on particularly nasty inputs. I have to check out if the situation has improved with v10.2. $\endgroup$ – kirma Jul 18 '15 at 5:26

Graphics (and Graphics3D) accept graphics primitives as input. Version 10 introduced a number of special (or basic) geometric regions which serve as both regions and graphics primitives, so they can be given directly to Graphics (at least the 2D and 3D cases), for example Graphics[Disk[]].

When it comes to derived regions, sometimes they directly correspond to a primitive, for example

RegionIntersection[Rectangle[{0, 0}], Rectangle[{0.5, 0.5}]]

(* Rectangle[{0.5, 0.5}, {1, 1} *)]

and thus can be fed to Graphics (by the way, a number of similar region autosimplification rules are under development). However, there isn't a graphics primitive corresponding to

RegionIntersection[Disk[{0, 0}, 1], Disk[{0.5, 0.5}, 1]]

or, the equivalent region in different form

  ParametricRegion[{r Cos[t], r Sin[t]}, {{r, 0, 1}, {t, 0, 2 Pi}}], 
  ImplicitRegion[(x - 0.5)^2 + (y - 0.5)^2 <= 1, {x, y}]]

Besides boolean operations, there are other ways to construct derived regions, for example TransformedRegion where the result generally is not going to be representable as a combination of graphics primitives.

On the other hand, a MeshRegion is built from cells which are graphics primitives and thus can always be drawn. The default is for mesh regions to typeset as graphics, which is why the result of

DiscretizeRegion[RegionIntersection[Disk[{0, 0}, 1], Disk[{0.5, 0.5}, 1]]]

is immediately visualized. In the next example, the intersection is again a (boundary) mesh region and is displayed accordingly

mr1 = MeshRegion[{{0, 4}, {2, 1}, {4, 4}}, Polygon[{1, 2, 3}]];
mr2 = MeshRegion[{{0, 0}, {2, 3}, {4, 0}}, Polygon[{1, 3, 2}]];
ℛ = RegionIntersection[mr1, mr2]

where the actual Graphics expression used by the typesetting can be shown by

Show[ℛ] // InputForm
  • 1
    $\begingroup$ But why DiscretizeRegion rather than RegionPlot in these two-dimensional examples? $\endgroup$ – murray Jul 18 '15 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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