Dear Ben, dear John,
Thank You for the emails. Well, we have modified only the part
influencing the modules, that we need or will need in our projects. I
admit that apart from the deceptions connected with human perception
(for example
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.2303 ) still
the inaccuracy remains. Nevertheless all the surfaces we have rendered
were unproblematic. Also the examples from the forum rendered correctly
even for big stride. If it is unsatisfactory one can control the
precision with the stride size. The modification was written under the
assumption not to modify too much in the existing system. While writing
the code we were naturally keeping in mind the ratio of accuracy to the
computational effort.
Since in our projects we didn't need the return value from the
plot_surface we return the obtained list for the efficiency reasons. But
if the API should remain unchanged, then one can generate also the
previous collection and return it instead of the list, while the list is
added.
I admit, that I didn't consider the changes You mention in the
consecutive e-mails, since it would mean redesigning Your code. From the
same reason I also cannot comment them – I simply don't know the
internal structure of Your code sufficienty. Change on the level of
Artists would probably imply a lot of other modifications in many, many
modules.
------
Mit freundlichen Grüssen / With friendly greetings,
Konrad Bartkowski
On 04/15/11 23:02, Benjamin Root wrote:
>
>
> On Fri, Apr 15, 2011 at 3:54 PM, John Hunter <jdh2...@gmail.com
> <mailto:jdh2...@gmail.com>> wrote:
>
>
>
> On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben.r...@ou.edu
> <mailto:ben.r...@ou.edu>> 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
>
>
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
