matplotlib-devel Mailing List for matplotlib

On Fri, Apr 15, 2011 at 3:54 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> There might be a possible work-around, though. Maybe (and I am just
>> speculating here) if we can get the core part of matplotlib to specially
>> treat 3d collection objects in such a way that allows the collection to
>> return provide elements and z-order pairs. It is either that, or we finally
>> try to get OpenGL working again in matplotlib and allow ourselves to specify
>> coordinates in 3-D.
>>
>>
> It should be fairly easy to get a collections object to support multiple
> z-orders *within* the collection. Across artists, damn near impossible. I
> don't think you need to provide elements and z-order pairs per-se. The
> typical way a property is specified for a collection if you want it to vary
> over the elements of the collection is that the property is a sequence, and
> the property is accessed as prop[i%N] where i is the element number and N is
> the length of the property vector. So if we make zorder a len(elements)
> sequence of z-orders, we can order the collection by the zorder at draw
> time. Presumably external code would modify the zorder of the collection
> before each draw depending on the view.
>
Within a collection, this is already done correctly (or at least, as well as
one can except with a 2D rendering engine). It is when you have multiple
artists that exists over parts of the z-order "axis" that there are
problems. Essentially, if the 3-D bounding boxes overlap, then trouble
ensues.
Also, that speculation I had wouldn't work either, as the problem still
would exist for intersecting patches. No, what we really need is a 3D
rendering engine, and a logical separation between z-order for
sorting/layering and z-coordinates.
Ben Root

On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...> wrote:
>
> There might be a possible work-around, though. Maybe (and I am just
> speculating here) if we can get the core part of matplotlib to specially
> treat 3d collection objects in such a way that allows the collection to
> return provide elements and z-order pairs. It is either that, or we finally
> try to get OpenGL working again in matplotlib and allow ourselves to specify
> coordinates in 3-D.
>
>
It should be fairly easy to get a collections object to support multiple
z-orders *within* the collection. Across artists, damn near impossible. I
don't think you need to provide elements and z-order pairs per-se. The
typical way a property is specified for a collection if you want it to vary
over the elements of the collection is that the property is a sequence, and
the property is accessed as prop[i%N] where i is the element number and N is
the length of the property vector. So if we make zorder a len(elements)
sequence of z-orders, we can order the collection by the zorder at draw
time. Presumably external code would modify the zorder of the collection
before each draw depending on the view.

