Ben.
Sorry I did not see the other posts surrounding mplot3d or your patch. I am
very excited to have that though. Thank you.
My opinion about a redesign still stands though.
Jon.
On Thu, Feb 25, 2010 at 11:16 PM, Jonathan Taylor <jtay...@cs.toronto.edu>wrote:
> Hi,
>
> I cannot answer your questions specifically but perhaps I can provide some
> insight. My current understanding is that most of mplot3d is a bit of a
> hack. I say this because I use it daily and I was the one who hacked it
> into a half working state out of necessity after it was originally fell out
> repair. Reiner finished the job in terms of returning it to its original
> usability.
>
> Unfortunately, it still has many warts. Part of the problem is that
> matplotlib continues to evolve and add features that we have not added to
> mplot3d. I think that part of the reason this is happening is because it is
> not easily apparent what works and what does not. Indeed, the classes in
> mplot3d such as axes3d, axis3d, etc inherit from the mainline 2d classes
> axes, axis, etc. Thus it appears that methods have been implemented simply
> because the 3d objects have inherited them. This just gets worse as the 2d
> classes add more features. This causes a lot of frustration for users as
> sometimes these methods work by fluke and sometimes don't. Even worse is
> that it is possible for an addition to some 2D code to call a method that
> has not been masked in the 3D object causing a breakage.
>
> The reason this happened in the first place is that the original author
> realized that a lot of the 2d code could be reused to render a 2d view of
> the 3d space. I think that this reuse is a good idea but I think it would
> be much better if this was done more explicitly instead of using
> inheritance. In particular, I think that Axes3D should not inherit from
> Axes and simply contain an Axes object stored in self.axes. Then each
> method that is actually supported can be explicitly written and
> appropriately proxied to self.axes.method.
>
> I have been thinking about trying to do a rewrite as I describe above for
> some time. I think that this would not only make it easier for users but
> would make a much clearer code base in which it was more obvious how someone
> could contribute. Alas, I have not found the time to do this, but perhaps
> in a month. ;)
>
> The other issue is that of speed. In the longer term, that can be
> addressed more easily. It will be a lot more work and more complicated but
> I am guessing that what needs to be done is a complete rewrite in something
> like OpenGL. That said, I am not sure how well this would work and if there
> are complications with ipython and threading, etc. I would be interested to
> know what people think about this.
>
> I realize that I did not answer your questions except to provide some
> insight as to why mplot3d behaves oddly sometimes. Sorry ;)
>
> Best,
> Jonathan.
>
>
> On Thu, Feb 25, 2010 at 12:14 PM, Ben Axelrod <baxel...@coroware.com>wrote:
>
>> Hi Reinier,
>>
>> Here are a number of issues in mplot3d that I would really like fixed, but
>> can't quite figure out. I would very much appreciate some feedback from you
>> on these. (Where to start, what might be the cause, how hard is the fix...)
>>
>> * Global 3d object sorting. Not just for polygons, but all 3d objects
>> like lines, and text as well. These objects have z values after all, so
>> should be able to be placed in some sort of global z buffer.
>>
>> * When I implement 'picking' for bar3d plots, how can I know which bar
>> was picked? In the picker callback, the event.artist is a Poly3DCollection
>> object. I can call event.artist.get_paths() to get all the polygon paths,
>> and determine which one the mouse click was in. But this data does not have
>> any 'z' data. So, this will find 2 faces for the box you clicked. (You may
>> get many more results from other boxes as well). And even with this data, I
>> am unable to determine which box the path corresponds to. I can think of a
>> few solutions:
>> - Store some kind of data in Poly3DCollection corresponding to all path
>> polygons, *with* the real world data so they can be matched up. (maybe this
>> is already the case?)
>> - make some kind of Bar3DPath class that inherits from Path which
>> contains an extra data field to store the index of the bar the path belongs
>> to. It should probably also store the real world coordinates and the screen
>> z value as well.
>> - override some pick event method and do this logic in the mplot3d code
>> so that the user's picker callback can simply use event.ind to get the bar
>> index that was picked. just like the pick event for scatter().
>>
>> * picking does not seem to work for the 3D axis labels. The normal
>> 'picker=True' parameter of set_xlabel(), set_ylabel() , and set_zlabel()
>> does not seem to make the axis label pickable. Other 2d and 3d text on the
>> plot is pickable however. It may be possible that the Axis3D object does not
>> add the label to the Axes3D's list of artists. Which means it doesn't get
>> searched for and found in Axes.__pick().
>>
>> * Is it possible to make 3d bars with transparent faces, so that they
>> appear wireframe? I am pretty sure that patches support this, but I think
>> the fancy face coloring bar3d does overrides the 'none' color specification.
>>
>> * How can I set axis tick label properties for 3D axes? This code does
>> not work on Axes3D, but it works for normal 2D axes:
>> setp(ax.get_xticklabels(),
>> color='r'). Furthermore, there is no such ax.get_zticklabels(). Is there
>> another way that this must be done? How can we support the
>> setp(ax.get_zticklabels(),
>> color='r') paradigm?
>>
>> Thanks!
>> -Ben
>>
>>
>> *Ben Axelrod*
>> Robotics Engineer
>> (800) 641-2676 x737
>> www.coroware.com
>> www.corobot.net
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
