[matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi, I saw that 3D plotting was dropped from matplotlib since the last time I used it. Unfortunately, it is pretty necessary for some of the work I am doing. Thus, I have started the process of refactoring the code to work with recent versions of matplotlib. Right now, it is still in very early stages and is quite flaky but I do have some functionality. In particular, I am able to do a regular 3d plot, a wireframe plot and a scatter plot. If this interests anyone I am making the code available via git. Instructions are available on my website at: http://jonathantaylor.ca/projects.shtml Feel free to send any patches my way. Best, Jon. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
That sounds reasonable. Can I ask what it is that was primitive? Having looked through the code I see that a few shortcuts were made to minimize the amount of code written that makes it especially susceptible to changes in the 2D code. That said, it seems like it was comparable functionally to matlab's 3d plots, which is my goal for it. Best, Jon. P.S. I saw your talk at NIPS 2008 this year. I have used mpl for a while now but that demo where you url.opened() yahoo finance and plotted it with those nice dates in 2/3 lines was very nice. ;) On Tue, Mar 3, 2009 at 9:14 AM, John Hunter wrote: > > > On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor > wrote: >> >> Hi, >> >> I saw that 3D plotting was dropped from matplotlib since the last time >> I used it. Unfortunately, it is pretty necessary for some of the work >> I am doing. Thus, I have started the process of refactoring the code >> to work with recent versions of matplotlib. >> >> Right now, it is still in very early stages and is quite flaky but I >> do have some functionality. In particular, I am able to do a regular >> 3d plot, a wireframe plot and a scatter plot. If this interests >> anyone I am making the code available via git. Instructions are >> available on my website at: > > That's great -- a number of people were very disappointed to see the > functionality removed, even though it was primitive compared to a good 3D > toolkit. The problem was, we could never find a core developer who was > interested in taking it under his wing. Once you get this to a satisfactory > point, I suggest you develop it as an mpl toolkit. That way, it will get > installed with every mpl distro (the plain vanilla toolkits we ship, the > complex ones like basemap are distributed separately) but without the > implicit promise of full support until someone is willing to step up and > offer to fully support it. > > JDH > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Great. I applied your patch and pushed it to the web repository. I agree, that some more serious refactoring might be good. I have been leaving comments throughout the code with my thoughts on this. Cheers, Jon. On Wed, Mar 4, 2009 at 4:53 AM, Reinier Heeres wrote: > Hi all, > > I was also a bit disappointed about the fact that 3d plotting support > was dropped. I'm happy to help out to get it going again, so here's a > patch to get surface plotting working; I'm busy with the contour plots > as well. > (We might want to do some code refactoring as well when it's functional). > > Regards, > Reinier > > On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley wrote: >> On Tue, Mar 3, 2009 at 11:39 AM, John Hunter wrote: >> >>> Well, it is painfully slow, since it does everything in software, and there >>> are some corner cases where the zorder clipping is broken in the presence of >>> alpha transparency, and it doesn't do lighting, shadows, etc But it >>> does do enough for basic stuff, so we would be happy if you could resurrect >>> it cleanly enough for a toolkit. >>> >> >> I'd just like to add that having a *bare minimum* 3D capability in mpl >> is extremely useful to me -- i.e. being to visualize 3D data as a >> point cloud or a wireframe mesh. While teaching with python and doing >> numerical experiments in my research it's invaluable to be able to >> throw together a wholly non-publication quality 3D plot to get a quick >> idea of what's going on. I would imagine that others who use mpl >> professionally (and not necessarily only for public consumption) would >> agree on the value of maintaining this bare minimum even if there is >> no short- or medium-term expectation that it will develop into >> anything more sophisticated. >> >> Cheers, >> Rob >> >> -- >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi Reinier, Awesome. Those plots are making me smile! I also agree with your refactoring and have applied your patch to my git repository. I agree with you concerning the sympy plotting routines. I think what we have here is quite flexible and does a very good job of replicating the equivalent functionality of MATLAB. I think it would be a huge effort trying to make 2D plots and 3D plots look consistent if another approach was taken. Indeed, this is a desirable characteristic. In addition, the code is actually very short and easy to maintain. Given that matplotlib has had trouble maintaining 3D code in the past, it might not be a good idea to switch to a more complicated codebase. You should grab some of my more recent changes as I have added a few more fixes. Most importantly, if you reuse the same figure, the old event handlers will still attached preventing Axes objects from dieing and causing interactive manipulation of the plots to be very sluggish. Also, in terms of performance, I have found that switching to TkAgg from GTKAgg was helpful. Also, I think the original code from John Porter was under a BSD license. I am thinking of adding our names and the BSD license to the top of each file to protect it while its not officially part of matplotlib. What do you think? Best, Jonathan. On Sun, Mar 8, 2009 at 8:04 PM, Reinier Heeres wrote: > Hi, > > I've done some further refactoring of mplot3d: > > - Almost all of the test plotting functions work, except for > test_bar2D. Filled contours are not perfect yet and need a bit more > work. Try "python axes.py" with the attached files to see how it > looks! > > - I removed the Wrap2D class, which was using private class members > throughout. I replaced this approach with dynamically changing the > class type for Artist objects (e.g. PolyCollection to > Poly3DCollection). This is also a bit of voodoo, but I think in the > end it results in a bit less code, which is also more readable. > > - Much more code could still be removed (and added again later if necessary) > > Regards, > Reinier > > BTW: I think plugging sympy's plotting functionality into matplotlib > would not be so easy! The mplot3d code is much better suited for > this... > > On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux > wrote: >> On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote: >>> Nevertheless, I hate to think of matplotlib sending people to mayavi2 each >>> time 3D plotting is needed. Basic functionalities built-in would still be >>> highly desirable. >> >> Absolutely. I think we need basic 3D plotting functionnality that work >> without any 3D rendering library, both for robustess and for simplicity. >> >> I used to think different, because I believe that this approach is bound >> to fail on anything but very simple problems (my experience with gnuplot >> :>). I fear people are going to try and pull too far the simple 3D >> implementation. >> >> Nevertheless, it would be great to have some 3D in matplotlib, for easier >> mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary >> file, loading the result with matplotlib's imread, and displaying it with >> an imshow -- ugly!), and to have backend-universal, robust, 3D plotting. >> >> Gaël >> >> -- >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code:
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi, Thanks for the patch. How slow is it for you? I find it slow but quite usable. The main problem, I imagine, is that sympy is using OpenGL and thus your graphics card performs all the 3d -> 2d rendering whereas we do much of this in python/numpy. When I get a chance I am going to see if I can somewhat speed some of it up by adding an optional module to perform a few of these operations in C. Jon. On Sun, Mar 8, 2009 at 11:37 PM, Ondrej Certik wrote: > On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor > wrote: >> Hi Reinier, >> >> Awesome. Those plots are making me smile! I also agree with your >> refactoring and have applied your patch to my git repository. >> >> I agree with you concerning the sympy plotting routines. I think what >> we have here is quite flexible and does a very good job of replicating >> the equivalent functionality of MATLAB. I think it would be a huge >> effort trying to make 2D plots and 3D plots look consistent if another >> approach was taken. Indeed, this is a desirable characteristic. In >> addition, the code is actually very short and easy to maintain. Given >> that matplotlib has had trouble maintaining 3D code in the past, it >> might not be a good idea to switch to a more complicated codebase. >> >> You should grab some of my more recent changes as I have added a few >> more fixes. Most importantly, if you reuse the same figure, the old >> event handlers will still attached preventing Axes objects from dieing >> and causing interactive manipulation of the plots to be very sluggish. >> Also, in terms of performance, I have found that switching to TkAgg >> from GTKAgg was helpful. >> >> Also, I think the original code from John Porter was under a BSD >> license. I am thinking of adding our names and the BSD license to the >> top of each file to protect it while its not officially part of >> matplotlib. What do you think? > > A trivial patch is attached to make proj3d.py work. > > I tried the examples and it looks great. However, it's pretty slow, at > least on my machine. The plotting in sympy is much faster. Is there > some way to make the mplot3d faster? > > Ondrej > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Just because we are using all the 2D drawing code to make the plots, which is why the 3d code is so small, maintainable and is visually consistent with 2D matplotlib. I believe that moving to OpenGL would require a substantial effort. J On Mon, Mar 9, 2009 at 12:17 AM, Ondrej Certik wrote: > On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor > wrote: >> Hi, >> >> Thanks for the patch. How slow is it for you? I find it slow but > > Well, when I use mouse to rotate the image, I can see that it lags behind. > >> quite usable. The main problem, I imagine, is that sympy is using >> OpenGL and thus your graphics card performs all the 3d -> 2d rendering >> whereas we do much of this in python/numpy. When I get a chance I am >> going to see if I can somewhat speed some of it up by adding an >> optional module to perform a few of these operations in C. > > Why not to use OpenGL as well? > > Ondrej > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Sure, I thought it was going to the list too ;) So no problem. I am not sure what you can do with that module. It seems a shame to waste. Perhaps it should be split out into a seperate 3d only plotting library that cares less about being matplotlib'ish than something packaged with MPL would. What do you think? Jon. On Mon, Mar 9, 2009 at 5:36 PM, Ondrej Certik wrote: > On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik wrote: >> I posted only to you by a mistake -- can I reply to the list? > > Oops, I posted to the list by mistake too -- sorry about it. Anyway, > here is the email that I sent to Jonathan only by a mistake: > > On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor > wrote: >> Just because we are using all the 2D drawing code to make the plots, >> which is why the 3d code is so small, maintainable and is visually >> consistent with 2D matplotlib. I believe that moving to OpenGL would >> require a substantial effort. > > Ok, now I understand the motivation. So if one wanted to go the OpenGL > route, it would have to be created as a matplotlib backend? Then the > 3D plots would be fast enough. > > Ondrej > > > > and he replied in my previous email, that I just wanted to ask if I > can post to the list. > > Ondrej > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi, that is great! Can you give me a git repository address to pull from? I can't from the web viewer. Thanks, J. On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres wrote: > Hi, > > I updated my patch a bit more, and now all tests are running (try > "python axes3d.py"). Only the contourf3D is not working correctly yet, > but I'm sure it's fixable soon. There are also some obvious bugs (e.g. > the semi-3D histograms are not depth-sorted). > > Anyway, I have applied the commit in a different git repo that also > has gitweb.cgi for viewing: > http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary > > Jon, I got rid of the spurious commit-and-revert entries but included > your latest commits; perhaps you can clone from this tree now? > > Although I've not had a close look at the BSD license it definitely > sounds like a good idea to add it if it applies to the original code. > Shall we try to work to some sort of easily-installable form of the > again-working code? > > Regards, > Reinier > > On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor > wrote: >> Hi Reinier, >> >> Awesome. Those plots are making me smile! I also agree with your >> refactoring and have applied your patch to my git repository. >> >> I agree with you concerning the sympy plotting routines. I think what >> we have here is quite flexible and does a very good job of replicating >> the equivalent functionality of MATLAB. I think it would be a huge >> effort trying to make 2D plots and 3D plots look consistent if another >> approach was taken. Indeed, this is a desirable characteristic. In >> addition, the code is actually very short and easy to maintain. Given >> that matplotlib has had trouble maintaining 3D code in the past, it >> might not be a good idea to switch to a more complicated codebase. >> >> You should grab some of my more recent changes as I have added a few >> more fixes. Most importantly, if you reuse the same figure, the old >> event handlers will still attached preventing Axes objects from dieing >> and causing interactive manipulation of the plots to be very sluggish. >> Also, in terms of performance, I have found that switching to TkAgg >> from GTKAgg was helpful. >> >> Also, I think the original code from John Porter was under a BSD >> license. I am thinking of adding our names and the BSD license to the >> top of each file to protect it while its not officially part of >> matplotlib. What do you think? >> >> Best, >> Jonathan. > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > -- > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi John, You should be able to check out a copy from my git repo via git clone http://jonathantaylor.ca/mplot3d.git cd mplot3d git pull I am missing Reiniers final update though but you should be able to run demo.py and the first few examples in the __name__ == '__main__' clause of axes3d.py. Best, J. On Wed, Mar 11, 2009 at 2:21 PM, John Hunter wrote: > > > On Wed, Mar 11, 2009 at 3:25 AM, Reinier Heeres wrote: >> >> Hi, >> >> I updated my patch a bit more, and now all tests are running (try >> "python axes3d.py"). Only the contourf3D is not working correctly yet, >> but I'm sure it's fixable soon. There are also some obvious bugs (e.g. >> the semi-3D histograms are not depth-sorted). >> >> Anyway, I have applied the commit in a different git repo that also >> has gitweb.cgi for viewing: >> >> http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary >> >> Jon, I got rid of the spurious commit-and-revert entries but included >> your latest commits; perhaps you can clone from this tree now? >> >> Although I've not had a close look at the BSD license it definitely >> sounds like a good idea to add it if it applies to the original code. >> Shall we try to work to some sort of easily-installable form of the >> again-working code? > > One thing you can do is send a patch against lib/mpl-toolkits and I'll apply > it to svn trunk. > > I was briefly scrolling through the recent diffs on art3d, and noticed > > + try: > + zs = float(zs) > + zs = [zs for i in range(len(paths))] > + except: > + pass > > Except in very special cases, we do not allow blanket excepts -- eg you > should catch explicitly the error you are trying to trap. Also, it is > usually better to try just the part you are trying to catch and then do the > rest in an else. So if you are trying to catch the case where zs is not a > float > > try: > zs = float(zs) > except TypeError: > pass > else: > zs = [zs for i in range(len(paths))] > > > Also, again I am not excatly sure what you are trying to do here, mpl has > "duck typing" helpers to test whether something is iterable or num-like. So > you can do > > > import matplotlib.cbook as cbook > if not cbook.iterable(zs): > zs =float(zs) > zs = [zs for i in range(len(paths))] > > Anyway -- great work so far. I'm having trouble making a git co work so I > am looking forward to testing this when you have a snapshot or svn diff. > > JDH > > -- > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mplot3d questions
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 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 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 w
Re: [matplotlib-devel] Mplot3d questions
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 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
Re: [matplotlib-devel] git migration
> I am strongly in favor of keeping the entire commit history of > trunk/matplotlib. While the repo is large now, most of the size comes > from data and regression test images, and the early history is largely > code so will not add much incremental size. I suppose one of the > downsides of git is since you have to get the *entire* history on one > checkout, you end up with a bunch of stuff you are unlikely to ever > need, like data that was once in the repo but has now been removed (eg > the stuff we migrated to sampledata). Not sure if there is an easy > solution here. I think you should be able to use git clone --depth=x to get a shallow copy of the repository. The limitation is that you cannot push from or pull from your new repository. You can pull to it and create patches though, which is enough for most people I think. Best, Jon. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
