Digging through mplot3d (again), I have come to realize that a lot of its code in art3d.py could be simplified if we had a way to tell collection objects in what order to draw their elements.
My proposal is fairly straight-forward. All collections would have an internal _zdraworder attribute that can be anything that can index a numpy array: slice(), array of indices, whatever. The draw() methods will then iterate over their elements returned by indexing with _zdraworder. This will help keep the bookkeeping to a minimum, because everything should be sliced/indexed the same way: offsets, verts, facecolors, etc.
The default value will be slice(None), so nothing will change for regular collections.
With this, mplot3d can greatly simplify its logic and semantics by focusing on projecting and setting the _zdraworder by running np.argsort() on the projected depth of the elements. Another advantage is that methods like get_facecolors() and set_facecolors() can round-trip in mplot3d (right now, get_facecolors() has to return a z-sorted version of the colors for drawing).
For now, I imagine keeping this a private attribute, but I could see some really fancy tricks in the future such as using boolean indexing to mark some elements as visible/invisible, and doing some neat tricks for animations.
Thoughts?
Ben Root
Looking at collections.py, it looks like TriMesh might also benefit from this, as it has specialized code for masking out triangles and determining the order of the triangle elements.
Ben Root
···
On Sat, Feb 7, 2015 at 7:18 PM, Benjamin Root <ben.root@…553…> wrote:
Digging through mplot3d (again), I have come to realize that a lot of its code in art3d.py could be simplified if we had a way to tell collection objects in what order to draw their elements.
My proposal is fairly straight-forward. All collections would have an internal _zdraworder attribute that can be anything that can index a numpy array: slice(), array of indices, whatever. The draw() methods will then iterate over their elements returned by indexing with _zdraworder. This will help keep the bookkeeping to a minimum, because everything should be sliced/indexed the same way: offsets, verts, facecolors, etc.
The default value will be slice(None), so nothing will change for regular collections.
With this, mplot3d can greatly simplify its logic and semantics by focusing on projecting and setting the _zdraworder by running np.argsort() on the projected depth of the elements. Another advantage is that methods like get_facecolors() and set_facecolors() can round-trip in mplot3d (right now, get_facecolors() has to return a z-sorted version of the colors for drawing).
For now, I imagine keeping this a private attribute, but I could see some really fancy tricks in the future such as using boolean indexing to mark some elements as visible/invisible, and doing some neat tricks for animations.
Thoughts?
Ben Root