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
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
On Sun, Feb 21, 2010 at 8:20 AM, Jakub Nowacki <j.s.nowacki@...982...> 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/
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 [jdh2358@...287...]
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 <j.s.nowacki@...982...> 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.
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
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 mplot3dAlthough 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 properlyThere 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 [jdh2358@...287...]
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 > <j.s.nowacki@...982...> 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
matplotlib-users List Signup and Options------------------------------------------------------------------------------
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
matplotlib-users List Signup and Options
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 Sun, Feb 21, 2010 at 7:15 PM, David Arnold <dwarnold45@...2108...> wrote:
Hi,
What prevents me from using mplot3d in the classroom is highlighted by the following example.
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 properlyThere 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
On Sun, Feb 21, 2010 at 4:02 PM, Ben Axelrod <BAxelrod@...2066...> 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.
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:jdh2358@…287…]
Sent: Sunday, February 21, 2010 9:24 PM
To: David Arnold
Cc: Ben Axelrod; Jakub Nowacki; matplotlib-users@lists.sourceforge.net; Reinier Heeres
Subject: Re: [Matplotlib-users] mplot3d stays?
Importance: Low
On Sun, Feb 21, 2010 at 7:15 PM, David Arnold <dwarnold45@...2108...> 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
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
On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod <BAxelrod@...2066...> 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.
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 <jdh2358@...287...> wrote:
On Mon, Feb 22, 2010 at 10:01 AM, Ben Axelrod <BAxelrod@...2066...> 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 <reinier@…2663…>:
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.
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
On Thu, Feb 25, 2010 at 9:24 AM, Friedrich Romstedt <friedrichromstedt@...287...> wrote:
+------------+
> /
> 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 <reinier@...2663...>:
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
matplotlib-users List Signup and Options
--
Reinier Heeres
Tel: +31 6 10852639
2010/2/25 Reinier Heeres <reinier@...2663...>:
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
2010/2/25 Reinier Heeres <reinier@...2663...>:
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
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?
On Feb 25, 2010, at 2:50 AM, Friedrich Romstedt <friedrichromstedt@...287... > wrote:
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
matplotlib-users List Signup and Options
2010/2/25 John Hunter <jdh2358@...287...>:
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 (8.23 KB)
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-devel@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
2010/2/25 Eric Firing <efiring@...202...>:
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-devel@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
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:
which is demoed in the examples:
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
On Fri, Feb 26, 2010 at 12:16:40AM +0100, Friedrich Romstedt wrote:
2010/2/25 Eric Firing <efiring@...202...>:
> 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,
Chapter 4. Using MayaVi from Python
First, mayavi always creates its gui, second, one has to use an
intermediate vtk file. Don't know what about using vtk directly.
2010/2/26 Gael Varoquaux <gael.varoquaux@...1818...>:
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:Enthought Tool Suite :: Enthought, Inc.
which is demoed in the examples:
Enthought Tool Suite :: Enthought, Inc.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
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 <efiring@...202...> 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?Re: [matplotlib-devel] mpl1: models, projections, other comments
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
matplotlib-users List Signup and Options
--
Reinier Heeres
Tel: +31 6 10852639
Alan Isaac
On 2/26/2010 3:04 AM, Friedrich Romstedt wrote:
I need a physical rendering engine with light
sources and reflectance/transmittance simulation
