Jim Wilson wrote: > Ok the problem shows up with objects triangulated as follows: Picture > a diamond shape. Split it vertically so that you now have two > triangles, one on the left and the other on the right. Split the one > on the right horizontally. Now you have three triangles.
Yup. And one T junction. :) This is just a bad situation; it really can't be handled in any automated way. The lighting will always look wrong at such a junction, with or without any fancy vertex splitting. The middle point will be lit by a normal calculated locally from the two adjoining faces, while the adjacent pixels on the big triangle will be lit with a coefficient linearly interpolated from vertices which may be far away. There's no reason to expect these will be the same under any lighting model; the new code will look worse in some situations (heavily tesselated models where the edge will look sharp despite the fact that the geometry is locally curvy), better in others (coarser models where the corner normals of the big triangle might be very different, like the ailieron surfaces on most of the early planes). > BTW it appears that the "46" threshold indicates something other > than the inside angle between surface normals. Is this the intent? It's 180 minus the inner angle. Setting it to zero means that even an edge along a flat surface will be considered "sharp" and split, setting it to 180 means that even true knife edges won't get split (this is the behavior without the patch). Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
