Fix: Normal maps and triangulate modifier will give incorrect result on
authorAntony Riakiotakis <kalast@gmail.com>
Wed, 21 Nov 2012 21:42:07 +0000 (21:42 +0000)
committerAntony Riakiotakis <kalast@gmail.com>
Wed, 21 Nov 2012 21:42:07 +0000 (21:42 +0000)
rectangular faces after applying rotation, reported by Metalliandi

This issue is caused by floating point precision error. After applying
rotation, the edge lengths change slightly and on rectangular faces the
length comparison can be flipped. Solved by giving a slight offset to
the length calculation for the diagonal during triangulation
calculation. (Same as done during uv unwrapping)

source/blender/bmesh/intern/bmesh_polygon.c

index 35213c8309790ae4d9d15e2f247c97a96939965a..2e0471863d49e11bf9ee48d4eb3dbe6864b8f1e7 100644 (file)
@@ -677,6 +677,7 @@ static BMLoop *find_ear(BMFace *f, float (*verts)[3], const int use_beauty, floa
        BMLoop *l_first;
 
        const float cos_threshold = 0.9f;
+       const float bias = 1.0f + 1e-6f;
 
        if (f->len == 4) {
                BMLoop *larr[4];
@@ -691,7 +692,7 @@ static BMLoop *find_ear(BMFace *f, float (*verts)[3], const int use_beauty, floa
                /* pick 0/1 based on best lenth */
                /* XXX Can't only rely on such test, also must check we do not get (too much) degenerated triangles!!! */
                i = (((len_squared_v3v3(larr[0]->v->co, larr[2]->v->co) >
-                    len_squared_v3v3(larr[1]->v->co, larr[3]->v->co))) != use_beauty);
+                    len_squared_v3v3(larr[1]->v->co, larr[3]->v->co) * bias)) != use_beauty);
                i4 = (i + 3) % 4;
                /* Check produced tris aren’t too flat/narrow...
                 * Probably not the best test, but is quite efficient and should at least avoid null-area faces! */