From: Friedrich Romstedt <friedrichromstedt@gm...>  20100228 13:59:12

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 zsorting.png. For a simpleminded 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 nonintersecting 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 nonintersection. 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 4polygons, 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 <BAxelrod@...>: > 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 