Re: [matplotlib-devel] Mplot3d questions

[Jonathan T. <jt...@cs...>]

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 <jt...@cs...>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 <BAx...@co...>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&#174; 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>