On Fri, Apr 15, 2011 at 3:54 PM, John Hunter <jd...@gm...> wrote: > > > On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...> wrote: > >> >> There might be a possible work-around, though. Maybe (and I am just >> speculating here) if we can get the core part of matplotlib to specially >> treat 3d collection objects in such a way that allows the collection to >> return provide elements and z-order pairs. It is either that, or we finally >> try to get OpenGL working again in matplotlib and allow ourselves to specify >> coordinates in 3-D. >> >> > It should be fairly easy to get a collections object to support multiple > z-orders *within* the collection. Across artists, damn near impossible. I > don't think you need to provide elements and z-order pairs per-se. The > typical way a property is specified for a collection if you want it to vary > over the elements of the collection is that the property is a sequence, and > the property is accessed as prop[i%N] where i is the element number and N is > the length of the property vector. So if we make zorder a len(elements) > sequence of z-orders, we can order the collection by the zorder at draw > time. Presumably external code would modify the zorder of the collection > before each draw depending on the view. > Within a collection, this is already done correctly (or at least, as well as one can except with a 2D rendering engine). It is when you have multiple artists that exists over parts of the z-order "axis" that there are problems. Essentially, if the 3-D bounding boxes overlap, then trouble ensues. Also, that speculation I had wouldn't work either, as the problem still would exist for intersecting patches. No, what we really need is a 3D rendering engine, and a logical separation between z-order for sorting/layering and z-coordinates. Ben Root