Extraneous Contours from SliceContourPlot3D

Question

Bug introduced in 10.4.1 or earlier and persisting through 11.3

CASE:3866444

---

The straightforward computation,

SliceContourPlot3D[x^2 + y^2 + z^2, "CenterPlanes", {x, -1, 1}, {y, -1, 1}, {z, -1, 1}, 
    Contours -> {#}, ContourStyle -> Directive[Black, Thick], PlotPoints -> 200] & /@ 
    {1, .1, .03, .02}

produces a second set of contours near the origin for larger values of Contours and a set of misplaced Contours for Contours -> {0.02}. (Lest the reader suppose that PlotPoints is too small, I have reproduced the fist plot with PlotPoints -> 1000 although very slowly and with barely enough memory on a 16GB PC.)

I have three questions:

1. Is this a bug?
2. Is there a workaround?

and, on a related issue,

3. Why does x^2 + y^2 + z^2 == 1 (for instance) with no Contours specified produce an empty plot?

Simpler Plots

Similar undesirable results can be obtained much more rapidly for PlotPoints -> 1000 with

SliceContourPlot3D[x^2 + y^2 + z^2, z == 0, {x, -1, 1}, {y, -1, 1}, {z, -1, 1}, 
    Contours -> {#}, ContourStyle -> Directive[Black, Thick], PlotPoints -> 1000] & /@ 
    {1, .1, .03, .02}

Incidentally, I find surprising the amount of time and memory required to produce these simple plots. For instance,

LeafCount[First[%]]
(* 13718841 *)

Answer 1

Well, there is a workaround that induces more thinking.

Let's just observe that specifying PlotRangefor f based on the given functional form (it has a min of 0 and a max of 3 given the range of values for x, y, and z) works quite well:

SliceContourPlot3D[
   x^2 + y^2 + z^2, {x, -1, 1}, {y, -1, 1}, {z, -1, 1}, 
   Contours -> {#}, 
   PlotRange -> {Full, Full, Full, {0, 3}}
] & /@ {1, .1, .03, .02}

Note, however, that while the smaller contour next to the origin is gone, there is an error in the last graph when the contour value for f is the smallest. Let's investigate.

SliceContourPlot3D[
 x^2 + y^2 + z^2, {x, -1, 1}, {y, -1, 1}, {z, -1, 1}, 
 Contours -> Table[a, {a, 0, 3, 0.1}], 
 PlotRange -> {Full, Full, Full, {0, 3}}]

As we can see, despite the fact that we are starting from 0 in the increment of 0.1, there is a visible area next to the center, where there are no contours. We can zoom in and try to play with PlotPoints:

SliceContourPlot3D[
   x^2 + y^2 + z^2, {x, -1, 1}, {y, -1, 1}, {z, -1, 1}, 
   Contours -> Table[a, {a, 0, 3, 0.05}], 
   PlotRange -> {{-0.3, 0.3}, {-0.3, 0.3}, {-0.3, 0.3}, {0, 3}}, 
   PlotPoints -> #] & /@ {10, 50, 100}

Obviously, the result has nothing to do with the sampling of f (number of plot points), but exhibits a clear threshold. In this case, it is 0.025. Anything below this number is not going to be plotted as a contour, anything above -- works.

Here comes the question that I promised in the beginning. Why that number? I have experimented with ListSliceContourPlot3D giving it the data sampled with much smaller step, yet the magic number (it is actually slightly above that value) still holds for this particular function. It seems like a certain threshold below which the rendering engine doesn't want to draw, but I am not sure. Is that a bug? Maybe, but doesn't look like so. WorkingPrecision, MaxRecursionetc. don't matter at all.