Re: [Matplotlib-users] mplot3d stays?
Things become more and more complicated with time. I come up with four things to consider: First the ring I already mentioned is visualised in attachment Ring.png. A > C > B > A, no z sorting possible, because no linear order anymore. Second, the intersecting line may not always separate a tringle in front as in your example, see "Fourangle".png. Though either the front or the back part of the intersected tringle is always a triangle. Furthemore, I suggest to cut both tringles along the intersection line. This makes things easier to implement, I'm quite convinced. Third, z sorting. How does the current algorithm I didn't understand work? One may consider pict z-sorting.png. For a simple-minded algorithm comparing the center of mass, the triangle in front seems to be at higher z. Fourth, detection of intersection. With the algorithm I proposed, I assume non-intersecting triangles. The problem is how to detect intersection at all. One might think that it's sufficient to check in the corners for inconsistencies with non-intersection. But unfortunataly, it isn't like that. In pict Tricking.png is an example. An algorithm checking the corners will find out that [red] is in front of [green], and nothing more, and hence cannot conclude towards intersection. I have no straightforward idea? One idea more: Not leaving B in your example triangles.png intact, but creating two new planar convex 4-polygons, filling those with triangles is very easy and straightforward. Thus it works out for A and B as pointed out in triangles2.png. Thus 1. detect intersecting triangles and cut them into pieces, second apply z sorting or equivalents? I had implemented z sorting for pairs of triangles already, and would like to compare with the mplot3d algorithmic idea. Using this, one could simply let a sort algorithm of any kind do the job. Apart from that results may look strange when there are rings :-) 2010/2/28 Ben Axelrod : > Interesting, but I think subdividing triangles like this is unnecessary. For > most cases, when one triangle completely covers the other, all that is > required it to Z order the triangles. This is what mplot3d does already. > The only case we have yet to handle is when one triangle "pierces" the other. > As seen in the attached image. Triangle B is mostly behind triangle A, > except for a small piece labeled C. All we would have to do is determine the > line of intersection, then create a new triangle C. Then we just draw B > first, then A, then C. > > I think the hardest part is probably doing this for general polygons and > handling the edges properly. But that should not be super hard. Hmm. First I thought: One should create pathes of lines and patches of surfaces. The lines do not need to be z ordered at all, they just have to be z ordered against the surfaces. But that's not sufficient, because lines /on/ surface may be drawn before the surface or not, at random, spoiling the thing. Maybe have for each triangle outline attributes? I guess that's what you had in mind from the beginning. Friedrich <><><><><>-- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Interesting, but I think subdividing triangles like this is unnecessary. For most cases, when one triangle completely covers the other, all that is required it to Z order the triangles. This is what mplot3d does already. The only case we have yet to handle is when one triangle "pierces" the other. As seen in the attached image. Triangle B is mostly behind triangle A, except for a small piece labeled C. All we would have to do is determine the line of intersection, then create a new triangle C. Then we just draw B first, then A, then C. I think the hardest part is probably doing this for general polygons and handling the edges properly. But that should not be super hard. -Ben From: Friedrich Romstedt [friedrichromst...@gmail.com] Sent: Saturday, February 27, 2010 11:28 AM To: matplotlib-users Subject: Re: [Matplotlib-users] mplot3d stays? http://www.friedrichromstedt.org/python/pyclip/a01.Zerteilung.pdf (It's unfortunately in german, but the graphics are self-explaining) A school mate working together with me on the project has worked that out. H = number of corners of the front triangle lying inside of the back triangle V = number of corners of the back triangle lying inside of the front triangle S = number of the collinear edges of the two triangles Z = number of intersection points of the two tringles' edges, minus the number of those occuring because of collinear edges. Red: front triangle Black: back triangle Green: subdivision lines in the back triangle. I will check my implementation in C++ today. I will maybe need some advice in making a Python module out of it. Friedrich -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users <>-- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
http://www.friedrichromstedt.org/python/pyclip/a01.Zerteilung.pdf (It's unfortunately in german, but the graphics are self-explaining) A school mate working together with me on the project has worked that out. H = number of corners of the front triangle lying inside of the back triangle V = number of corners of the back triangle lying inside of the front triangle S = number of the collinear edges of the two triangles Z = number of intersection points of the two tringles' edges, minus the number of those occuring because of collinear edges. Red: front triangle Black: back triangle Green: subdivision lines in the back triangle. I will check my implementation in C++ today. I will maybe need some advice in making a Python module out of it. Friedrich -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
> I also agree with Reinier. I want my 3d plots to look as close as possible > to my 2d plots. Because mplot3d uses so much of the same matplotlib core, > this is trivial. As Friedrich mentioned, the mplot3d code is actually pretty > small. To me, that is a great feature. I found the mplot3d code very > accessible. Yes, I agree that it's really readable. But I didn't understand the sorting algorithm in plot_surface(). > I do agree that there is still much work to be done in mplot3d. But I think > starting from scratch is a waste of time. Well, I see ... When I write code "from scratch" as I often do, I mean to open a new file and to copy old code only if it useful or necessary. So I don't want to break the old code. I in fact think the current code is doing good work. But to my perception, it nevetheless needs some additional concepts like the global "surface space" and another sorting algorithm. > FYI, I looked into using mayavi2 before settling on mplot3d. Mayavi can > create some stunning graphics, but I found that it is very restrictive in its > plotting options. Take for example the 3d scatter plot. They combined the > size and color parameter. Getting around this strange restriction took me > quite some time. (Installation for me was also a pain due to VTK). That's important information, at least for me. I was so impressed by mayavi, that I was near to be stopped from all enthusiasm for mplot3d. But I see, there would be some use. The arguments you gave are already quite strong. I think the possibility to plot 2d things in 3d context like a stack of curves using the matplotlib style seems to be quite a good thing, isn't it? I would like to tell some "fresh look" onto the problem just coming into my mind. What about turning matplotlib itself into the 3D rendering engine? This would maybe be like a fork. But it would leave all matplotlib commands intact, putting the layer like this: matplotlib -- 3D rendering engine -- backend Instead of: 3D rendering engine matplotlib backend. I mean, the matplotlib would create some kind of plotting commands, either 2d or 3d. The 3d ones would be translated into 2d camera space by the intersecting layer. 2d ones would be promoted to the 3d camera space before being projected into the 2d camera space. This is a raw idea, I'm shure, so please don't kill me for it. When it turns out to be without substance, I would not be offended. How feasible would this be? Friedrich P.S.: But it would maybe simplify the sorting much. The 3D engine stores the projected polygons with z information (z as the depth from the camera). When another polygon arrives, it will be cut /after projection/ into pieces based on the polygons in front of it, and be drawn upon all polygons behind. The weel again? P.P.S.: I'm very un-self-confident about this ideas. But I read, in OSS one should also publish half-baken ideas, even when they do not compile ... -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
I also agree with Reinier. I want my 3d plots to look as close as possible to my 2d plots. Because mplot3d uses so much of the same matplotlib core, this is trivial. As Friedrich mentioned, the mplot3d code is actually pretty small. To me, that is a great feature. I found the mplot3d code very accessible. I do agree that there is still much work to be done in mplot3d. But I think starting from scratch is a waste of time. FYI, I looked into using mayavi2 before settling on mplot3d. Mayavi can create some stunning graphics, but I found that it is very restrictive in its plotting options. Take for example the 3d scatter plot. They combined the size and color parameter. Getting around this strange restriction took me quite some time. (Installation for me was also a pain due to VTK). -Ben -Original Message- From: Jakub Nowacki [mailto:j.s.nowa...@googlemail.com] Sent: Friday, February 26, 2010 12:01 PM To: matplotlib-users Subject: Re: [Matplotlib-users] mplot3d stays? Dear all, I don't know if creating full blown 3d library makes much sense. I think Reinier is right here that the current mplot3d creates quite satisfactory outcome with matplotlib look-and-feel we all like. In general, there are 3d libraries/packages out there (VTK, Mayavi2 etc.), which do most of the stuff one would need. The problem is many times using is not that trivial. Also, the installation process is usually much more complex, eg. setting up mayavi2 on snow leopard took me several days. I asked the question in the first place because in many cases I need rather simple 3d plotting tool, without al the massive rendering capabilities etc. Since I use matplotlib anyway, it would be nice to use the same tool and not be forced to install and learn something new just to plot not very complicated surface. Hence, I think the main goal here should be to have a relatively simple but usable plotting tool with matplotlib look-an-feel. BTW I didn't know that my simple question would generate such a discussion. :) Best wishes, Jakub -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Dear all, I don't know if creating full blown 3d library makes much sense. I think Reinier is right here that the current mplot3d creates quite satisfactory outcome with matplotlib look-and-feel we all like. In general, there are 3d libraries/packages out there (VTK, Mayavi2 etc.), which do most of the stuff one would need. The problem is many times using is not that trivial. Also, the installation process is usually much more complex, eg. setting up mayavi2 on snow leopard took me several days. I asked the question in the first place because in many cases I need rather simple 3d plotting tool, without al the massive rendering capabilities etc. Since I use matplotlib anyway, it would be nice to use the same tool and not be forced to install and learn something new just to plot not very complicated surface. Hence, I think the main goal here should be to have a relatively simple but usable plotting tool with matplotlib look-an-feel. BTW I didn't know that my simple question would generate such a discussion. :) Best wishes, Jakub -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On 2/26/2010 3:04 AM, Friedrich Romstedt wrote: > I need a physical rendering engine with light > sources and reflectance/transmittance simulation http://en.wikipedia.org/wiki/POV-Ray ? Alan Isaac -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Dear all, One of the great advantages of the current mplot3d design is that it produces complete vector based graphics with the same look-and-feel as your 2d plots. Integration with OpenGL will certainly change this, as the rendering will always give you (as far as I know) a bitmap. I think this is what matlab does, and I consider it a major weakness. I therefore believe that the mplot3d approach is good for what it is designed for (which means not being a complete 3d rendering engine). The drawback, of course, is that you have to do more 3d stuff yourself. There are some good reasons why some problems are *very* hard to solve, but others are doable, such as z-ordering all the polygons (and perhaps splitting them if that's required). Gouraud shading is something else that should be possible. Getting dashed 3d lines z-sorted in a good-looking way sounds very hard to me, but for solid lines it should be ok. As a comment to a previous post, by Gael if I'm not mistaken: mplot3d internally has all info in 3d. In the end you have to go 2d somewhere, and I personally think that we do this at the correct level. Let me mention some more areas of improvement. Currently the Axis3D code does some magic to draw the axes lines and ticks in the correct location. It would be better to rewrite this class to use actual Line3D instances to reduce duplicate code. This brings me to my last remark, which is about the fact that Axes3D currently inherits from Axes. The reason why this was is of course to reduce code duplication. However, I can see why this can be very confusing to the user since it is indeed not clear what is and what is not supposed to work. I need to think a bit about the solution; indeed it might be better to not inherit from Axes. But do not call that all too soon, since Axes is still doing some work under the hood. On the other hand, many of the functions probably don't really make sense. I think restarting from scratch is almost never a good plan... Cheers, Reinier PS: John, I would be interested in mentoring a gsoc student. On Thu, Feb 25, 2010 at 7:26 PM, Eric Firing wrote: > John Hunter wrote: > [...] >> >> It looks like we have enough 3D projects to justify a google summer of >> code student. Would those of you with an interest in mplot3d and some >> knowledge of the internals be interested in helping mentor a student? >> > > http://www.mail-archive.com/matplotlib-de...@lists.sourceforge.net/msg01343.html > > Is it time for some re-thinking of the approach to 3-D? I am a > bystander, but I have the uneasy sense that trying to turn mplot3d into > a first-class 3-D plotting tool may be a misapplication of effort. > Might the effort be more productive if applied to mayavi, or built on > mayavi, so that the 3-D engine is already taken care of? > > Eric > > -- > 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-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Reinier Heeres Tel: +31 6 10852639 -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
2010/2/26 Gael Varoquaux : > What Eric was most probably talking about is the newer versions of > Mayavi, that we tend to call 'mayavi2', even though we are now up to > version 3, in particular the mlab interface: > > http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html > > which is demoed in the examples: > http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/examples.html > > I believe that Mayavi does take care of the task you are interested in. > It has its limitation and annoyances, but a lot of people use it quite > efficiently to do 3D plotting, for simple problems to very complex ones. Wow, that's really impressive! I admit that adding 3D plotting capability to matplotlib would be like reinventing the wheel, and it would be a quite rectangular-shaped wheel. But, unfortunately, I need a physical rendering engine with light sources and reflectance/transmittance simulation from real measured data anyway, and the 3D rendering engine will be a byproduct. But, I think, it would be more easy to use Agg directly as the backend rather than going via matplotlib, although it may be an option. Friedrich -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On Fri, Feb 26, 2010 at 12:16:40AM +0100, Friedrich Romstedt wrote: > 2010/2/25 Eric Firing : > > Is it time for some re-thinking of the approach to 3-D? I am a bystander, > > but I have the uneasy sense that trying to turn mplot3d into a first-class > > 3-D plotting tool may be a misapplication of effort. Might the effort be > > more productive if applied to mayavi, or built on mayavi, so that the 3-D > > engine is already taken care of? > Hmm, mayavi seems not suitable for our purpose, > http://mayavi.sourceforge.net/docs/guide/ch04.html > First, mayavi always creates its gui, second, one has to use an > intermediate vtk file. Don't know what about using vtk directly. What Eric was most probably talking about is the newer versions of Mayavi, that we tend to call 'mayavi2', even though we are now up to version 3, in particular the mlab interface: http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html which is demoed in the examples: http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/examples.html I believe that Mayavi does take care of the task you are interested in. It has its limitation and annoyances, but a lot of people use it quite efficiently to do 3D plotting, for simple problems to very complex ones. Gaël -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
2010/2/25 Eric Firing : > Is it time for some re-thinking of the approach to 3-D? I am a bystander, > but I have the uneasy sense that trying to turn mplot3d into a first-class > 3-D plotting tool may be a misapplication of effort. Might the effort be > more productive if applied to mayavi, or built on mayavi, so that the 3-D > engine is already taken care of? Hmm, mayavi seems not suitable for our purpose, http://mayavi.sourceforge.net/docs/guide/ch04.html First, mayavi always creates its gui, second, one has to use an intermediate vtk file. Don't know what about using vtk directly. For me, it would just be an interesting task to solve, just as for the person you cite: http://www.mail-archive.com/matplotlib-de...@lists.sourceforge.net/msg01343.html Re: [matplotlib-devel] mpl1: models, projections, other comments Gael Varoquaux Sun, 22 Jul 2007 02:18:36 -0700 > [...], but I > did learn something: a 3D package must be fully 3D, or I think it won't > go far. My personnal opinion is that I won't spend my time on a package > that wants to do 3D and that does not keep a complete 3D representation > of its object at all time, and even feeds it to the backends. I would not feed it to the backend, as our backend seems to be the mpl plotting engine, but I agree to the basic outline of this thought. When I move through the code of mplot3d, which is indeed much shorter that I expected, I find it not that way :-(. I think, it would be a good approach to rewrite the package nearly from scratch. I don't want to diminish the work of John and Reinier in any way, but I think as far as my knowledge of mplot3d reaches, I come to an answer similar to that cited above. When John and Reinier would agree, I would like to start thus a new package, which uses mpl clearly as a backend. For me, I wouln't derive Axes3D from Axes, as it intermingles both. This approach would even make the package much more general, as other backends could be imagined (e.g., direct file rendering or display from more than one viewing position.) I would feel responsible for the C++ rendering machine, this has to be fast, but I will certainly need some advice :-) with Python extensions. Btw, z sorting isn't sufficient, imagining a ring of surfaces, 1, 2, ..., n, e.g. like in a turbine's compressor wheels, such that 2 > 1 and 3 > 2 ... and 1 > n, thus a ring. Not always is a linear ordering of the sufaces thus possible. If my thoughts find some resonance, I would suggest a switch to matplotlib-devel? Friedrich -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
John Hunter wrote: [...] > > It looks like we have enough 3D projects to justify a google summer of > code student. Would those of you with an interest in mplot3d and some > knowledge of the internals be interested in helping mentor a student? > http://www.mail-archive.com/matplotlib-de...@lists.sourceforge.net/msg01343.html Is it time for some re-thinking of the approach to 3-D? I am a bystander, but I have the uneasy sense that trying to turn mplot3d into a first-class 3-D plotting tool may be a misapplication of effort. Might the effort be more productive if applied to mayavi, or built on mayavi, so that the 3-D engine is already taken care of? Eric -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
2010/2/25 John Hunter : > We rely on plenty of C++ code so this isn't a problem for us. We would have > to write an interface layer but it shouldn't be too difficult. The harder > problem may be dealing tracking the interior vs the edges of the mesh, but > certainly not insurmountable. If you'd like to contribute the code, that'd > be great. If you want to add some comments first, even better. I'll be happy to contribute the code, but it certainly needs some reworking and investigation before, because I recall it to be written in part with german class names ... well, it was a high-school project ... long ago. I think the concept could be fairly easy if I'm not mistaken: One has a list of "pathes" (lines) and a list of "patches" (surfaces). When adding a plot, it will be both created and appended. Then the rendering engine clips the "pathes" and "patches" as mentioned. I think also it would be a nice idea to design the thing in the whole such that it can be integrated into matplotlib's core, I mean, that one does not need to call another module to make 3D plots, but instead simply passes another coordinate as non-None. But this is just an idea, I'm inclined to believe that it's maybe not feasible at the present point. Also I have way to low knowledge about mplot3d and am in fact new to it. Thus please apologise this thought if it is half-baken or even raw. > I believe the faces are quadrilateral, and Michael already wrote the code to > convert these to triangle meshes for his gouraud shading work ( which I'd > still like to see ported to 3d). That sounds good, at least to me. In fact, the project of mine is a complete renderer, thus we could also incorporate any kind of shading and light sources and shadows .. I send a picture appended. > It looks like we have enough 3D projects to justify a google summer of code > student. Would those of you with an interest in mplot3d and some knowledge > of the internals be interested in helping mentor a student? I never dived very deeply into matplotlib, and don't know how much time I can efford for even one more project, but I can certainly help with telling the concepts of my implementation etc. and how I coded things, such that another person can do the real work :-) In fact, even this small amount of help could maybe save us a lot of time? My deepest matplotlib project was that mentioned in the thread "Embedding matplotlib in Tkinter Applications" in the first post. (Soon unter MIT.) It would be great for me to make a contribution to a real usable rendering engine ... :-) Friedrich tst06.ppm.rar Description: Binary data -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On Feb 25, 2010, at 2:50 AM, Friedrich Romstedt wrote: > 2010/2/25 Reinier Heeres : >> Of course many 3D engines do this already, but the problem is always >> the integration. Is your engine python based and is the code (freely) >> available? I would be interested in taking a look. > > It's C++ code :-( And nearly no comments :-(( I myself will need some > time to find out what part does what. > But nevertheless, if it can help, I will be happy to privide with it. > Maybe it's faster than writing from scratch and tracking all the bugs > We rely on plenty of C++ code so this isn't a problem for us. We would have to write an interface layer but it shouldn't be too difficult. The harder problem may be dealing tracking the interior vs the edges of the mesh, but certainly not insurmountable. If you'd like to contribute the code, that'd be great. If you want to add some comments first, even better. > >> Also, currently the native mpl structures are polygons instead of a >> triangles, so they will have to be decomposed. This will definitely >> cause some issues with line styles etc. that should not be applied to >> all edges. > > What kind of structure is used to store the polygons? Is each > polygon planar? > I believe the faces are quadrilateral, and Michael already wrote the code to convert these to triangle meshes for his gouraud shading work ( which I'd still like to see ported to 3d). It looks like we have enough 3D projects to justify a google summer of code student. Would those of you with an interest in mplot3d and some knowledge of the internals be interested in helping mentor a student? > For the second issue, one could decompose the polygon into surface and > boundary. The lines would be clipped against the surfaces only, and > the surfaces against the surfaces too. Then one could draw the > surfaces first without any line style around the triangles, and in the > end the boundaries. > > When performing clipping, there will be no way around decomposing the > polygons into something? > > Friedrich > > --- > --- > --- > - > 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-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
2010/2/25 Reinier Heeres : > Of course many 3D engines do this already, but the problem is always > the integration. Is your engine python based and is the code (freely) > available? I would be interested in taking a look. It's C++ code :-( And nearly no comments :-(( I myself will need some time to find out what part does what. But nevertheless, if it can help, I will be happy to privide with it. Maybe it's faster than writing from scratch and tracking all the bugs ... > Also, currently the native mpl structures are polygons instead of a > triangles, so they will have to be decomposed. This will definitely > cause some issues with line styles etc. that should not be applied to > all edges. What kind of structure is used to store the polygons? Is each polygon planar? For the second issue, one could decompose the polygon into surface and boundary. The lines would be clipped against the surfaces only, and the surfaces against the surfaces too. Then one could draw the surfaces first without any line style around the triangles, and in the end the boundaries. When performing clipping, there will be no way around decomposing the polygons into something? Friedrich -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Hi Friedrich, Thanks for your message. On Thu, Feb 25, 2010 at 9:24 AM, Friedrich Romstedt wrote: > I have worked in highschool on a project "Beam tracing" where I had to > subdivide triangles from a certain point of view with z-ordering and with > such a subdivision how they are covered by the viewing beam. This means > this engine you want to write already exists. See the following ascii > graphics: Of course many 3D engines do this already, but the problem is always the integration. Is your engine python based and is the code (freely) available? I would be interested in taking a look. Also, currently the native mpl structures are polygons instead of a triangles, so they will have to be decomposed. This will definitely cause some issues with line styles etc. that should not be applied to all edges. Cheers, Reinier > > ++ > | / > | 1 / > | / > | +-/--+ > | \ 2 / / > | \ / / > | / 3 / > | / \ / > | / \ / > | / \/ > | / > |/ > > Say that 1 is in front of 2 + 3. Then the engine will leave 1 unchanged, > will discard 2, and will subdivide 3 into a number of sub-triangles, which > comprise 3 exactly. > > Don't know whether you are interested in the tringles at all or only in the > pathes of their contours. > > The engine assumes that the sets of points comprising the sufaces of the > triangles are disjoint. > > Friedrich > > 2010/2/25 Reinier Heeres : >> Hi all, >> >> I'll mention again that I intend to continue supporting mplot3d, >> although help would be greatly appreciated. >> >> I think the z-ordering issues are in the end quite hard to tackle, >> especially since we can have different kinds of structures in a plot, >> e.g. polygons and lines (or rather: curves). >> >> John's suggestion of a global polygon list would indeed be a good way >> forward, and I will think about implementing this soon. However, the >> next step of finding intersecting polygons and breaking them properly >> could be quite slow if implemented in pure python. So I'm not sure >> whether our goal should be to create a full 3d engine... >> >> Cheers, >> Reinier > > -- > 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-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- Reinier Heeres Tel: +31 6 10852639 -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
I have worked in highschool on a project "Beam tracing" where I had to subdivide triangles from a certain point of view with z-ordering and with such a subdivision how they are covered by the viewing beam. This means this engine you want to write already exists. See the following ascii graphics: ++ | / | 1 / | / | +-/--+ | \ 2 / / |\ / / | / 3 / |/ \/ | / \ / | / \/ | / |/ Say that 1 is in front of 2 + 3. Then the engine will leave 1 unchanged, will discard 2, and will subdivide 3 into a number of sub-triangles, which comprise 3 exactly. Don't know whether you are interested in the tringles at all or only in the pathes of their contours. The engine assumes that the sets of points comprising the sufaces of the triangles are disjoint. Friedrich 2010/2/25 Reinier Heeres : > Hi all, > > I'll mention again that I intend to continue supporting mplot3d, > although help would be greatly appreciated. > > I think the z-ordering issues are in the end quite hard to tackle, > especially since we can have different kinds of structures in a plot, > e.g. polygons and lines (or rather: curves). > > John's suggestion of a global polygon list would indeed be a good way > forward, and I will think about implementing this soon. However, the > next step of finding intersecting polygons and breaking them properly > could be quite slow if implemented in pure python. So I'm not sure > whether our goal should be to create a full 3d engine... > > Cheers, > Reinier -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Hi all, I'll mention again that I intend to continue supporting mplot3d, although help would be greatly appreciated. I think the z-ordering issues are in the end quite hard to tackle, especially since we can have different kinds of structures in a plot, e.g. polygons and lines (or rather: curves). John's suggestion of a global polygon list would indeed be a good way forward, and I will think about implementing this soon. However, the next step of finding intersecting polygons and breaking them properly could be quite slow if implemented in pure python. So I'm not sure whether our goal should be to create a full 3d engine... Cheers, Reinier On Mon, Feb 22, 2010 at 5:15 PM, John Hunter wrote: > On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod wrote: >> John, your assesment of the problem is correct. And I believe your >> suggested solution is also correct. Currently, each call to a mplot3d plot >> method is treated independantly. They get converted into custom >> PolyCollections which each do the Z-order sorting. > >> >> There is still an issue here however. Even if we implement the >> aformentioned solution, we are still only approximating a 3d library. And >> the result will still not be as nice as matlab. I believe that because we >> treat the surface as a series of 2D polygons, the intersection between two >> surfaces will be at the polygon edges. See the attached image for an >> example of what the intersection between a sphere and plane might look like. > > True enough, but as your example shows it would still be a substantial > improvement over what we have now, and by getting all the faces in the > scene into a single data structure, we leave open the possibility of > doing something more sophisticated down the road (like chopping a > problematic face into multiple faces, some in front, some behind, an > intersecting object). > > JDH -- Reinier Heeres Tel: +31 6 10852639 -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod wrote: > John, your assesment of the problem is correct. And I believe your suggested > solution is also correct. Currently, each call to a mplot3d plot method is > treated independantly. They get converted into custom PolyCollections which > each do the Z-order sorting. > > There is still an issue here however. Even if we implement the aformentioned > solution, we are still only approximating a 3d library. And the result will > still not be as nice as matlab. I believe that because we treat the surface > as a series of 2D polygons, the intersection between two surfaces will be at > the polygon edges. See the attached image for an example of what the > intersection between a sphere and plane might look like. True enough, but as your example shows it would still be a substantial improvement over what we have now, and by getting all the faces in the scene into a single data structure, we leave open the possibility of doing something more sophisticated down the road (like chopping a problematic face into multiple faces, some in front, some behind, an intersecting object). JDH -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On Sun, Feb 21, 2010 at 4:02 PM, Ben Axelrod wrote: > I am not a MPL developer, You are now :-) > but I am using mplot3d quite heavily right now to support 3D plots for a > client of mine. I have found many bugs and > lacking features which I require in the mplot3d library and have modified my > local copy of the code significantly. I am > eagerly awaiting Reinier's return from vacation so that I can work with him > to integrate my improvements. For the most > part, these fixes simply make the 3D plots behave more like the 2D plots. > Here is a tentative list of my changes so far: > > * bug fix: placement of title in 3D plots to match 2D plot behavior > * bug fix: allow facecolors and edgecolors to be specified as 'none' in 3D > scatter plots to match the 2D scatter plot behavior > * bug fix: allow all keyword arguments to be used in text3D > * bug fix: allow an array of colors to be passed into bar3d to specify the > colors on a per-bar or per-face basis > * bug fix: allow all keyword arguments to be used in bar3d > * bug fix: allow 3d scatter plots with 3 or 4 points with colors specified > * new feature: new method to disable mouse rotation in 3D plots > * new feature: new Z-order sorting heuristic to eliminate rendering issues > for the common case of using bar3d to visualize a 2D histogram > * new feature: new method text2D > * code cleanup: warn when canvas is None which disables mouse callbacks > * code cleanup: fully document more methods in mplot3d I'd be happy to take a look at this patch and commit it - Reinier can review it and make any necessary changes when he gets back. > Although I haven't written them yet, I can probably create a couple more > example codes: > * example code: demonstrate use of transform() to do rectangle selection in > 3D scatter plots > * example code: mplot3d with wx - demonstrate turning off mouse rotations to > make pan and zoom toolbar buttons work properly > > There are a few other bugs that I would really like fixed, but can't quite > figure out right now. Hopefully Reinier will be able to shed some light on > these: > * axis label picking for 3D axes > * how to set axis tick label properties for 3D axes > * allow 3d boxes with transparent faces to make "wireframe" boxes > * fix z-order sorting across multiple calls to bar3d() > > I should note that because of my client, I have a vested interest in seeing > mplot3d (with the above bug fixes) make it > into a stable release of MPL. But at the same time, I don't have a lot of > spare time to spend on MPL development. I see no reason why they can't make it into the (overdue, upcoming) 1.0 if you can get a patch together in the next week or two. JDH -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
On Sun, Feb 21, 2010 at 7:15 PM, David Arnold wrote: > Hi, > > What prevents me from using mplot3d in the classroom is highlighted by the > following example. I believe the problem arises because each artist (ie each polygon, line or 3d text object) is rendered separately, and so there is no way different faces from the same object to be rendered on different sides of another object in the scene. I am no expert on the mplot3d internals or pipeline, but it seems like the solution is for each artist to transform the faces of their respective polys and place them in a Axes3D level list (or other data structure) along with their properties (eg facecolor, alpha) and then do a zordering and clipping at the axes level rather than the artist level before rendering. One might use a custom PolyCollection for this For those of you with more familiarity with mplot3d internals: is this approach viable/feasible? JDH -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] mplot3d stays?
Hi,
What prevents me from using mplot3d in the classroom is highlighted by the
following example.
# surface3d_demo2.py
import matplotlib
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt
import numpy as np
fig = plt.figure()
ax = Axes3D(fig)
u = np.linspace(0, 2*np.pi, 100)
v = np.linspace(0, np.pi, 100)
x = 10 * np.outer(np.cos(u), np.sin(v))
y = 10 * np.outer(np.sin(u), np.sin(v))
z = 10 * np.outer(np.ones(np.size(u)), np.cos(v))
ax.plot_surface(x, y, z, rstride=4, cstride=4, color='b')
yy = np.linspace(-10, 10, 40)
zz = np.linspace(-10, 10, 40)
[yy, zz] = np.meshgrid(yy, zz)
xx = np.ones(np.shape(yy))
ax.plot_surface(xx, yy, zz, rstride=1, cstride=1, color=".7")
ax.set_xlabel('x-axis')
ax.set_ylabel('y-axis')
plt.show()
This code produces the following image:
http://msemac.redwoods.edu/~darnold/junk/test1.png
Pretty much the same code in Matlab:
u=linspace(0,2*pi,40);
v=linspace(0,pi,40);
[u,v]=meshgrid(u,v);
x=10*cos(u).*sin(v);
y=10*sin(u).*sin(v);
z=10*cos(v);
surf(x,y,z,'FaceColor','b')
yy=linspace(-10,10,40);
zz=yy;
[yy,zz]=meshgrid(yy,zz);
xx=ones(size(yy));
hold on
surf(xx,yy,zz,'FaceColor',[0.7,0.7,0.7])
view(30,30)
print -dpng 'test2.png'
shg
Produces this image:
http://msemac.redwoods.edu/~darnold/junk/test2.png
The inability of mplot3d to determine which image is in front seems to be a
problem.
The following page (must be viewed in Firefox) will give some sense of what I
need when teaching multivariable calculus.
http://msemac.redwoods.edu/~darnold/math50c/matlab/index.php
David Arnold
College of the Redwoods
http://msemac.redwoods.edu/~darnold/index.php
Davd Arnold
College of the Redwoods
On Feb 21, 2010, at 2:02 PM, Ben Axelrod wrote:
> I am not a MPL developer, but I am using mplot3d quite heavily right now to
> support 3D plots for a client of mine. I have found many bugs and lacking
> features which I require in the mplot3d library and have modified my local
> copy of the code significantly. I am eagerly awaiting Reinier's return from
> vacation so that I can work with him to integrate my improvements. For the
> most part, these fixes simply make the 3D plots behave more like the 2D
> plots. Here is a tentative list of my changes so far:
>
> * bug fix: placement of title in 3D plots to match 2D plot behavior
> * bug fix: allow facecolors and edgecolors to be specified as 'none' in 3D
> scatter plots to match the 2D scatter plot behavior
> * bug fix: allow all keyword arguments to be used in text3D
> * bug fix: allow an array of colors to be passed into bar3d to specify the
> colors on a per-bar or per-face basis
> * bug fix: allow all keyword arguments to be used in bar3d
> * bug fix: allow 3d scatter plots with 3 or 4 points with colors specified
> * new feature: new method to disable mouse rotation in 3D plots
> * new feature: new Z-order sorting heuristic to eliminate rendering issues
> for the common case of using bar3d to visualize a 2D histogram
> * new feature: new method text2D
> * code cleanup: warn when canvas is None which disables mouse callbacks
> * code cleanup: fully document more methods in mplot3d
>
> Although I haven't written them yet, I can probably create a couple more
> example codes:
> * example code: demonstrate use of transform() to do rectangle selection in
> 3D scatter plots
> * example code: mplot3d with wx - demonstrate turning off mouse rotations to
> make pan and zoom toolbar buttons work properly
>
> There are a few other bugs that I would really like fixed, but can't quite
> figure out right now. Hopefully Reinier will be able to shed some light on
> these:
> * axis label picking for 3D axes
> * how to set axis tick label properties for 3D axes
> * allow 3d boxes with transparent faces to make "wireframe" boxes
> * fix z-order sorting across multiple calls to bar3d()
>
> I should note that because of my client, I have a vested interest in seeing
> mplot3d (with the above bug fixes) make it into a stable release of MPL. But
> at the same time, I don't have a lot of spare time to spend on MPL
> development.
>
> Thanks,
> -Ben
>
>
> From: John Hunter [jdh2...@gmail.com]
> Sent: Sunday, February 21, 2010 12:19 PM
> To: Jakub Nowacki
> Cc: matplotlib-users@lists.sourceforge.net
> Subject: Re: [Matplotlib-users] mplot3d stays?
>
> On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki
> wrote:
>> Hi,
>>
>> I have quite general question. Since mplot3d now back in matplotlib, the
>> question is: is it going to stay there? Or is it some test release? I was
>> just wondering cause sometimes I use 3d plotting and use Ma
Re: [Matplotlib-users] mplot3d stays?
I am not a MPL developer, but I am using mplot3d quite heavily right now to support 3D plots for a client of mine. I have found many bugs and lacking features which I require in the mplot3d library and have modified my local copy of the code significantly. I am eagerly awaiting Reinier's return from vacation so that I can work with him to integrate my improvements. For the most part, these fixes simply make the 3D plots behave more like the 2D plots. Here is a tentative list of my changes so far: * bug fix: placement of title in 3D plots to match 2D plot behavior * bug fix: allow facecolors and edgecolors to be specified as 'none' in 3D scatter plots to match the 2D scatter plot behavior * bug fix: allow all keyword arguments to be used in text3D * bug fix: allow an array of colors to be passed into bar3d to specify the colors on a per-bar or per-face basis * bug fix: allow all keyword arguments to be used in bar3d * bug fix: allow 3d scatter plots with 3 or 4 points with colors specified * new feature: new method to disable mouse rotation in 3D plots * new feature: new Z-order sorting heuristic to eliminate rendering issues for the common case of using bar3d to visualize a 2D histogram * new feature: new method text2D * code cleanup: warn when canvas is None which disables mouse callbacks * code cleanup: fully document more methods in mplot3d Although I haven't written them yet, I can probably create a couple more example codes: * example code: demonstrate use of transform() to do rectangle selection in 3D scatter plots * example code: mplot3d with wx - demonstrate turning off mouse rotations to make pan and zoom toolbar buttons work properly There are a few other bugs that I would really like fixed, but can't quite figure out right now. Hopefully Reinier will be able to shed some light on these: * axis label picking for 3D axes * how to set axis tick label properties for 3D axes * allow 3d boxes with transparent faces to make "wireframe" boxes * fix z-order sorting across multiple calls to bar3d() I should note that because of my client, I have a vested interest in seeing mplot3d (with the above bug fixes) make it into a stable release of MPL. But at the same time, I don't have a lot of spare time to spend on MPL development. Thanks, -Ben From: John Hunter [jdh2...@gmail.com] Sent: Sunday, February 21, 2010 12:19 PM To: Jakub Nowacki Cc: matplotlib-users@lists.sourceforge.net Subject: Re: [Matplotlib-users] mplot3d stays? On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki wrote: > Hi, > > I have quite general question. Since mplot3d now back in matplotlib, the > question is: is it going to stay there? Or is it some test release? I was > just wondering cause sometimes I use 3d plotting and use Mayavi2 for that but > in many cases it's like killing the spider with a shotgun, not mentioning > that installation process can be quite tricky. > > Thanks for answer in advance/ Like anything in open source, it stays as long as someone supports it. The original implementation in matplotlib.axes3d was not supported by the original authors and none of the core developers had the bandwidth to support it, so we pulled it when a significant transformations refactoring broke the existing 3D support and noone had the resources to fix it. It languished for a while to Reinier picked up the torch with help from others and reintegrated it into mpl. To date he has been supporting it but is mostly acting alone (bus factor 1) . So we plan to continue support for mpl but we need developers to do it, so don't be shy about jumping into the code base and seeing if you can make incremental enhancements when you need them. On the plus side, the core of mpl is in pretty good shape, so I don't anticipate the need for a significant refactoring of the internals of the kind Michael did a couple of years ago which broke mplot3d the first time. JDH -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- 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-users maili
Re: [Matplotlib-users] mplot3d stays?
On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki wrote: > Hi, > > I have quite general question. Since mplot3d now back in matplotlib, the > question is: is it going to stay there? Or is it some test release? I was > just wondering cause sometimes I use 3d plotting and use Mayavi2 for that but > in many cases it's like killing the spider with a shotgun, not mentioning > that installation process can be quite tricky. > > Thanks for answer in advance/ Like anything in open source, it stays as long as someone supports it. The original implementation in matplotlib.axes3d was not supported by the original authors and none of the core developers had the bandwidth to support it, so we pulled it when a significant transformations refactoring broke the existing 3D support and noone had the resources to fix it. It languished for a while to Reinier picked up the torch with help from others and reintegrated it into mpl. To date he has been supporting it but is mostly acting alone (bus factor 1) . So we plan to continue support for mpl but we need developers to do it, so don't be shy about jumping into the code base and seeing if you can make incremental enhancements when you need them. On the plus side, the core of mpl is in pretty good shape, so I don't anticipate the need for a significant refactoring of the internals of the kind Michael did a couple of years ago which broke mplot3d the first time. JDH -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] mplot3d stays?
Hi, I have quite general question. Since mplot3d now back in matplotlib, the question is: is it going to stay there? Or is it some test release? I was just wondering cause sometimes I use 3d plotting and use Mayavi2 for that but in many cases it's like killing the spider with a shotgun, not mentioning that installation process can be quite tricky. Thanks for answer in advance. Cheers, Jakub -- 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
