From 784fc400b3415f5120e3eef59a43e519c6a06fe0 Mon Sep 17 00:00:00 2001 From: Robin Watts Date: Wed, 17 Apr 2013 18:39:17 +0100 Subject: When triangulating quads, send edges in consistent order. Due to the underlying implementation, this probably doesn't make a difference. But it's more aesthetically pleasing. Most importantly, add a comment so we know what the tradeoffs are here. --- fitz/res_shade.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/fitz/res_shade.c b/fitz/res_shade.c index ae024073..fd5e0a85 100644 --- a/fitz/res_shade.c +++ b/fitz/res_shade.c @@ -11,8 +11,27 @@ paint_tri(fz_mesh_processor *painter, fz_vertex *v0, fz_vertex *v1, fz_vertex *v static void paint_quad(fz_mesh_processor *painter, fz_vertex *v0, fz_vertex *v1, fz_vertex *v2, fz_vertex *v3) { + /* For a quad with corners (in clockwise or anticlockwise order) are + * v0, v1, v2, v3. We can choose to split in in various different ways. + * Arbitrarily we can pick v0, v1, v3 for the first triangle. We then + * have to choose between v1, v2, v3 or v3, v2, v1 (or their equivalent + * rotations) for the second triangle. + * + * v1, v2, v3 has the property that both triangles share the same + * winding (useful if we were ever doing simple back face culling). + * + * v3, v2, v1 has the property that all the 'shared' edges (both + * within this quad, and with adjacent quads) are walked in the same + * direction every time. This can be useful in that depending on the + * implementation/rounding etc walking from A -> B can hit different + * pixels than walking from B->A. + * + * In the event neither of these things matter at the moment, as all + * the process functions where it matters order the edges from top to + * bottom before walking them. + */ painter->process(painter->process_arg, v0, v1, v3); - painter->process(painter->process_arg, v2, v3, v1); + painter->process(painter->process_arg, v3, v2, v1); } static void -- cgit v1.2.3