Things become more and more complicated with time. I come up with four things to consider:
First the ring I already mentioned is visualised in attachment Ring.png. A > C > B > A, no z sorting possible, because no linear order anymore. Second, the intersecting line may not always separate a tringle in front as in your example, see "Fourangle".png. Though either the front or the back part of the intersected tringle is always a triangle. Furthemore, I suggest to cut both tringles along the intersection line. This makes things easier to implement, I'm quite convinced. Third, z sorting. How does the current algorithm I didn't understand work? One may consider pict z-sorting.png. For a simple-minded algorithm comparing the center of mass, the triangle in front seems to be at higher z. Fourth, detection of intersection. With the algorithm I proposed, I assume non-intersecting triangles. The problem is how to detect intersection at all. One might think that it's sufficient to check in the corners for inconsistencies with non-intersection. But unfortunataly, it isn't like that. In pict Tricking.png is an example. An algorithm checking the corners will find out that [red] is in front of [green], and nothing more, and hence cannot conclude towards intersection. I have no straightforward idea? One idea more: Not leaving B in your example triangles.png intact, but creating two new planar convex 4-polygons, filling those with triangles is very easy and straightforward. Thus it works out for A and B as pointed out in triangles2.png. Thus 1. detect intersecting triangles and cut them into pieces, second apply z sorting or equivalents? I had implemented z sorting for pairs of triangles already, and would like to compare with the mplot3d algorithmic idea. Using this, one could simply let a sort algorithm of any kind do the job. Apart from that results may look strange when there are rings :-) 2010/2/28 Ben Axelrod <baxel...@coroware.com>: > Interesting, but I think subdividing triangles like this is unnecessary. For > most cases, when one triangle completely covers the other, all that is > required it to Z order the triangles. This is what mplot3d does already. > The only case we have yet to handle is when one triangle "pierces" the other. > As seen in the attached image. Triangle B is mostly behind triangle A, > except for a small piece labeled C. All we would have to do is determine the > line of intersection, then create a new triangle C. Then we just draw B > first, then A, then C. > > I think the hardest part is probably doing this for general polygons and > handling the edges properly. But that should not be super hard. Hmm. First I thought: One should create pathes of lines and patches of surfaces. The lines do not need to be z ordered at all, they just have to be z ordered against the surfaces. But that's not sufficient, because lines /on/ surface may be drawn before the surface or not, at random, spoiling the thing. Maybe have for each triangle outline attributes? I guess that's what you had in mind from the beginning. Friedrich
<<attachment: Fourangle.png>>
<<attachment: Ring.png>>
<<attachment: triangles2.png>>
<<attachment: Tricking.png>>
<<attachment: z-sorting.png>>
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
