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
On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki <j.s...@go...> 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
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 [jd...@gm...] Sent: Sunday, February 21, 2010 12:19 PM To: Jakub Nowacki Cc: mat...@li... Subject: Re: [Matplotlib-users] mplot3d stays? On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki <j.s...@go...> 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On Sun, Feb 21, 2010 at 4:02 PM, Ben Axelrod <BAx...@co...> 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
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 [jd...@gm...]
> Sent: Sunday, February 21, 2010 12:19 PM
> To: Jakub Nowacki
> Cc: mat...@li...
> Subject: Re: [Matplotlib-users] mplot3d stays?
>
> On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki
> <j.s...@go...> 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
> Mat...@li...
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On Sun, Feb 21, 2010 at 7:15 PM, David Arnold <dwa...@su...> 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
On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod <BAx...@co...> 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
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 <jd...@gm...> wrote: > On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod <BAx...@co...> 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
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 <re...@he...>: > 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
Hi Friedrich, Thanks for your message. On Thu, Feb 25, 2010 at 9:24 AM, Friedrich Romstedt <fri...@gm...> 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 <re...@he...>: >> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- Reinier Heeres Tel: +31 6 10852639
2010年2月25日 Reinier Heeres <re...@he...>: > 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
On Feb 25, 2010, at 2:50 AM, Friedrich Romstedt <fri...@gm... > wrote: > 2010年2月25日 Reinier Heeres <re...@he...>: >> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
2010年2月25日 John Hunter <jd...@gm...>: > 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
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/mat...@li.../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
2010年2月25日 Eric Firing <ef...@ha...>: > 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/mat...@li.../msg01343.html Re: [matplotlib-devel] mpl1: models, projections, other comments Gael Varoquaux 2007年7月22日 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
On Fri, Feb 26, 2010 at 12:16:40AM +0100, Friedrich Romstedt wrote: > 2010年2月25日 Eric Firing <ef...@ha...>: > > 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
2010年2月26日 Gael Varoquaux <gae...@no...>: > 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
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
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. As a side note, this was a major barrier to me displaying multi-colored 3d bar plots as seen here: http://www.benaxelrod.com/temp/bar3d-2.png. But I fixed some color parameter issues in bar3d so that I can now call bar3d only once, and pass in color arrays so that now it renders properly. I will hopefully be able to submit a patch for this soon. -Ben -----Original Message----- From: John Hunter [mailto:jd...@gm...] Sent: Sunday, February 21, 2010 9:24 PM To: David Arnold Cc: Ben Axelrod; Jakub Nowacki; mat...@li...; Reinier Heeres Subject: Re: [Matplotlib-users] mplot3d stays? Importance: Low On Sun, Feb 21, 2010 at 7:15 PM, David Arnold <dwa...@su...> 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
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 <ef...@ha...> 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/mat...@li.../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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Reinier Heeres Tel: +31 6 10852639
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
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...@go...] 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 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 ...
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
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 [fri...@gm...] 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users
