Incorrect mplot3d contourf rendering

[ddale]

Original report at SourceForge, opened Tue Nov 23 03:11:06 2010

There is a bug in mplot3d's rendering of filled contours. Attached is a simple test script to reproduce the error: the 2D plot on the left shows the desired result, the 3D plot on the right shows the holes in the contour are not rendered correctly.

Digging around in axes3d.py and art3d.py, I think the problem is that mplot3d ignores the 'codes' that are produced by the 2D contourf routine. I am probably not using the correct terminology, but I understand that these codes allow a polygon to be composed of multiple line loops, some of which may be holes within other line loops. By ignoring the codes, the 3D routine renders a single polygon by concatenating all the points together regardless of whether they correspond to a hole or not.

In revision 8806 of lib/mpl_toolkits/mplot3d/art3d.py, lines 136-7:

for (((x, y), code), z) in zip(pathsegs, zs):
seg.append((x, y, z))

The codes are extracted from the pathsegs (which come from the 2D contourf routine), but then ignored.

I've taken a look at trying to fix this, but it was not obvious to me how to propagate the 'codes' rendering functionality from the 2D to 3D source code. Perhaps someone more familiar with mplot3d could look at it.

SourceForge History

• On Tue Nov 23 03:11:07 2010, by ianthomas23: File Added: 394120: bug3d.py

[WeatherGod]

This problem is nearly identical to report #186.

[ianthomas23]

This needs to be solved before #395 can be.

[WeatherGod]

So, it is in your opinion that a proper Path3D class would be the next crucial feature for mplot3d?

[ianthomas23]

I don't know enough about mplot3d development to express an opinion on this; I know you have been very busy improving it but I don't really know where it is at now or where it is heading. I was just trying to make the point that tricontourf examples would be a bit premature until we have contourf rendering properly in 3D.

Incidentally, 3D tricontour(f) is perhaps a bit of a red herring. It was added following a user-submitted patch which did what that user wanted but not the other possibilities that 2D tricontour supports. Unfortunately the patch was checked in before I had a chance to write the correct full solution.

[dmcdougall]

@WeatherGod Do you have example code that shows what's going on in the ouput? Maybe I can take when I have a spare moment.

[WeatherGod]

I believe this is the script. However, it might be for #186.

import numpy as np

##*********************************************************
##*********************************************************

## 2D collection
import matplotlib.pyplot as plt
import matplotlib.collections as collections



vertsQuad = [ [ [0.,0.], [0.,1.], [1.,1.], [1.,0.] ],
          [ [0.,1.], [2.,3.], [2.,2.], [1.,1.] ],
          [ [2.,2.], [2.,3.], [4.,1.], [3.,1.] ],
          [ [3.,0.], [3.,1.], [4.,1.], [4.,0.] ]]

#vertsQuad = np.array([ [0, 0], [0, 1], [2, 3], [4, 1], [4, 0], [3, 0],
# [3, 1], [2, 2], [1, 1], [1, 0] ])

## 3D collection
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.cm as cm # colormaps

fig = plt.figure()
ax = Axes3D(fig)

colors = ['r', 'g', 'b', 'y', 'k']
zpos = [0,1,2,3,4]

#verts = [vertsQuad] * len(zpos)

#for i, c in zip(zpos, colors):
poly = collections.PolyCollection(vertsQuad * len(zpos), linewidth=0.25)
poly.set_alpha(0.7)# collection transparency (opaque == 1), needed for projection bug workaround!
#poly.set_color('r')

## need to have a z-value for *each* polygon = element!
zs = []
cs = []
for z, c in zip(zpos, colors) :
    zs.extend([z] * len(vertsQuad))
    cs.extend([c] * len(vertsQuad))

poly.set_color(cs)

ax.add_collection3d(poly, zs=zs, zdir='y')

## axis limit settings:
ax.set_xlim3d(0,4)
ax.set_zlim3d(0,3)
ax.set_ylim3d(0,4)
#ax.set_title(title)
ax.set_xlabel('x')
ax.set_ylabel('slice')
ax.set_zlabel('y')

#pylab.draw()
plt.show()

I'll dig around to see if I have another.

[WeatherGod]

I believe this has been fixed when #4784 was fixed. Since we lost the original script demoing the bug, I can't confirm one way or the other, but we do now respect the path code info now.