Re: [Matplotlib-users] mplot3d stays?

[Friedrich R. <fri...@gm...>]

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 <BAx...@co...>:
> 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