From eef0b4f7a4274e332c971bfcffeef65cff3ab4fd Mon Sep 17 00:00:00 2001 From: gered Date: Sat, 1 Apr 2023 14:57:17 -0400 Subject: [PATCH] important comment documenting a difference in this triangle algorithm the difference is important to note since most articles discussing implementations of barycentric triangle rasterization show a test for positive w0/w1/w2 to determine if you're inside the triangle or not. they also usually use a slightly different formula in the `cross` function if they assume counter-clockwise vertex winding. since i'll admit i still don't *fully* grasp the math behind the edge functions and that stuff that is used to calculate the a01/b01/a12/... values, i wasn't sure how to adjust these for counter-clockwise winding to keep a positive w0/w1/w2 check. so the simple solution is to use the `cross` function as it is now, calculate a01/b01/a12/b12/a20/b20 as we are now, and do a negative w0/w1/w2 check and we get to keep counter-clockwise vertex winding which i prefer. hooray! --- ggdt/src/graphics/bitmap/triangles.rs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ggdt/src/graphics/bitmap/triangles.rs b/ggdt/src/graphics/bitmap/triangles.rs index bba7609..8e711e3 100644 --- a/ggdt/src/graphics/bitmap/triangles.rs +++ b/ggdt/src/graphics/bitmap/triangles.rs @@ -90,6 +90,8 @@ impl Bitmap { let row_pixels = unsafe { std::slice::from_raw_parts_mut(pixels, draw_width) }; for pixel in row_pixels.iter_mut() { + // note that for a counter-clockwise vertex winding order with the direction of Y+ going down instead + // of up, we need to test for *negative* area when checking if we're inside the triangle if w0 < 0.0 && w1 < 0.0 && w2 < 0.0 { pixel_fn(pixel, w0, w1, w2); }