Thank you for your work on this.

If I am understanding the test example correctly, one of the quadrants sets the z value toinf which by some mechanism messes with the z-sorting of between the other quadrents:

importmatplotlib.pyplotaspltimportnumpyasnpfig=plt.figure()ax=fig.add_subplot(projection="3d")x,y=np.mgrid[-2:2:0.1,-2:2:0.1]z=np.sin(x)**2+np.cos(y)**2z[x.shape[0]//2 :,x.shape[1]//2 :]=np.infax.plot_surface(x,y,z,cmap="jet")ax.view_init(elev=45,azim=145)

vs what it should look like (a different angle)

I agree something is definitely wrong, but I suspect it may be better to fix this in the code inCollection3D that sorts the patchs rather than by dropping all non-finite data on the floor.

There has been a push recently to make the 2D mesh-like methods do a better job of holding onto the shape of the originally passed in data (to make it easier to update x / y / color / ... after the fact). We have not (to my knowledge) done anything similar with the 3D methods yet, but we may want to go that way eventually. This also suggests that the right place to filter out the non-finite data is in the sorting step, not in the "what data are we holding" step.

I agree something is definitely wrong, but I suspect it may be better to fix this in the code in Collection3D that sorts the patchs rather than by dropping all non-finite data on the floor.

That was my initial guess too, but the linked issue pointed towards this dataset-cleaning approach.

We have not (to my knowledge) done anything similar with the 3D methods yet, but we may want to go that way eventually. This also suggests that the right place to filter out the non-finite data is in the sorting step, not in the "what data are we holding" step.

What I am afraid of is the additional complexity of having to filter the dataset whenever it's needed, eg. before the z-sort, before computing the colormap min/max values, etc. However, if the general consensus is to remove the preliminary data filtering I'd be happy to send another patch soon.

Friendly ping.

Fundamentally, I agree with@tacaswell that the Collection should hold all data, and handling of nan and inf should be done in there.

Given that the nan handling was already implemented on the outer level in#20725, it is bearable to extend that logic to include inf values as well. It's an improvement in the sense, that we fix a buggy plot. We'll anyway have to do an API change for the existing code when we want to move nonfinite data handling into the 3D Collections.

Can this still go to 3.8?