On Mon, Apr 11, 2011 at 4:16 AM, Konrad Bartkowski <
k.b...@fz...> wrote:
> Ok, forwarding it to the matplotlib-devel list.
>
>
> Best wishes,
>
> Konrad (on behalf of our workgroup)
>
>
> -------- Original Message -------- Subject: Source of inaccuracies in the
> matplotlib library Date: Fri, 8 Apr 2011 18:12:47 +0200 From: Bartkowski,
> Konrad <k.b...@fz...> <k.b...@fz...> To:
> dd...@co... <dd...@co...> <dd...@co...>, md...@st...
> <md...@st...> <md...@st...>, ef...@ha...
> <ef...@ha...> <ef...@ha...>, jdh...@ac...
> <jdh...@ac...> <jdh...@ac...>,
> jd...@gm... <jd...@gm...> <jd...@gm...> CC: Bartkowski,
> Konrad <k.b...@fz...> <k.b...@fz...>,
> el...@in... <el...@in...> <el...@in...>, Matthias Bolten
> <bo...@ma...> <bo...@ma...>,
> Grotendorst, Johannes <j.g...@fz...><j.g...@fz...>,
> Steffen, Bernhard <b.s...@fz...> <b.s...@fz...>
>
> Dear Matplotlib developers,
>
> I am writing about the matplotlib library with the mpl_toolkits. First
> of all let me emphasize how great software it is. Recently, in one of
> our projects we were rendering big surfaces and encountered the
> following problem:
> http://www.mail-archive.com/mat...@li.../msg06869.html
>
> It's not a bug (which all in all is a natural and unavoidable ingredient
> of the software, and especially in such a big and complex system like
> matplotlib would be fully natural), since the software does exactly the
> projection mathematics that it is expected to do, but a source of the
> inaccuracies, which is especially visible in the critical examples. For
> the profit of the Python community we are sending You a proposition of a
> modification of the surface plotting rendering system, in case You find
> it interesting enough to include in the consecutive version of the
> library. In the source code from the attachment we redesigned a little
> bit the computation process – since the computations are especially
> sensible to numerical errors, that are for example amplified while
> norming or processing the quaterions in the various stages (for example
> division over coordinate in the perspective projection). Therefore the
> computational focus can be shifted from the Polygon collection to the
> polygons itself. In the example from the above forum or the slightly
> modified one, one can observe a big difference in the numerical
> precision while the speed of the computations does not decrease (at
> least visibly). While instead of the surfaces from the forum, the
> following surfaces are rendered:
>
> 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=8, cstride=8, color='y', alpha=0.5)
> shiftX=28
> shiftY=28
> X,Y=np.meshgrid(range(-20+shiftX,20+shiftX),range(-20+shiftY,20+shiftY))
> Z=np.ones((X.shape[0], Y.shape[1]))
> ax.plot_surface(X, Y, Z, color='r', rstride=10, cstride=10, alpha=1.0)
>
> the issue is visible for example at the azimuth=40 , elevation=70 – with
> those parameters the mentioned case is visible on the red surface, while
> with elevation=68 not. Moreover, now also the stride is big (in the new
> approach the influence of increasing stride on the numerical precision
> grows).
> So again let me use this opportunity to thank You for empowering the
> Python community worldwide in a great, powerful scientific visualization
> tool.
>
> Best wishes,
> Konrad Bartkowski
>
>
>
Konrad,
Ok, I have examined the attached file, and I see what you have done. First,
the shading issue has long since been resolved and is in the development
branch (but probably won't be backported to v1.0.x because the changes were
extensive).
Second, the zorder sorting issue is a PITA to say the least. Your approach,
however, only pushes the problem down to smaller parts, and still doesn't
address the same problems with PatchCollection objects. That being said, I
would still be inclined to have the problem solved for surfaces and leave
patches to be buggy, except that this approach completely breaks the API.
plot_surface returns a Poly3DCollection object, not a list of
Poly3DCollection objects.
The Collections object is a double-edge sword. It allows for easy
manipulation of many artist objects, but ultimately the Collection object
must report a single z-order value to represent the z-order for plotting all
of the artist elements.
There might be a possible work-around, though. Maybe (and I am just
speculating here) if we can get the core part of matplotlib to specially
treat 3d collection objects in such a way that allows the collection to
return provide elements and z-order pairs. It is either that, or we finally
try to get OpenGL working again in matplotlib and allow ourselves to specify
coordinates in 3-D.
Ben Root

On Fri, Apr 15, 2011 at 9:27 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Benjamin Root <ben...@gm...> writes:
>
> > Would a change to the v1.0.x branch "stay" on the v1.0.x branch, or is
> > there something I have to do to prevent subsequent merges from going
> > into master?
>
> Since v1.0.x is supposed to be merged into master frequently, your
> change would propagate into master. To prevent it:
>
> 1. make sure v1.0.x is merged into master (usually it is, but
> if not, start by doing that merge)
> 2. merge your change to v1.0.x
> 3. merge v1.0.x to master with
>
> git checkout master
> git merge --strategy=ours v1.0.x
>
> This means that (1) the merge commit on top of v1.0.x will be in
> master's history, so it will not be merged again; (2) the merge is done
> by selecting the version of each file that is already in master, so the
> contents of master do not change.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
Ok, thanks, I did that, and everything looks ok. I pushed the fixes up.
Hopefully, the next merge doesn't screw things up.
Ben

Benjamin Root <ben...@gm...> writes:
> Would a change to the v1.0.x branch "stay" on the v1.0.x branch, or is
> there something I have to do to prevent subsequent merges from going
> into master?
Since v1.0.x is supposed to be merged into master frequently, your
change would propagate into master. To prevent it:
1. make sure v1.0.x is merged into master (usually it is, but
 if not, start by doing that merge)
2. merge your change to v1.0.x
3. merge v1.0.x to master with
 git checkout master
 git merge --strategy=ours v1.0.x
This means that (1) the merge commit on top of v1.0.x will be in
master's history, so it will not be merged again; (2) the merge is done
by selecting the version of each file that is already in master, so the
contents of master do not change.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks