Um can it be split up into three subplots, one for each axes?

Just thinking through that while pretty, it might be a bit hard to follow from a "what do I do to make this slice for one axes"?

No. The point here is to illustrate multiple intersecting planes in one subplot, which requires the quadrant subdivision for correct drawing order.

This is somewhat inherently complex (with current API (?)) due to the involved indexing. Note also that indexing will get even worse if you don’t split in the center (which I thus have refained from to generalize to). I rather see this as an illustration/proof of concept how you can work around limitations of the 3d rendering.

Separate planes (well, one would be enough then) is a simpler example that should be done separately. Also note that drawing a single color-coded plane is currently already quite a hassle because you have to use plot_surface. Some quadmesh like function to draw axes-aligned planes from 2D arrays would be reasonable. But that’s even a bigger topic.

This is somewhat inherently complex (with current API (?)) due to the involved indexing.

My concern more is that in this case the complexity/way that it's written may make it hard to unravel and tweak for someone who wanted to make something similar but not identical.

I wonder if this would work better as a tutorial where these stages were also included:

• Separate planes (well, one would be enough then) is a simpler example that should be done separately.
• Also note that drawing a single color-coded plane is currently already quite a hassle because you have to use plot_surface

And build up to the figure above.

My concern more is that in this case the complexity/way that it's written may make it hard to unravel and tweak for someone who wanted to make something similar but not identical.

It is difficult, but better than nothing at all. We don't have the capacity to pamper users for every edge case.

I'm -0.5 on a tutorial. First, I'd like to have both the separate plane and the intersecting plane show up in the gallery overview. Second, going into an extensive tutorial for working around limitations and insufficiencies of our API feels the wrong way. It would be better to invest that time into improving the API, i.e. the quadmesh-like parallel-axes plane.

But as always, if you are convinced that a tutorial is worth the effort, you are free to create one.

We don't have the capacity to pamper users for every edge case.

Maybe the solution is more code comments and not wrapping the figure code in figure_3D_array_slices, but my concern is that the example as written might be hard to modify and cross apply to a slightly different use case, which I think is the core purpose of examples and not an edge case. And a very consistent complaint about the examples is that they tend to do too much in a way where it's hard to see what code is responsible for which aspect of the visualization.

Second, going into an extensive tutorial for working around limitations and insufficiencies of our API feels the wrong way. It would be better to invest that time into improving the API, i.e. the quadmesh-like parallel-axes plane.

I think of it more as a tutorial showing how to use the existing API to build something that the API doesn't provide out of the box, but yeah if a new function makes more sense than I'm not opposed to that.