attn @WeatherGod

It looks like the zsort logic from Poly3DCollection needs to be ported to Path3DCollection as well.

Indeed. I think this has been noticed before in the theoretical sense, but
no one until now has provided an actual example of it performing really
badly. IIRC, this was one of my motivations for #4090, which would have
brought proper z-order handling across all collections, and potentially
allow for intra-collection ordering as well. I never had the time to really
pursue it, though.

On Mon, Jan 11, 2016 at 7:54 AM, Thomas A Caswell [email protected]
wrote:

attn @WeatherGod https://github.com/WeatherGod

It looks like the zsort logic from Poly3DCollection needs to be ported to
Path3DCollection as well.

—
Reply to this email directly or view it on GitHub
#5830 (comment)
.

Just a minor addition. I've run into what I assume is the same bug. But I tracked down the particular elevation at which the problem occurs for me: 48.02450 degrees. Maybe this is just down to the peculiar particulars of precisely my problem, but maybe you could find it an interesting test or helpful in some other way. I've gisted the example here.

I've run into this with the z-order of markers not applying on top of a surface plot. It's the same as in @moble 's gist.

The problem here is that the drawing order of the patches needs to change when the camera view changes so that the patches that are behind others wrt the line of sight get drawn first. The order of the patches is decided upon initializing the PathCollection, but in this case, where all the patches are the same, we can reorder them at draw time by the distance from the camera position like this (with inspiration from my SO answer to a similar related problem):

import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D

def get_camera_position(ax):
    """returns the camera position for 3D axes in cartesian coordinates"""
    r = np.square(ax.xy_viewLim.max).sum()
    theta, phi = np.radians((90 - ax.elev, ax.azim))
    return np.array(sph2cart(r, theta, phi), ndmin=2).T

def sph2cart(r, theta, phi):
    """spherical to cartesian transformation."""
    x = r * np.sin(theta) * np.cos(phi)
    y = r * np.sin(theta) * np.sin(phi)
    z = r * np.cos(theta)
    return x, y, z

def reorder_camera_distance():
    """
    Sort the patches (via their offsets) by decreasing distance from camera position
    so that the furthest gets drawn first.
    """
    # camera position in xyz
    camera = get_camera_position(ax)
    # distance of patches from camera
    d = np.square(np.subtract(camera, patches._offsets3d)).sum(0)
    o = d.argsort()[::-1]

    patches._offsets3d = tuple(np.array(patches._offsets3d)[:, o])
    patches._facecolor3d = patches._facecolor3d[o]
    patches._edgecolor3d = patches._edgecolor3d[o]
    # todo: similar for linestyles, linewidths, etc.... 

def on_draw(event):
    reorder_camera_distance()

# MWE
x = np.array([-1, 0, 1])
y = np.array([0, 0, 0])
z = y

fig, ax = plt.subplots(subplot_kw=dict(projection='3d'))
patches = ax.scatter(x, y, z, s=2500, c=x)

# connect to draw event (re-orders patches each time the canvas draws)
fig.canvas.mpl_connect('draw_event', on_draw)

Things should now be drawn in the correct order irrespective of the viewing angle.

Using the data from your gist:

Might be addressed by #15594.

Indeed, I wasn't aware of that PR since it wasn't linked here, but from what I can tell it should fix this issue.

Really? To me it looks like #15594 just sorts along z and does not take the distance to the "camera" into account? Edit: seems I misinterpreted some of the variable names. Ignore this.

@ImportanceOfBeingErnest Yes, I personally find this section of code quite opaque, partly due to the choice of variable names, sparse comments and lack of docstrings...

Should be fixed by #17378.