diff --git a/docs/images/chapters/abc/059000c5c8a37dcc8d7fa04154a05df3.svg b/docs/images/chapters/abc/059000c5c8a37dcc8d7fa04154a05df3.svg index 0b65462e..2b29c549 100644 --- a/docs/images/chapters/abc/059000c5c8a37dcc8d7fa04154a05df3.svg +++ b/docs/images/chapters/abc/059000c5c8a37dcc8d7fa04154a05df3.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/12aaf0d7fd20b3c551a0ec76b18bd7d2.svg b/docs/images/chapters/abc/12aaf0d7fd20b3c551a0ec76b18bd7d2.svg index f2e31787..9986e8a4 100644 --- a/docs/images/chapters/abc/12aaf0d7fd20b3c551a0ec76b18bd7d2.svg +++ b/docs/images/chapters/abc/12aaf0d7fd20b3c551a0ec76b18bd7d2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/385d1fd4aecbd2066e6e284a84408be6.svg b/docs/images/chapters/abc/385d1fd4aecbd2066e6e284a84408be6.svg index b1b10de4..ae19e8b3 100644 --- a/docs/images/chapters/abc/385d1fd4aecbd2066e6e284a84408be6.svg +++ b/docs/images/chapters/abc/385d1fd4aecbd2066e6e284a84408be6.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/3c696e0364d61b1391695342707d6ccc.svg b/docs/images/chapters/abc/3c696e0364d61b1391695342707d6ccc.svg index c92d0726..f62ce798 100644 --- a/docs/images/chapters/abc/3c696e0364d61b1391695342707d6ccc.svg +++ b/docs/images/chapters/abc/3c696e0364d61b1391695342707d6ccc.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/5484dc53e408a4259891a65212ef8636.svg b/docs/images/chapters/abc/5484dc53e408a4259891a65212ef8636.svg index ef28accf..b18b4e71 100644 --- a/docs/images/chapters/abc/5484dc53e408a4259891a65212ef8636.svg +++ b/docs/images/chapters/abc/5484dc53e408a4259891a65212ef8636.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/63fbe4e666a7dad985ec4110e17c249f.svg b/docs/images/chapters/abc/63fbe4e666a7dad985ec4110e17c249f.svg index 987ba4f5..baeafda5 100644 --- a/docs/images/chapters/abc/63fbe4e666a7dad985ec4110e17c249f.svg +++ b/docs/images/chapters/abc/63fbe4e666a7dad985ec4110e17c249f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/b4987e9b77b0df604238b88596c5f7c3.svg b/docs/images/chapters/abc/b4987e9b77b0df604238b88596c5f7c3.svg index a07bd242..4b509763 100644 --- a/docs/images/chapters/abc/b4987e9b77b0df604238b88596c5f7c3.svg +++ b/docs/images/chapters/abc/b4987e9b77b0df604238b88596c5f7c3.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/bc245327e0b011712168bad1c48dfec4.svg b/docs/images/chapters/abc/bc245327e0b011712168bad1c48dfec4.svg index f2d98e6c..6fdc4f8d 100644 --- a/docs/images/chapters/abc/bc245327e0b011712168bad1c48dfec4.svg +++ b/docs/images/chapters/abc/bc245327e0b011712168bad1c48dfec4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/abc/cd2e47cdc2e23ec86cd1ca1cb4286645.svg b/docs/images/chapters/abc/cd2e47cdc2e23ec86cd1ca1cb4286645.svg index 74393c28..35babc51 100644 --- a/docs/images/chapters/abc/cd2e47cdc2e23ec86cd1ca1cb4286645.svg +++ b/docs/images/chapters/abc/cd2e47cdc2e23ec86cd1ca1cb4286645.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/aligning/50679d61424222d7b6b97eb3aa663582.svg b/docs/images/chapters/aligning/50679d61424222d7b6b97eb3aa663582.svg index 7470d0d6..95f3afa3 100644 --- a/docs/images/chapters/aligning/50679d61424222d7b6b97eb3aa663582.svg +++ b/docs/images/chapters/aligning/50679d61424222d7b6b97eb3aa663582.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/aligning/a9af1c06a00bb3c4af816a138fb0a66d.svg b/docs/images/chapters/aligning/a9af1c06a00bb3c4af816a138fb0a66d.svg index 8cdd1f86..bf215b97 100644 --- a/docs/images/chapters/aligning/a9af1c06a00bb3c4af816a138fb0a66d.svg +++ b/docs/images/chapters/aligning/a9af1c06a00bb3c4af816a138fb0a66d.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/aligning/c78b203ff33e5c1606728b552505d61c.svg b/docs/images/chapters/aligning/c78b203ff33e5c1606728b552505d61c.svg index b69dd310..3bd94cfc 100644 --- a/docs/images/chapters/aligning/c78b203ff33e5c1606728b552505d61c.svg +++ b/docs/images/chapters/aligning/c78b203ff33e5c1606728b552505d61c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/aligning/d480a9aa41917e5230d432cdbd6899b1.svg b/docs/images/chapters/aligning/d480a9aa41917e5230d432cdbd6899b1.svg index 58ddd04c..848ef7d6 100644 --- a/docs/images/chapters/aligning/d480a9aa41917e5230d432cdbd6899b1.svg +++ b/docs/images/chapters/aligning/d480a9aa41917e5230d432cdbd6899b1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/4b5d220d02b08f6c9aa19389255ef8bb.png b/docs/images/chapters/arclength/4b5d220d02b08f6c9aa19389255ef8bb.png index b5d26f69..c75ad7e4 100644 Binary files a/docs/images/chapters/arclength/4b5d220d02b08f6c9aa19389255ef8bb.png and b/docs/images/chapters/arclength/4b5d220d02b08f6c9aa19389255ef8bb.png differ diff --git a/docs/images/chapters/arclength/4bffba7dda2a3556cf5b2ae7392083c6.png b/docs/images/chapters/arclength/4bffba7dda2a3556cf5b2ae7392083c6.png index 3803a718..aec768ba 100644 Binary files a/docs/images/chapters/arclength/4bffba7dda2a3556cf5b2ae7392083c6.png and b/docs/images/chapters/arclength/4bffba7dda2a3556cf5b2ae7392083c6.png differ diff --git a/docs/images/chapters/arclength/5509919419288129322cfbd4c60d0a4f.svg b/docs/images/chapters/arclength/5509919419288129322cfbd4c60d0a4f.svg index 38ef5597..5b9d950c 100644 --- a/docs/images/chapters/arclength/5509919419288129322cfbd4c60d0a4f.svg +++ b/docs/images/chapters/arclength/5509919419288129322cfbd4c60d0a4f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/cb24cda7f7f4bbf3be7104c460e0ec9f.svg b/docs/images/chapters/arclength/cb24cda7f7f4bbf3be7104c460e0ec9f.svg index 609f6370..9512d2e6 100644 --- a/docs/images/chapters/arclength/cb24cda7f7f4bbf3be7104c460e0ec9f.svg +++ b/docs/images/chapters/arclength/cb24cda7f7f4bbf3be7104c460e0ec9f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/d0d93f1cc26b560309dade1f1aa012f2.svg b/docs/images/chapters/arclength/d0d93f1cc26b560309dade1f1aa012f2.svg index 0e2bef64..5559c6fc 100644 --- a/docs/images/chapters/arclength/d0d93f1cc26b560309dade1f1aa012f2.svg +++ b/docs/images/chapters/arclength/d0d93f1cc26b560309dade1f1aa012f2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/d3003177813309f88f58a1f515f5df9f.svg b/docs/images/chapters/arclength/d3003177813309f88f58a1f515f5df9f.svg index 1ac2d5e3..2b847055 100644 --- a/docs/images/chapters/arclength/d3003177813309f88f58a1f515f5df9f.svg +++ b/docs/images/chapters/arclength/d3003177813309f88f58a1f515f5df9f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/dc74a2f2da19470b8d721ece5f3ce268.png b/docs/images/chapters/arclength/dc74a2f2da19470b8d721ece5f3ce268.png index 260e5240..22ba6e0c 100644 Binary files a/docs/images/chapters/arclength/dc74a2f2da19470b8d721ece5f3ce268.png and b/docs/images/chapters/arclength/dc74a2f2da19470b8d721ece5f3ce268.png differ diff --git a/docs/images/chapters/arclength/e168758d35b8f6781617eda5a32b20bf.svg b/docs/images/chapters/arclength/e168758d35b8f6781617eda5a32b20bf.svg index 675d15f5..31f5eed9 100644 --- a/docs/images/chapters/arclength/e168758d35b8f6781617eda5a32b20bf.svg +++ b/docs/images/chapters/arclength/e168758d35b8f6781617eda5a32b20bf.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/arclength/e96dd431f6ef9433ccf25909dddd5bca.svg b/docs/images/chapters/arclength/e96dd431f6ef9433ccf25909dddd5bca.svg index a6dc8a62..b27e27e6 100644 --- a/docs/images/chapters/arclength/e96dd431f6ef9433ccf25909dddd5bca.svg +++ b/docs/images/chapters/arclength/e96dd431f6ef9433ccf25909dddd5bca.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/0f3451c711c0fe5d0b018aa4aa77d855.svg b/docs/images/chapters/bsplines/0f3451c711c0fe5d0b018aa4aa77d855.svg index 3d89be81..634d7727 100644 --- a/docs/images/chapters/bsplines/0f3451c711c0fe5d0b018aa4aa77d855.svg +++ b/docs/images/chapters/bsplines/0f3451c711c0fe5d0b018aa4aa77d855.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/4c8f9814c50c708757eeb5a68afabb7f.svg b/docs/images/chapters/bsplines/4c8f9814c50c708757eeb5a68afabb7f.svg index b6ae592a..75a2c494 100644 --- a/docs/images/chapters/bsplines/4c8f9814c50c708757eeb5a68afabb7f.svg +++ b/docs/images/chapters/bsplines/4c8f9814c50c708757eeb5a68afabb7f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/763838ea6f9e6c6aa63ea5f9c6d9542f.svg b/docs/images/chapters/bsplines/763838ea6f9e6c6aa63ea5f9c6d9542f.svg index 98f9af31..aa90f371 100644 --- a/docs/images/chapters/bsplines/763838ea6f9e6c6aa63ea5f9c6d9542f.svg +++ b/docs/images/chapters/bsplines/763838ea6f9e6c6aa63ea5f9c6d9542f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/892209dad8fd1f839470dd061e870913.svg b/docs/images/chapters/bsplines/892209dad8fd1f839470dd061e870913.svg index 318ec473..0e46a541 100644 --- a/docs/images/chapters/bsplines/892209dad8fd1f839470dd061e870913.svg +++ b/docs/images/chapters/bsplines/892209dad8fd1f839470dd061e870913.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/adac18ea69cc58e01c8d5e15498e4aa6.svg b/docs/images/chapters/bsplines/adac18ea69cc58e01c8d5e15498e4aa6.svg index c25e7948..57100931 100644 --- a/docs/images/chapters/bsplines/adac18ea69cc58e01c8d5e15498e4aa6.svg +++ b/docs/images/chapters/bsplines/adac18ea69cc58e01c8d5e15498e4aa6.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/bd187c361b285ef878d0bc17af8a3900.svg b/docs/images/chapters/bsplines/bd187c361b285ef878d0bc17af8a3900.svg index 6403e730..5cd6bcb3 100644 --- a/docs/images/chapters/bsplines/bd187c361b285ef878d0bc17af8a3900.svg +++ b/docs/images/chapters/bsplines/bd187c361b285ef878d0bc17af8a3900.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/bsplines/cf45d1ea00d4866abc8a058b130299b4.svg b/docs/images/chapters/bsplines/cf45d1ea00d4866abc8a058b130299b4.svg index 8f58bdba..147fc968 100644 --- a/docs/images/chapters/bsplines/cf45d1ea00d4866abc8a058b130299b4.svg +++ b/docs/images/chapters/bsplines/cf45d1ea00d4866abc8a058b130299b4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/0430e8c7f7d4ec80e6527f96f3d56e5c.svg b/docs/images/chapters/canonical/0430e8c7f7d4ec80e6527f96f3d56e5c.svg index a6f9f724..2d717931 100644 --- a/docs/images/chapters/canonical/0430e8c7f7d4ec80e6527f96f3d56e5c.svg +++ b/docs/images/chapters/canonical/0430e8c7f7d4ec80e6527f96f3d56e5c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/10025fdab2b3fd20f5d389cbe7e3e3ce.svg b/docs/images/chapters/canonical/10025fdab2b3fd20f5d389cbe7e3e3ce.svg index 8c3946b3..cf89ea1f 100644 --- a/docs/images/chapters/canonical/10025fdab2b3fd20f5d389cbe7e3e3ce.svg +++ b/docs/images/chapters/canonical/10025fdab2b3fd20f5d389cbe7e3e3ce.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/13c09950363c33627fd3a20343f2f6ce.svg b/docs/images/chapters/canonical/13c09950363c33627fd3a20343f2f6ce.svg index cbf2c4b1..d2be9f86 100644 --- a/docs/images/chapters/canonical/13c09950363c33627fd3a20343f2f6ce.svg +++ b/docs/images/chapters/canonical/13c09950363c33627fd3a20343f2f6ce.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/20684d22b3ddc52fd6abde8ce56608a9.svg b/docs/images/chapters/canonical/20684d22b3ddc52fd6abde8ce56608a9.svg index 9ff90d59..1c005dbf 100644 --- a/docs/images/chapters/canonical/20684d22b3ddc52fd6abde8ce56608a9.svg +++ b/docs/images/chapters/canonical/20684d22b3ddc52fd6abde8ce56608a9.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/2a411f175dcc987cdcc12e7df49ca272.svg b/docs/images/chapters/canonical/2a411f175dcc987cdcc12e7df49ca272.svg index a57bc626..43309b28 100644 --- a/docs/images/chapters/canonical/2a411f175dcc987cdcc12e7df49ca272.svg +++ b/docs/images/chapters/canonical/2a411f175dcc987cdcc12e7df49ca272.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/4230e959138d8400e04abf316360009a.svg b/docs/images/chapters/canonical/4230e959138d8400e04abf316360009a.svg index b252d264..242f5876 100644 --- a/docs/images/chapters/canonical/4230e959138d8400e04abf316360009a.svg +++ b/docs/images/chapters/canonical/4230e959138d8400e04abf316360009a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/63ccae0ebe0ca70dc2afb507ab32e4bd.svg b/docs/images/chapters/canonical/63ccae0ebe0ca70dc2afb507ab32e4bd.svg index cb7d8351..0ec30bbf 100644 --- a/docs/images/chapters/canonical/63ccae0ebe0ca70dc2afb507ab32e4bd.svg +++ b/docs/images/chapters/canonical/63ccae0ebe0ca70dc2afb507ab32e4bd.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/8cbef24b8c3b26f9daf2f89d27d36e95.svg b/docs/images/chapters/canonical/8cbef24b8c3b26f9daf2f89d27d36e95.svg index f9f308d8..44620a29 100644 --- a/docs/images/chapters/canonical/8cbef24b8c3b26f9daf2f89d27d36e95.svg +++ b/docs/images/chapters/canonical/8cbef24b8c3b26f9daf2f89d27d36e95.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/add5f7fb210a306fe9ff933113f6fb91.svg b/docs/images/chapters/canonical/add5f7fb210a306fe9ff933113f6fb91.svg index 6d68f6bb..554461dc 100644 --- a/docs/images/chapters/canonical/add5f7fb210a306fe9ff933113f6fb91.svg +++ b/docs/images/chapters/canonical/add5f7fb210a306fe9ff933113f6fb91.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/ba5f418452c3657f3c4dd4b319e59070.svg b/docs/images/chapters/canonical/ba5f418452c3657f3c4dd4b319e59070.svg index fda471a7..d1d5bed6 100644 --- a/docs/images/chapters/canonical/ba5f418452c3657f3c4dd4b319e59070.svg +++ b/docs/images/chapters/canonical/ba5f418452c3657f3c4dd4b319e59070.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/ddee51855ef3a9ee7660c395b0a041c7.svg b/docs/images/chapters/canonical/ddee51855ef3a9ee7660c395b0a041c7.svg index 7e283e5f..52b555b3 100644 --- a/docs/images/chapters/canonical/ddee51855ef3a9ee7660c395b0a041c7.svg +++ b/docs/images/chapters/canonical/ddee51855ef3a9ee7660c395b0a041c7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/canonical/f039b4e7cf0203df9fac48dad820b2b7.svg b/docs/images/chapters/canonical/f039b4e7cf0203df9fac48dad820b2b7.svg index 31325d78..04c0bbfc 100644 --- a/docs/images/chapters/canonical/f039b4e7cf0203df9fac48dad820b2b7.svg +++ b/docs/images/chapters/canonical/f039b4e7cf0203df9fac48dad820b2b7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/06ae1e3fdc660e59d618e0760e8e9ab5.svg b/docs/images/chapters/catmullconv/06ae1e3fdc660e59d618e0760e8e9ab5.svg index f3b0a47d..37e9a3a1 100644 --- a/docs/images/chapters/catmullconv/06ae1e3fdc660e59d618e0760e8e9ab5.svg +++ b/docs/images/chapters/catmullconv/06ae1e3fdc660e59d618e0760e8e9ab5.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/169fd85a95e4d16fe289a75583017a11.svg b/docs/images/chapters/catmullconv/169fd85a95e4d16fe289a75583017a11.svg index e6579ea8..de960168 100644 --- a/docs/images/chapters/catmullconv/169fd85a95e4d16fe289a75583017a11.svg +++ b/docs/images/chapters/catmullconv/169fd85a95e4d16fe289a75583017a11.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/1811b59c5ab9233f08590396e5d03303.svg b/docs/images/chapters/catmullconv/1811b59c5ab9233f08590396e5d03303.svg index 41acb642..7a0d16a8 100644 --- a/docs/images/chapters/catmullconv/1811b59c5ab9233f08590396e5d03303.svg +++ b/docs/images/chapters/catmullconv/1811b59c5ab9233f08590396e5d03303.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/1b8a782f7540503d38067317e4cd00b0.svg b/docs/images/chapters/catmullconv/1b8a782f7540503d38067317e4cd00b0.svg index bc0ef446..a96e63eb 100644 --- a/docs/images/chapters/catmullconv/1b8a782f7540503d38067317e4cd00b0.svg +++ b/docs/images/chapters/catmullconv/1b8a782f7540503d38067317e4cd00b0.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/26363fc09f8cf2d41ea5b4256656bb6d.svg b/docs/images/chapters/catmullconv/26363fc09f8cf2d41ea5b4256656bb6d.svg index 0d73182c..d1522362 100644 --- a/docs/images/chapters/catmullconv/26363fc09f8cf2d41ea5b4256656bb6d.svg +++ b/docs/images/chapters/catmullconv/26363fc09f8cf2d41ea5b4256656bb6d.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/2844a4f4d222374a25b5f673c94679d9.svg b/docs/images/chapters/catmullconv/2844a4f4d222374a25b5f673c94679d9.svg index bb3f7d82..667c34d1 100644 --- a/docs/images/chapters/catmullconv/2844a4f4d222374a25b5f673c94679d9.svg +++ b/docs/images/chapters/catmullconv/2844a4f4d222374a25b5f673c94679d9.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/3ea54fe939d076f8db605c5b480e7db0.svg b/docs/images/chapters/catmullconv/3ea54fe939d076f8db605c5b480e7db0.svg index 8d1358c5..326350af 100644 --- a/docs/images/chapters/catmullconv/3ea54fe939d076f8db605c5b480e7db0.svg +++ b/docs/images/chapters/catmullconv/3ea54fe939d076f8db605c5b480e7db0.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/4d524810417b4caffedd13af23135f5b.svg b/docs/images/chapters/catmullconv/4d524810417b4caffedd13af23135f5b.svg index 03c46584..4a923a8e 100644 --- a/docs/images/chapters/catmullconv/4d524810417b4caffedd13af23135f5b.svg +++ b/docs/images/chapters/catmullconv/4d524810417b4caffedd13af23135f5b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/5f2750de827497375d9a915f96686885.svg b/docs/images/chapters/catmullconv/5f2750de827497375d9a915f96686885.svg index bbc2f617..336cc086 100644 --- a/docs/images/chapters/catmullconv/5f2750de827497375d9a915f96686885.svg +++ b/docs/images/chapters/catmullconv/5f2750de827497375d9a915f96686885.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/78ac9df086ec19147414359369b563fc.svg b/docs/images/chapters/catmullconv/78ac9df086ec19147414359369b563fc.svg index 3497c999..a887711e 100644 --- a/docs/images/chapters/catmullconv/78ac9df086ec19147414359369b563fc.svg +++ b/docs/images/chapters/catmullconv/78ac9df086ec19147414359369b563fc.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/79e333cd0c569657eea033b04fb5e61b.svg b/docs/images/chapters/catmullconv/79e333cd0c569657eea033b04fb5e61b.svg index 2650db3d..4697a3ec 100644 --- a/docs/images/chapters/catmullconv/79e333cd0c569657eea033b04fb5e61b.svg +++ b/docs/images/chapters/catmullconv/79e333cd0c569657eea033b04fb5e61b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/841fb6a2a035c9bcf5a2d46f2a67709b.svg b/docs/images/chapters/catmullconv/841fb6a2a035c9bcf5a2d46f2a67709b.svg index 91f8e7e9..36365389 100644 --- a/docs/images/chapters/catmullconv/841fb6a2a035c9bcf5a2d46f2a67709b.svg +++ b/docs/images/chapters/catmullconv/841fb6a2a035c9bcf5a2d46f2a67709b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/8f56909fcb62b8eef18b9b9559575c13.svg b/docs/images/chapters/catmullconv/8f56909fcb62b8eef18b9b9559575c13.svg index 6976feb2..ad67f783 100644 --- a/docs/images/chapters/catmullconv/8f56909fcb62b8eef18b9b9559575c13.svg +++ b/docs/images/chapters/catmullconv/8f56909fcb62b8eef18b9b9559575c13.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/9215d05705c8e8a7ebd718ae6f690371.svg b/docs/images/chapters/catmullconv/9215d05705c8e8a7ebd718ae6f690371.svg index d880b477..8612576c 100644 --- a/docs/images/chapters/catmullconv/9215d05705c8e8a7ebd718ae6f690371.svg +++ b/docs/images/chapters/catmullconv/9215d05705c8e8a7ebd718ae6f690371.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/a47b072a325812ac4f0ff52c22792588.svg b/docs/images/chapters/catmullconv/a47b072a325812ac4f0ff52c22792588.svg index 2ad281e0..166d50b1 100644 --- a/docs/images/chapters/catmullconv/a47b072a325812ac4f0ff52c22792588.svg +++ b/docs/images/chapters/catmullconv/a47b072a325812ac4f0ff52c22792588.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/b21386f86bef8894f108c5441dad10de.svg b/docs/images/chapters/catmullconv/b21386f86bef8894f108c5441dad10de.svg index 33417bbf..b442ce32 100644 --- a/docs/images/chapters/catmullconv/b21386f86bef8894f108c5441dad10de.svg +++ b/docs/images/chapters/catmullconv/b21386f86bef8894f108c5441dad10de.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/ba31c32eba62f1e3b15066cd5ddda597.svg b/docs/images/chapters/catmullconv/ba31c32eba62f1e3b15066cd5ddda597.svg index f4f9bc9b..3f6aa6a8 100644 --- a/docs/images/chapters/catmullconv/ba31c32eba62f1e3b15066cd5ddda597.svg +++ b/docs/images/chapters/catmullconv/ba31c32eba62f1e3b15066cd5ddda597.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/cbdd46d5e2e1a6202ef46fb03711ebe4.svg b/docs/images/chapters/catmullconv/cbdd46d5e2e1a6202ef46fb03711ebe4.svg index 7a3d8ee3..d680eaa7 100644 --- a/docs/images/chapters/catmullconv/cbdd46d5e2e1a6202ef46fb03711ebe4.svg +++ b/docs/images/chapters/catmullconv/cbdd46d5e2e1a6202ef46fb03711ebe4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/cc1e2ff43350c32f0ae9ba9a7652b8fb.svg b/docs/images/chapters/catmullconv/cc1e2ff43350c32f0ae9ba9a7652b8fb.svg index d880b477..8612576c 100644 --- a/docs/images/chapters/catmullconv/cc1e2ff43350c32f0ae9ba9a7652b8fb.svg +++ b/docs/images/chapters/catmullconv/cc1e2ff43350c32f0ae9ba9a7652b8fb.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/e3d30ab368dcead1411532ce3814d3f3.svg b/docs/images/chapters/catmullconv/e3d30ab368dcead1411532ce3814d3f3.svg index 8832a55e..41cb5446 100644 --- a/docs/images/chapters/catmullconv/e3d30ab368dcead1411532ce3814d3f3.svg +++ b/docs/images/chapters/catmullconv/e3d30ab368dcead1411532ce3814d3f3.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/eae7f01976e511ee38b08b6edc8765d2.svg b/docs/images/chapters/catmullconv/eae7f01976e511ee38b08b6edc8765d2.svg index 7c783bfd..4da99e81 100644 --- a/docs/images/chapters/catmullconv/eae7f01976e511ee38b08b6edc8765d2.svg +++ b/docs/images/chapters/catmullconv/eae7f01976e511ee38b08b6edc8765d2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/f08e34395ce2812276fd70548f805041.svg b/docs/images/chapters/catmullconv/f08e34395ce2812276fd70548f805041.svg index 2ae488c9..434c9986 100644 --- a/docs/images/chapters/catmullconv/f08e34395ce2812276fd70548f805041.svg +++ b/docs/images/chapters/catmullconv/f08e34395ce2812276fd70548f805041.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/f2b2a16a41d134ce0dfd544ab77ff25e.svg b/docs/images/chapters/catmullconv/f2b2a16a41d134ce0dfd544ab77ff25e.svg index aa26f769..72879fca 100644 --- a/docs/images/chapters/catmullconv/f2b2a16a41d134ce0dfd544ab77ff25e.svg +++ b/docs/images/chapters/catmullconv/f2b2a16a41d134ce0dfd544ab77ff25e.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/f41487aff3e34fafd5d4ee5979f133f1.svg b/docs/images/chapters/catmullconv/f41487aff3e34fafd5d4ee5979f133f1.svg index a5bec69b..03cc4061 100644 --- a/docs/images/chapters/catmullconv/f41487aff3e34fafd5d4ee5979f133f1.svg +++ b/docs/images/chapters/catmullconv/f41487aff3e34fafd5d4ee5979f133f1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/catmullconv/f814bb8d627f9c8f33b347c1cf13d4c7.svg b/docs/images/chapters/catmullconv/f814bb8d627f9c8f33b347c1cf13d4c7.svg index 3e92ede9..e14bef1b 100644 --- a/docs/images/chapters/catmullconv/f814bb8d627f9c8f33b347c1cf13d4c7.svg +++ b/docs/images/chapters/catmullconv/f814bb8d627f9c8f33b347c1cf13d4c7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/7754bc3c96ae3c90162fec3bd46bedff.svg b/docs/images/chapters/circles/7754bc3c96ae3c90162fec3bd46bedff.svg index 44ae6bbb..3f2fe19e 100644 --- a/docs/images/chapters/circles/7754bc3c96ae3c90162fec3bd46bedff.svg +++ b/docs/images/chapters/circles/7754bc3c96ae3c90162fec3bd46bedff.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/8374c4190d6213b0ac0621481afaa754.svg b/docs/images/chapters/circles/8374c4190d6213b0ac0621481afaa754.svg index a5458b6c..3730c296 100644 --- a/docs/images/chapters/circles/8374c4190d6213b0ac0621481afaa754.svg +++ b/docs/images/chapters/circles/8374c4190d6213b0ac0621481afaa754.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/9e4d886c372f916f6511c41245ceee39.svg b/docs/images/chapters/circles/9e4d886c372f916f6511c41245ceee39.svg index 99b7bbe7..d55b4a7e 100644 --- a/docs/images/chapters/circles/9e4d886c372f916f6511c41245ceee39.svg +++ b/docs/images/chapters/circles/9e4d886c372f916f6511c41245ceee39.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/a127f926eced2751a09c54bf7c361b4a.svg b/docs/images/chapters/circles/a127f926eced2751a09c54bf7c361b4a.svg index 562ac87e..79bfb625 100644 --- a/docs/images/chapters/circles/a127f926eced2751a09c54bf7c361b4a.svg +++ b/docs/images/chapters/circles/a127f926eced2751a09c54bf7c361b4a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/adbd056f4b8fcd05b1d4f2fce27d7657.svg b/docs/images/chapters/circles/adbd056f4b8fcd05b1d4f2fce27d7657.svg index a3298b57..fb584165 100644 --- a/docs/images/chapters/circles/adbd056f4b8fcd05b1d4f2fce27d7657.svg +++ b/docs/images/chapters/circles/adbd056f4b8fcd05b1d4f2fce27d7657.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/b5d864e9ed0c44c56d454fbaa4218d5e.svg b/docs/images/chapters/circles/b5d864e9ed0c44c56d454fbaa4218d5e.svg index eee1d8fa..438d76fd 100644 --- a/docs/images/chapters/circles/b5d864e9ed0c44c56d454fbaa4218d5e.svg +++ b/docs/images/chapters/circles/b5d864e9ed0c44c56d454fbaa4218d5e.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/c22f6d343ee0cce7bff6a617c946ca17.svg b/docs/images/chapters/circles/c22f6d343ee0cce7bff6a617c946ca17.svg index ba2e8445..e1ff7e7c 100644 --- a/docs/images/chapters/circles/c22f6d343ee0cce7bff6a617c946ca17.svg +++ b/docs/images/chapters/circles/c22f6d343ee0cce7bff6a617c946ca17.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/df87674db0f31fc3944aaeb6b890e196.svg b/docs/images/chapters/circles/df87674db0f31fc3944aaeb6b890e196.svg index c36d08d2..39f8190e 100644 --- a/docs/images/chapters/circles/df87674db0f31fc3944aaeb6b890e196.svg +++ b/docs/images/chapters/circles/df87674db0f31fc3944aaeb6b890e196.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/e1059e611aa1e51db41f9ce0b4ebb95a.svg b/docs/images/chapters/circles/e1059e611aa1e51db41f9ce0b4ebb95a.svg index 11112bc8..5863c8fc 100644 --- a/docs/images/chapters/circles/e1059e611aa1e51db41f9ce0b4ebb95a.svg +++ b/docs/images/chapters/circles/e1059e611aa1e51db41f9ce0b4ebb95a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/ef3ab62bb896019c6157c85aae5d1ed3.svg b/docs/images/chapters/circles/ef3ab62bb896019c6157c85aae5d1ed3.svg index 06f527af..5eb24ed1 100644 --- a/docs/images/chapters/circles/ef3ab62bb896019c6157c85aae5d1ed3.svg +++ b/docs/images/chapters/circles/ef3ab62bb896019c6157c85aae5d1ed3.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles/fe32474b4616ee9478e1308308f1b6bf.svg b/docs/images/chapters/circles/fe32474b4616ee9478e1308308f1b6bf.svg index dea287d7..a3533922 100644 --- a/docs/images/chapters/circles/fe32474b4616ee9478e1308308f1b6bf.svg +++ b/docs/images/chapters/circles/fe32474b4616ee9478e1308308f1b6bf.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/circles_cubic/fe32474b4616ee9478e1308308f1b6bf.svg b/docs/images/chapters/circles_cubic/fe32474b4616ee9478e1308308f1b6bf.svg index a3533922..dea287d7 100644 --- a/docs/images/chapters/circles_cubic/fe32474b4616ee9478e1308308f1b6bf.svg +++ b/docs/images/chapters/circles_cubic/fe32474b4616ee9478e1308308f1b6bf.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/control/2a0635829051977b265b64ef204f718e.png b/docs/images/chapters/control/2a0635829051977b265b64ef204f718e.png index be703f1c..4659b5a2 100644 Binary files a/docs/images/chapters/control/2a0635829051977b265b64ef204f718e.png and b/docs/images/chapters/control/2a0635829051977b265b64ef204f718e.png differ diff --git a/docs/images/chapters/control/989f4ca49d7099802cc0345dbeddca8c.png b/docs/images/chapters/control/989f4ca49d7099802cc0345dbeddca8c.png index d1403643..5cfe86ff 100644 Binary files a/docs/images/chapters/control/989f4ca49d7099802cc0345dbeddca8c.png and b/docs/images/chapters/control/989f4ca49d7099802cc0345dbeddca8c.png differ diff --git a/docs/images/chapters/control/fca18b2602929f80e68d8964832f0f44.png b/docs/images/chapters/control/fca18b2602929f80e68d8964832f0f44.png index a1940cfb..fc16b535 100644 Binary files a/docs/images/chapters/control/fca18b2602929f80e68d8964832f0f44.png and b/docs/images/chapters/control/fca18b2602929f80e68d8964832f0f44.png differ diff --git a/docs/images/chapters/curvature/6ed4fd2ead35c57984caddf9fe375a5f.svg b/docs/images/chapters/curvature/6ed4fd2ead35c57984caddf9fe375a5f.svg index e2033566..499a50f9 100644 --- a/docs/images/chapters/curvature/6ed4fd2ead35c57984caddf9fe375a5f.svg +++ b/docs/images/chapters/curvature/6ed4fd2ead35c57984caddf9fe375a5f.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvature/828333034b4fed8e248683760d6bc6f4.svg b/docs/images/chapters/curvature/828333034b4fed8e248683760d6bc6f4.svg index 0a147ccc..5bcd4e69 100644 --- a/docs/images/chapters/curvature/828333034b4fed8e248683760d6bc6f4.svg +++ b/docs/images/chapters/curvature/828333034b4fed8e248683760d6bc6f4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvature/d9c893051586eb8d9de51c0ae1ef8fae.svg b/docs/images/chapters/curvature/d9c893051586eb8d9de51c0ae1ef8fae.svg index b5e47ae7..818992fd 100644 --- a/docs/images/chapters/curvature/d9c893051586eb8d9de51c0ae1ef8fae.svg +++ b/docs/images/chapters/curvature/d9c893051586eb8d9de51c0ae1ef8fae.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/03ec73258d5c95eed39a2ea8665e0b07.svg b/docs/images/chapters/curvefitting/03ec73258d5c95eed39a2ea8665e0b07.svg index 98588d0c..4bcd6340 100644 --- a/docs/images/chapters/curvefitting/03ec73258d5c95eed39a2ea8665e0b07.svg +++ b/docs/images/chapters/curvefitting/03ec73258d5c95eed39a2ea8665e0b07.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/08f4beaebf83dca594ad125bdca7e436.svg b/docs/images/chapters/curvefitting/08f4beaebf83dca594ad125bdca7e436.svg index 09378509..0e4504c1 100644 --- a/docs/images/chapters/curvefitting/08f4beaebf83dca594ad125bdca7e436.svg +++ b/docs/images/chapters/curvefitting/08f4beaebf83dca594ad125bdca7e436.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/283bc9e8fe59a78d3c74860f62a66ecb.svg b/docs/images/chapters/curvefitting/283bc9e8fe59a78d3c74860f62a66ecb.svg index 0e380709..9c441a9f 100644 --- a/docs/images/chapters/curvefitting/283bc9e8fe59a78d3c74860f62a66ecb.svg +++ b/docs/images/chapters/curvefitting/283bc9e8fe59a78d3c74860f62a66ecb.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/2b8334727d3b004c6e87263fec6b32b7.svg b/docs/images/chapters/curvefitting/2b8334727d3b004c6e87263fec6b32b7.svg index e618c6a9..449b7523 100644 --- a/docs/images/chapters/curvefitting/2b8334727d3b004c6e87263fec6b32b7.svg +++ b/docs/images/chapters/curvefitting/2b8334727d3b004c6e87263fec6b32b7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/2bef3da3828d63d690460ce9947dbde2.svg b/docs/images/chapters/curvefitting/2bef3da3828d63d690460ce9947dbde2.svg index 10801872..5730a767 100644 --- a/docs/images/chapters/curvefitting/2bef3da3828d63d690460ce9947dbde2.svg +++ b/docs/images/chapters/curvefitting/2bef3da3828d63d690460ce9947dbde2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/2d42758fba3370f52191306752c2705c.svg b/docs/images/chapters/curvefitting/2d42758fba3370f52191306752c2705c.svg index 8837c467..5bdd5256 100644 --- a/docs/images/chapters/curvefitting/2d42758fba3370f52191306752c2705c.svg +++ b/docs/images/chapters/curvefitting/2d42758fba3370f52191306752c2705c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/4ffad56e281ee79d0688e93033429f0a.svg b/docs/images/chapters/curvefitting/4ffad56e281ee79d0688e93033429f0a.svg index 92462c72..e4293a60 100644 --- a/docs/images/chapters/curvefitting/4ffad56e281ee79d0688e93033429f0a.svg +++ b/docs/images/chapters/curvefitting/4ffad56e281ee79d0688e93033429f0a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/5f7fcb86ae1c19612b9fe02e23229e31.svg b/docs/images/chapters/curvefitting/5f7fcb86ae1c19612b9fe02e23229e31.svg index 158f3b2d..556e8dab 100644 --- a/docs/images/chapters/curvefitting/5f7fcb86ae1c19612b9fe02e23229e31.svg +++ b/docs/images/chapters/curvefitting/5f7fcb86ae1c19612b9fe02e23229e31.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/6202d7bd150c852b432d807c40fb1647.svg b/docs/images/chapters/curvefitting/6202d7bd150c852b432d807c40fb1647.svg index 309d4b6d..4a70871d 100644 --- a/docs/images/chapters/curvefitting/6202d7bd150c852b432d807c40fb1647.svg +++ b/docs/images/chapters/curvefitting/6202d7bd150c852b432d807c40fb1647.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/78b8ba1aba2e4c9ad3f7890299c90152.svg b/docs/images/chapters/curvefitting/78b8ba1aba2e4c9ad3f7890299c90152.svg index 88d9ca0d..08bd2b23 100644 --- a/docs/images/chapters/curvefitting/78b8ba1aba2e4c9ad3f7890299c90152.svg +++ b/docs/images/chapters/curvefitting/78b8ba1aba2e4c9ad3f7890299c90152.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/7e5d59272621baf942bc722208ce70c2.svg b/docs/images/chapters/curvefitting/7e5d59272621baf942bc722208ce70c2.svg index 3c9b7125..24fa6350 100644 --- a/docs/images/chapters/curvefitting/7e5d59272621baf942bc722208ce70c2.svg +++ b/docs/images/chapters/curvefitting/7e5d59272621baf942bc722208ce70c2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/7eada6f12045423de24d9a2ab8e293b1.svg b/docs/images/chapters/curvefitting/7eada6f12045423de24d9a2ab8e293b1.svg index 0e69dda5..13cd868e 100644 --- a/docs/images/chapters/curvefitting/7eada6f12045423de24d9a2ab8e293b1.svg +++ b/docs/images/chapters/curvefitting/7eada6f12045423de24d9a2ab8e293b1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/875ca8eea72e727ccb881b4c0b6a3224.svg b/docs/images/chapters/curvefitting/875ca8eea72e727ccb881b4c0b6a3224.svg index 87002d07..33df76b5 100644 --- a/docs/images/chapters/curvefitting/875ca8eea72e727ccb881b4c0b6a3224.svg +++ b/docs/images/chapters/curvefitting/875ca8eea72e727ccb881b4c0b6a3224.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/8d09f2be2c6db79ee966f170ffc25815.svg b/docs/images/chapters/curvefitting/8d09f2be2c6db79ee966f170ffc25815.svg index 6c6c2d37..fcde3a3d 100644 --- a/docs/images/chapters/curvefitting/8d09f2be2c6db79ee966f170ffc25815.svg +++ b/docs/images/chapters/curvefitting/8d09f2be2c6db79ee966f170ffc25815.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/9151c0fdf9689ee598a2d029ab2ffe34.svg b/docs/images/chapters/curvefitting/9151c0fdf9689ee598a2d029ab2ffe34.svg index 7397a05a..d5c6d91c 100644 --- a/docs/images/chapters/curvefitting/9151c0fdf9689ee598a2d029ab2ffe34.svg +++ b/docs/images/chapters/curvefitting/9151c0fdf9689ee598a2d029ab2ffe34.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/94acb5850778dcb16c2ba3cfa676f537.svg b/docs/images/chapters/curvefitting/94acb5850778dcb16c2ba3cfa676f537.svg index 6b97b0a5..f414d4c3 100644 --- a/docs/images/chapters/curvefitting/94acb5850778dcb16c2ba3cfa676f537.svg +++ b/docs/images/chapters/curvefitting/94acb5850778dcb16c2ba3cfa676f537.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/ab334858d3fa309cc1a5ba535a2ca168.svg b/docs/images/chapters/curvefitting/ab334858d3fa309cc1a5ba535a2ca168.svg index d5f7c27a..f18c9c48 100644 --- a/docs/images/chapters/curvefitting/ab334858d3fa309cc1a5ba535a2ca168.svg +++ b/docs/images/chapters/curvefitting/ab334858d3fa309cc1a5ba535a2ca168.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/bd8e8e294eec10d2bf6ef857c7c0c2c2.svg b/docs/images/chapters/curvefitting/bd8e8e294eec10d2bf6ef857c7c0c2c2.svg index 869937f0..52c27d84 100644 --- a/docs/images/chapters/curvefitting/bd8e8e294eec10d2bf6ef857c7c0c2c2.svg +++ b/docs/images/chapters/curvefitting/bd8e8e294eec10d2bf6ef857c7c0c2c2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/curvefitting/d84d1c71a3ce1918f53eaf8f9fe98ac4.svg b/docs/images/chapters/curvefitting/d84d1c71a3ce1918f53eaf8f9fe98ac4.svg index 3008ea83..ea714679 100644 --- a/docs/images/chapters/curvefitting/d84d1c71a3ce1918f53eaf8f9fe98ac4.svg +++ b/docs/images/chapters/curvefitting/d84d1c71a3ce1918f53eaf8f9fe98ac4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/066a910ae6aba69c40a338320759cdd1.svg b/docs/images/chapters/explanation/066a910ae6aba69c40a338320759cdd1.svg index 50713c42..6f802d03 100644 --- a/docs/images/chapters/explanation/066a910ae6aba69c40a338320759cdd1.svg +++ b/docs/images/chapters/explanation/066a910ae6aba69c40a338320759cdd1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/0f5cffd58e864fec6739a57664eb8cbd.svg b/docs/images/chapters/explanation/0f5cffd58e864fec6739a57664eb8cbd.svg index 9f81756b..69228905 100644 --- a/docs/images/chapters/explanation/0f5cffd58e864fec6739a57664eb8cbd.svg +++ b/docs/images/chapters/explanation/0f5cffd58e864fec6739a57664eb8cbd.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/1caef9931f954e32eae5067b732c1018.svg b/docs/images/chapters/explanation/1caef9931f954e32eae5067b732c1018.svg index 936e0755..0466c0f7 100644 --- a/docs/images/chapters/explanation/1caef9931f954e32eae5067b732c1018.svg +++ b/docs/images/chapters/explanation/1caef9931f954e32eae5067b732c1018.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/2adc12d0cff01d40d9e1702014a7dc19.svg b/docs/images/chapters/explanation/2adc12d0cff01d40d9e1702014a7dc19.svg index b20000a0..62b4da60 100644 --- a/docs/images/chapters/explanation/2adc12d0cff01d40d9e1702014a7dc19.svg +++ b/docs/images/chapters/explanation/2adc12d0cff01d40d9e1702014a7dc19.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/4cf6fb369841e2c5d36e5567a8db4306.svg b/docs/images/chapters/explanation/4cf6fb369841e2c5d36e5567a8db4306.svg index 1eccf6ad..6e2362be 100644 --- a/docs/images/chapters/explanation/4cf6fb369841e2c5d36e5567a8db4306.svg +++ b/docs/images/chapters/explanation/4cf6fb369841e2c5d36e5567a8db4306.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/9a6d17c362980775f1425d0d2ad9a36a.svg b/docs/images/chapters/explanation/9a6d17c362980775f1425d0d2ad9a36a.svg index d307f8b4..3b48115f 100644 --- a/docs/images/chapters/explanation/9a6d17c362980775f1425d0d2ad9a36a.svg +++ b/docs/images/chapters/explanation/9a6d17c362980775f1425d0d2ad9a36a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/9c18f76e76cf684ecd217ad8facc2e93.svg b/docs/images/chapters/explanation/9c18f76e76cf684ecd217ad8facc2e93.svg index dfbbde5a..412f4573 100644 --- a/docs/images/chapters/explanation/9c18f76e76cf684ecd217ad8facc2e93.svg +++ b/docs/images/chapters/explanation/9c18f76e76cf684ecd217ad8facc2e93.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/bb06cb82d372f822a7b35e661502bd72.svg b/docs/images/chapters/explanation/bb06cb82d372f822a7b35e661502bd72.svg index 965f18de..7ebe5497 100644 --- a/docs/images/chapters/explanation/bb06cb82d372f822a7b35e661502bd72.svg +++ b/docs/images/chapters/explanation/bb06cb82d372f822a7b35e661502bd72.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/explanation/e107caca1577e44293cd207388ac939c.svg b/docs/images/chapters/explanation/e107caca1577e44293cd207388ac939c.svg index 68a70358..a0290fb4 100644 --- a/docs/images/chapters/explanation/e107caca1577e44293cd207388ac939c.svg +++ b/docs/images/chapters/explanation/e107caca1577e44293cd207388ac939c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extended/b80a1cac1f9ec476d6f6646ce0e154e7.svg b/docs/images/chapters/extended/b80a1cac1f9ec476d6f6646ce0e154e7.svg index ac4c488f..bb85865d 100644 --- a/docs/images/chapters/extended/b80a1cac1f9ec476d6f6646ce0e154e7.svg +++ b/docs/images/chapters/extended/b80a1cac1f9ec476d6f6646ce0e154e7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extended/d930dea961b40f4810708bd6746221a2.svg b/docs/images/chapters/extended/d930dea961b40f4810708bd6746221a2.svg index 9f7786ca..2391cb17 100644 --- a/docs/images/chapters/extended/d930dea961b40f4810708bd6746221a2.svg +++ b/docs/images/chapters/extended/d930dea961b40f4810708bd6746221a2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/0ec5cc72a428d75defb480530b50d720.svg b/docs/images/chapters/extremities/0ec5cc72a428d75defb480530b50d720.svg index c810f40e..ae058401 100644 --- a/docs/images/chapters/extremities/0ec5cc72a428d75defb480530b50d720.svg +++ b/docs/images/chapters/extremities/0ec5cc72a428d75defb480530b50d720.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/1c0367fad2a0d6946db1f55a8520793a.svg b/docs/images/chapters/extremities/1c0367fad2a0d6946db1f55a8520793a.svg index e134bbd6..3282e1f1 100644 --- a/docs/images/chapters/extremities/1c0367fad2a0d6946db1f55a8520793a.svg +++ b/docs/images/chapters/extremities/1c0367fad2a0d6946db1f55a8520793a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/6db78123d4b676ffdf85d53670c77468.svg b/docs/images/chapters/extremities/6db78123d4b676ffdf85d53670c77468.svg index 38a6dd1e..a69d2227 100644 --- a/docs/images/chapters/extremities/6db78123d4b676ffdf85d53670c77468.svg +++ b/docs/images/chapters/extremities/6db78123d4b676ffdf85d53670c77468.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/997a8cc704c0ab0e364cb8b532df90b0.svg b/docs/images/chapters/extremities/997a8cc704c0ab0e364cb8b532df90b0.svg index 2489c8bd..ec959270 100644 --- a/docs/images/chapters/extremities/997a8cc704c0ab0e364cb8b532df90b0.svg +++ b/docs/images/chapters/extremities/997a8cc704c0ab0e364cb8b532df90b0.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/c621cc41f6f22ee1beedbcb510fa5b6b.svg b/docs/images/chapters/extremities/c621cc41f6f22ee1beedbcb510fa5b6b.svg index baa9ab6a..d3b2049c 100644 --- a/docs/images/chapters/extremities/c621cc41f6f22ee1beedbcb510fa5b6b.svg +++ b/docs/images/chapters/extremities/c621cc41f6f22ee1beedbcb510fa5b6b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/d9e66caeb45b6643112ce3d971b17e5b.svg b/docs/images/chapters/extremities/d9e66caeb45b6643112ce3d971b17e5b.svg index 64d12c1e..8ef46d1c 100644 --- a/docs/images/chapters/extremities/d9e66caeb45b6643112ce3d971b17e5b.svg +++ b/docs/images/chapters/extremities/d9e66caeb45b6643112ce3d971b17e5b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/ddc6f99a543afad25c55cf16b9deeed9.svg b/docs/images/chapters/extremities/ddc6f99a543afad25c55cf16b9deeed9.svg index f078c502..a3127a01 100644 --- a/docs/images/chapters/extremities/ddc6f99a543afad25c55cf16b9deeed9.svg +++ b/docs/images/chapters/extremities/ddc6f99a543afad25c55cf16b9deeed9.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/extremities/e06ec558d99b53e559d24524f4201951.svg b/docs/images/chapters/extremities/e06ec558d99b53e559d24524f4201951.svg index ed3b2aee..9bd72aa8 100644 --- a/docs/images/chapters/extremities/e06ec558d99b53e559d24524f4201951.svg +++ b/docs/images/chapters/extremities/e06ec558d99b53e559d24524f4201951.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/1679090a942a43d27f886f236fc8d62b.svg b/docs/images/chapters/inflections/1679090a942a43d27f886f236fc8d62b.svg index 05687051..be62b241 100644 --- a/docs/images/chapters/inflections/1679090a942a43d27f886f236fc8d62b.svg +++ b/docs/images/chapters/inflections/1679090a942a43d27f886f236fc8d62b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/2029bca9f4fa15739553636af99b70a8.svg b/docs/images/chapters/inflections/2029bca9f4fa15739553636af99b70a8.svg index 9dded3a2..c745eba0 100644 --- a/docs/images/chapters/inflections/2029bca9f4fa15739553636af99b70a8.svg +++ b/docs/images/chapters/inflections/2029bca9f4fa15739553636af99b70a8.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/4b5c7d0bf0fcd769db007dd98d4a024d.svg b/docs/images/chapters/inflections/4b5c7d0bf0fcd769db007dd98d4a024d.svg index a33d6d45..c3b524e8 100644 --- a/docs/images/chapters/inflections/4b5c7d0bf0fcd769db007dd98d4a024d.svg +++ b/docs/images/chapters/inflections/4b5c7d0bf0fcd769db007dd98d4a024d.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/4d78ebcf8626f777725d67d3672fa480.svg b/docs/images/chapters/inflections/4d78ebcf8626f777725d67d3672fa480.svg index b0dc06eb..bbcccafc 100644 --- a/docs/images/chapters/inflections/4d78ebcf8626f777725d67d3672fa480.svg +++ b/docs/images/chapters/inflections/4d78ebcf8626f777725d67d3672fa480.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/7c9762c0e04693eb743905cdc0487f8b.svg b/docs/images/chapters/inflections/7c9762c0e04693eb743905cdc0487f8b.svg index 1c0bc505..2568ebf3 100644 --- a/docs/images/chapters/inflections/7c9762c0e04693eb743905cdc0487f8b.svg +++ b/docs/images/chapters/inflections/7c9762c0e04693eb743905cdc0487f8b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/97b34ad5920612574d1b2a1a9d22d571.svg b/docs/images/chapters/inflections/97b34ad5920612574d1b2a1a9d22d571.svg index 6b2e9b47..23682936 100644 --- a/docs/images/chapters/inflections/97b34ad5920612574d1b2a1a9d22d571.svg +++ b/docs/images/chapters/inflections/97b34ad5920612574d1b2a1a9d22d571.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/b2433959e1f451fa3bf238fc37e04527.svg b/docs/images/chapters/inflections/b2433959e1f451fa3bf238fc37e04527.svg index 217baee2..25450b67 100644 --- a/docs/images/chapters/inflections/b2433959e1f451fa3bf238fc37e04527.svg +++ b/docs/images/chapters/inflections/b2433959e1f451fa3bf238fc37e04527.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/inflections/bafdb6583323bda71d9a15c02d1fdec2.svg b/docs/images/chapters/inflections/bafdb6583323bda71d9a15c02d1fdec2.svg index 1a05b531..90f0133c 100644 --- a/docs/images/chapters/inflections/bafdb6583323bda71d9a15c02d1fdec2.svg +++ b/docs/images/chapters/inflections/bafdb6583323bda71d9a15c02d1fdec2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/molding/079d318ad693b6b17413a91f5de06be8.svg b/docs/images/chapters/molding/079d318ad693b6b17413a91f5de06be8.svg index de6c0325..155cb793 100644 --- a/docs/images/chapters/molding/079d318ad693b6b17413a91f5de06be8.svg +++ b/docs/images/chapters/molding/079d318ad693b6b17413a91f5de06be8.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/molding/82a99caec5f84fb26dce28277377c041.svg b/docs/images/chapters/molding/82a99caec5f84fb26dce28277377c041.svg index 59451769..db0bf546 100644 --- a/docs/images/chapters/molding/82a99caec5f84fb26dce28277377c041.svg +++ b/docs/images/chapters/molding/82a99caec5f84fb26dce28277377c041.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/offsetting/1d4be24e5896dce3c16c8e71f9cc8881.svg b/docs/images/chapters/offsetting/1d4be24e5896dce3c16c8e71f9cc8881.svg index f797b8e8..c3bfbb35 100644 --- a/docs/images/chapters/offsetting/1d4be24e5896dce3c16c8e71f9cc8881.svg +++ b/docs/images/chapters/offsetting/1d4be24e5896dce3c16c8e71f9cc8881.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/offsetting/1d586b939b44ff9bdb42562a12ac2779.svg b/docs/images/chapters/offsetting/1d586b939b44ff9bdb42562a12ac2779.svg index c1764cbb..6a1bd9fe 100644 --- a/docs/images/chapters/offsetting/1d586b939b44ff9bdb42562a12ac2779.svg +++ b/docs/images/chapters/offsetting/1d586b939b44ff9bdb42562a12ac2779.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/offsetting/5bfee4f2ae27304475673d0596e42f9a.svg b/docs/images/chapters/offsetting/5bfee4f2ae27304475673d0596e42f9a.svg index fc705e15..93c47cd6 100644 --- a/docs/images/chapters/offsetting/5bfee4f2ae27304475673d0596e42f9a.svg +++ b/docs/images/chapters/offsetting/5bfee4f2ae27304475673d0596e42f9a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/offsetting/b262e50c085815421d94e120fc17f1c8.svg b/docs/images/chapters/offsetting/b262e50c085815421d94e120fc17f1c8.svg index c5b2375c..fb249f7a 100644 --- a/docs/images/chapters/offsetting/b262e50c085815421d94e120fc17f1c8.svg +++ b/docs/images/chapters/offsetting/b262e50c085815421d94e120fc17f1c8.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/offsetting/fa6c243de2aa78b7451e0086848dfdfc.svg b/docs/images/chapters/offsetting/fa6c243de2aa78b7451e0086848dfdfc.svg index 4be49407..e70572fb 100644 --- a/docs/images/chapters/offsetting/fa6c243de2aa78b7451e0086848dfdfc.svg +++ b/docs/images/chapters/offsetting/fa6c243de2aa78b7451e0086848dfdfc.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointcurves/3c7516c16a5dea95df741f4263cecd1c.svg b/docs/images/chapters/pointcurves/3c7516c16a5dea95df741f4263cecd1c.svg index b3600fb2..ec9fc5b2 100644 --- a/docs/images/chapters/pointcurves/3c7516c16a5dea95df741f4263cecd1c.svg +++ b/docs/images/chapters/pointcurves/3c7516c16a5dea95df741f4263cecd1c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointcurves/55d4f7ed095dfea8f9772208abc83b51.svg b/docs/images/chapters/pointcurves/55d4f7ed095dfea8f9772208abc83b51.svg index 41a86f90..4a14687e 100644 --- a/docs/images/chapters/pointcurves/55d4f7ed095dfea8f9772208abc83b51.svg +++ b/docs/images/chapters/pointcurves/55d4f7ed095dfea8f9772208abc83b51.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointcurves/6f0e2b6494d7dae2ea79a46a499d7ed4.svg b/docs/images/chapters/pointcurves/6f0e2b6494d7dae2ea79a46a499d7ed4.svg index c7598539..82f5fc9b 100644 --- a/docs/images/chapters/pointcurves/6f0e2b6494d7dae2ea79a46a499d7ed4.svg +++ b/docs/images/chapters/pointcurves/6f0e2b6494d7dae2ea79a46a499d7ed4.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointcurves/9203537b7dca98ebb2d7017c76100fde.svg b/docs/images/chapters/pointcurves/9203537b7dca98ebb2d7017c76100fde.svg index bc006d26..f8ffee33 100644 --- a/docs/images/chapters/pointcurves/9203537b7dca98ebb2d7017c76100fde.svg +++ b/docs/images/chapters/pointcurves/9203537b7dca98ebb2d7017c76100fde.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/009715fce01e46e7c07f87a8192a8c62.svg b/docs/images/chapters/pointvectors/009715fce01e46e7c07f87a8192a8c62.svg index 01f08451..6828b7e2 100644 --- a/docs/images/chapters/pointvectors/009715fce01e46e7c07f87a8192a8c62.svg +++ b/docs/images/chapters/pointvectors/009715fce01e46e7c07f87a8192a8c62.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/2a55cb2d23c25408aa10cfd8db13278b.svg b/docs/images/chapters/pointvectors/2a55cb2d23c25408aa10cfd8db13278b.svg index fe6be2d6..5d201cd1 100644 --- a/docs/images/chapters/pointvectors/2a55cb2d23c25408aa10cfd8db13278b.svg +++ b/docs/images/chapters/pointvectors/2a55cb2d23c25408aa10cfd8db13278b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/2dd2f89d1c762991a86526490a3deef6.svg b/docs/images/chapters/pointvectors/2dd2f89d1c762991a86526490a3deef6.svg index d7141093..b5155282 100644 --- a/docs/images/chapters/pointvectors/2dd2f89d1c762991a86526490a3deef6.svg +++ b/docs/images/chapters/pointvectors/2dd2f89d1c762991a86526490a3deef6.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/6101b2f8b69ebabba4a2c88456a32aa0.svg b/docs/images/chapters/pointvectors/6101b2f8b69ebabba4a2c88456a32aa0.svg index 74e46b65..a1f1f0a8 100644 --- a/docs/images/chapters/pointvectors/6101b2f8b69ebabba4a2c88456a32aa0.svg +++ b/docs/images/chapters/pointvectors/6101b2f8b69ebabba4a2c88456a32aa0.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/d236b7b2ad46c8ced1b43bb2a496379a.svg b/docs/images/chapters/pointvectors/d236b7b2ad46c8ced1b43bb2a496379a.svg index e5204b50..c324e547 100644 --- a/docs/images/chapters/pointvectors/d236b7b2ad46c8ced1b43bb2a496379a.svg +++ b/docs/images/chapters/pointvectors/d236b7b2ad46c8ced1b43bb2a496379a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors/deec095950fcd1f9c980be76a7093fe6.svg b/docs/images/chapters/pointvectors/deec095950fcd1f9c980be76a7093fe6.svg index 968dac30..5b863668 100644 --- a/docs/images/chapters/pointvectors/deec095950fcd1f9c980be76a7093fe6.svg +++ b/docs/images/chapters/pointvectors/deec095950fcd1f9c980be76a7093fe6.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/pointvectors3d/59b6ce3fcbf79da171d86e962597097e.png b/docs/images/chapters/pointvectors3d/59b6ce3fcbf79da171d86e962597097e.png index 95fcb150..aa8cb533 100644 Binary files a/docs/images/chapters/pointvectors3d/59b6ce3fcbf79da171d86e962597097e.png and b/docs/images/chapters/pointvectors3d/59b6ce3fcbf79da171d86e962597097e.png differ diff --git a/docs/images/chapters/pointvectors3d/9983328e50c2156c124bb1ea4ad5c05b.png b/docs/images/chapters/pointvectors3d/9983328e50c2156c124bb1ea4ad5c05b.png index 95fcb150..aa8cb533 100644 Binary files a/docs/images/chapters/pointvectors3d/9983328e50c2156c124bb1ea4ad5c05b.png and b/docs/images/chapters/pointvectors3d/9983328e50c2156c124bb1ea4ad5c05b.png differ diff --git a/docs/images/chapters/polybezier/408dd95905a5f001179c4da6051e49c5.svg b/docs/images/chapters/polybezier/408dd95905a5f001179c4da6051e49c5.svg index 4365bd35..cdb1acf9 100644 --- a/docs/images/chapters/polybezier/408dd95905a5f001179c4da6051e49c5.svg +++ b/docs/images/chapters/polybezier/408dd95905a5f001179c4da6051e49c5.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/polybezier/8c1b570b3efdfbbc39ddedb4adcaaff6.svg b/docs/images/chapters/polybezier/8c1b570b3efdfbbc39ddedb4adcaaff6.svg index 16c75145..5cc88838 100644 --- a/docs/images/chapters/polybezier/8c1b570b3efdfbbc39ddedb4adcaaff6.svg +++ b/docs/images/chapters/polybezier/8c1b570b3efdfbbc39ddedb4adcaaff6.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/1244a85c1f9044b6f77cb709c682159c.svg b/docs/images/chapters/reordering/1244a85c1f9044b6f77cb709c682159c.svg index f925f8be..cbe3e70d 100644 --- a/docs/images/chapters/reordering/1244a85c1f9044b6f77cb709c682159c.svg +++ b/docs/images/chapters/reordering/1244a85c1f9044b6f77cb709c682159c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/41e184228d85023abdadd6ce2acb54c7.svg b/docs/images/chapters/reordering/41e184228d85023abdadd6ce2acb54c7.svg index 8e3cb407..6c12ec56 100644 --- a/docs/images/chapters/reordering/41e184228d85023abdadd6ce2acb54c7.svg +++ b/docs/images/chapters/reordering/41e184228d85023abdadd6ce2acb54c7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/483c89c8726f7fd0dca0b7de339b04bd.svg b/docs/images/chapters/reordering/483c89c8726f7fd0dca0b7de339b04bd.svg index 30538744..e52344a0 100644 --- a/docs/images/chapters/reordering/483c89c8726f7fd0dca0b7de339b04bd.svg +++ b/docs/images/chapters/reordering/483c89c8726f7fd0dca0b7de339b04bd.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/4debbed5922d2bd84fd322c616872d20.svg b/docs/images/chapters/reordering/4debbed5922d2bd84fd322c616872d20.svg index 5ae35fa5..93db824d 100644 --- a/docs/images/chapters/reordering/4debbed5922d2bd84fd322c616872d20.svg +++ b/docs/images/chapters/reordering/4debbed5922d2bd84fd322c616872d20.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/71f47629388901b821976e034be159e4.png b/docs/images/chapters/reordering/71f47629388901b821976e034be159e4.png index 0450a9ec..d7b7242a 100644 Binary files a/docs/images/chapters/reordering/71f47629388901b821976e034be159e4.png and b/docs/images/chapters/reordering/71f47629388901b821976e034be159e4.png differ diff --git a/docs/images/chapters/reordering/773fdc86b686647c823b4f499aca3a35.svg b/docs/images/chapters/reordering/773fdc86b686647c823b4f499aca3a35.svg index 7c1ad8d9..f1cdecd6 100644 --- a/docs/images/chapters/reordering/773fdc86b686647c823b4f499aca3a35.svg +++ b/docs/images/chapters/reordering/773fdc86b686647c823b4f499aca3a35.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/7a9120997e4a4855ecda435553a7bbdf.svg b/docs/images/chapters/reordering/7a9120997e4a4855ecda435553a7bbdf.svg index 5c854ce4..39d5ef17 100644 --- a/docs/images/chapters/reordering/7a9120997e4a4855ecda435553a7bbdf.svg +++ b/docs/images/chapters/reordering/7a9120997e4a4855ecda435553a7bbdf.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/b2fda1dcce5bb13317aa42ebf5e7ea6c.svg b/docs/images/chapters/reordering/b2fda1dcce5bb13317aa42ebf5e7ea6c.svg index 90a19093..187f7a5a 100644 --- a/docs/images/chapters/reordering/b2fda1dcce5bb13317aa42ebf5e7ea6c.svg +++ b/docs/images/chapters/reordering/b2fda1dcce5bb13317aa42ebf5e7ea6c.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/d52f60b331c1b8d6733eb5217adfbc4d.svg b/docs/images/chapters/reordering/d52f60b331c1b8d6733eb5217adfbc4d.svg index a93456b0..8a22673c 100644 --- a/docs/images/chapters/reordering/d52f60b331c1b8d6733eb5217adfbc4d.svg +++ b/docs/images/chapters/reordering/d52f60b331c1b8d6733eb5217adfbc4d.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/dd8d8d98f66ce9f51b95cbf48225e97b.svg b/docs/images/chapters/reordering/dd8d8d98f66ce9f51b95cbf48225e97b.svg index 60f1b3ff..92f097ac 100644 --- a/docs/images/chapters/reordering/dd8d8d98f66ce9f51b95cbf48225e97b.svg +++ b/docs/images/chapters/reordering/dd8d8d98f66ce9f51b95cbf48225e97b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/reordering/faf29599c9307f930ec28065c96fde2a.svg b/docs/images/chapters/reordering/faf29599c9307f930ec28065c96fde2a.svg index 56f9b36c..ce63f825 100644 --- a/docs/images/chapters/reordering/faf29599c9307f930ec28065c96fde2a.svg +++ b/docs/images/chapters/reordering/faf29599c9307f930ec28065c96fde2a.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/splitting/891133c5f0e140b8c7e179af04e497e0.png b/docs/images/chapters/splitting/891133c5f0e140b8c7e179af04e497e0.png index e3f0c2ec..6e25e835 100644 Binary files a/docs/images/chapters/splitting/891133c5f0e140b8c7e179af04e497e0.png and b/docs/images/chapters/splitting/891133c5f0e140b8c7e179af04e497e0.png differ diff --git a/docs/images/chapters/weightcontrol/02457b19087540dfb144978419524a85.svg b/docs/images/chapters/weightcontrol/02457b19087540dfb144978419524a85.svg index f8263c9e..72a548de 100644 --- a/docs/images/chapters/weightcontrol/02457b19087540dfb144978419524a85.svg +++ b/docs/images/chapters/weightcontrol/02457b19087540dfb144978419524a85.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/weightcontrol/3fd61ab3fe88f694e70f61e4f8ea056b.svg b/docs/images/chapters/weightcontrol/3fd61ab3fe88f694e70f61e4f8ea056b.svg index 45b2f9d8..c5342dd8 100644 --- a/docs/images/chapters/weightcontrol/3fd61ab3fe88f694e70f61e4f8ea056b.svg +++ b/docs/images/chapters/weightcontrol/3fd61ab3fe88f694e70f61e4f8ea056b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/whatis/524dd296e96c0fe2281fb95146f8ea65.png b/docs/images/chapters/whatis/524dd296e96c0fe2281fb95146f8ea65.png index e6108a1e..76aaa493 100644 Binary files a/docs/images/chapters/whatis/524dd296e96c0fe2281fb95146f8ea65.png and b/docs/images/chapters/whatis/524dd296e96c0fe2281fb95146f8ea65.png differ diff --git a/docs/images/chapters/whatis/b5aa26284ba3df74970a95cb047a841d.svg b/docs/images/chapters/whatis/b5aa26284ba3df74970a95cb047a841d.svg index 62ad7c58..8462b235 100644 --- a/docs/images/chapters/whatis/b5aa26284ba3df74970a95cb047a841d.svg +++ b/docs/images/chapters/whatis/b5aa26284ba3df74970a95cb047a841d.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/whatis/cd46926a37f90ea474d53f07a63c9ee6.png b/docs/images/chapters/whatis/cd46926a37f90ea474d53f07a63c9ee6.png deleted file mode 100644 index e6108a1e..00000000 Binary files a/docs/images/chapters/whatis/cd46926a37f90ea474d53f07a63c9ee6.png and /dev/null differ diff --git a/docs/images/chapters/yforx/61e43d68f6eb677d0fccd473c121e782.svg b/docs/images/chapters/yforx/61e43d68f6eb677d0fccd473c121e782.svg index ea3499f2..cc7024c3 100644 --- a/docs/images/chapters/yforx/61e43d68f6eb677d0fccd473c121e782.svg +++ b/docs/images/chapters/yforx/61e43d68f6eb677d0fccd473c121e782.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/yforx/9ab2b830fe7fb73350c19bde04e9441b.svg b/docs/images/chapters/yforx/9ab2b830fe7fb73350c19bde04e9441b.svg index 64bde4aa..2cd6c166 100644 --- a/docs/images/chapters/yforx/9ab2b830fe7fb73350c19bde04e9441b.svg +++ b/docs/images/chapters/yforx/9ab2b830fe7fb73350c19bde04e9441b.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/images/chapters/yforx/9df91c28af38c1ba2e2d38d2714c9446.svg b/docs/images/chapters/yforx/9df91c28af38c1ba2e2d38d2714c9446.svg index e6a4f7c2..35f51bc9 100644 --- a/docs/images/chapters/yforx/9df91c28af38c1ba2e2d38d2714c9446.svg +++ b/docs/images/chapters/yforx/9df91c28af38c1ba2e2d38d2714c9446.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index 550569ae..f51a2b77 100644 --- a/docs/index.html +++ b/docs/index.html @@ -285,7 +285,7 @@

Playing with the points for curves may have given you a feel for how Bézier curves behave, but what are Bézier curves, really? There are two ways to explain what a Bézier curve is, and they turn out to be the entirely equivalent, but one of them uses complicated maths, and the other uses really simple maths. So... let's start with the simple explanation:

Bézier curves are the result of linear interpolations. That sounds complicated but you've been doing linear interpolation since you were very young: any time you had to point at something between two other things, you've been applying linear interpolation. It's simply "picking a point between two points".

If we know the distance between those two points, and we want a new point that is, say, 20% the distance away from the first point (and thus 80% the distance away from the second point) then we can compute that really easily:

- +

So let's look at that in action: the following graphic is interactive in that you can use your up and down arrow keys to increase or decrease the interpolation ratio, to see what happens. We start with three points, which gives us two lines. Linear interpolation over those lines gives us two points, between which we can again perform linear interpolation, yielding a single point. And that point —and all points we can form in this way for all ratios taken together— form our Bézier curve:

@@ -305,14 +305,14 @@

The mathematics of Bézier curves

Bézier curves are a form of "parametric" function. Mathematically speaking, parametric functions are cheats: a "function" is actually a well defined term representing a mapping from any number of inputs to a single output. Numbers go in, a single number comes out. Change the numbers that go in, and the number that comes out is still a single number.

Parametric functions cheat. They basically say "alright, well, we want multiple values coming out, so we'll just use more than one function". An illustration: Let's say we have a function that maps some value, let's call it x, to some other value, using some kind of number manipulation:

- +

The notation f(x) is the standard way to show that it's a function (by convention called f if we're only listing one) and its output changes based on one variable (in this case, x). Change x, and the output for f(x) changes.

So far, so good. Now, let's look at parametric functions, and how they cheat. Let's take the following two functions:

- +

There's nothing really remarkable about them, they're just a sine and cosine function, but you'll notice the inputs have different names. If we change the value for a, we're not going to change the output value for f(b), since a isn't used in that function. Parametric functions cheat by changing that. In a parametric function all the different functions share a variable, like this:

- +

Multiple functions, but only one variable. If we change the value for t, we change the outcome of both fa(t) and fb(t). You might wonder how that's useful, and the answer is actually pretty simple: if we change the labels fa(t) and fb(t) with what we usually mean with them for parametric curves, things might be a lot more obvious:

- +

There we go. x/y coordinates, linked through some mystery value t.

So, parametric curves don't define a y coordinate in terms of an x coordinate, like normal functions do, but they instead link the values to a "control" variable. If we vary the value of t, then with every change we get two values, which we can use as (x,y) coordinates in a graph. The above set of functions, for instance, generates points on a circle: We can range t from negative to positive infinity, and the resulting (x,y) coordinates will always lie on a circle with radius 1 around the origin (0,0). If we plot it for t from 0 to 5, we get this:

@@ -326,17 +326,17 @@

Bézier curves are just one out of the many classes of parametric functions, and are characterised by using the same base function for all of the output values. In the example we saw above, the x and y values were generated by different functions (one uses a sine, the other a cosine); but Bézier curves use the "binomial polynomial" for both the x and y outputs. So what are binomial polynomials?

You may remember polynomials from high school. They're those sums that look like this:

- +

If the highest order term they have is , they're called "cubic" polynomials; if it's , it's a "square" polynomial; if it's just x, it's a line (and if there aren't even any terms with x it's not a polynomial!)

Bézier curves are polynomials of t, rather than x, with the value for t being fixed between 0 and 1, with coefficients a, b etc. taking the "binomial" form, which sounds fancy but is actually a pretty simple description for mixing values:

- +

I know what you're thinking: that doesn't look too simple! But if we remove t and add in "times one", things suddenly look pretty easy. Check out these binomial terms:

- +

Notice that 2 is the same as 1+1, and 3 is 2+1 and 1+2, and 6 is 3+3... As you can see, each time we go up a dimension, we simply start and end with 1, and everything in between is just "the two numbers above it, added together", giving us a simple number sequence known as Pascal's triangle. Now that's easy to remember.

There's an equally simple way to figure out how the polynomial terms work: if we rename (1-t) to a and t to b, and remove the weights for a moment, we get this:

- +

It's basically just a sum of "every combination of a and b", progressively replacing a's with b's after every + sign. So that's actually pretty simple too. So now you know binomial polynomials, and just for completeness I'm going to show you the generic function for this:

- +

And that's the full description for Bézier curves. Σ in this function indicates that this is a series of additions (using the variable listed below the Σ, starting at ...=<value> and ending at the value listed on top of the Σ).

@@ -471,9 +471,9 @@ function Bezier(3,t,w[]):

Controlling Bézier curvatures, part 2: Rational Béziers

We can further control Bézier curves by "rationalising" them: that is, adding a "ratio" value in addition to the weight value discussed in the previous section, thereby gaining control over "how strongly" each coordinate influences the curve.

Adding these ratio values to the regular Bézier curve function is fairly easy. Where the regular function is the following:

- +

The function for rational Bézier curves has two more terms:

- +

In this, the first new term represents an additional weight for each coordinate. For example, if our ratio values are [1, 0.5, 0.5, 1] then ratio0 = 1, ratio1 = 0.5, and so on, and is effectively identical as if we were just using different weight. So far, nothing too special.

However, the second new term is what makes the difference: every point on the curve isn't just a "double weighted" point, it is a fraction of the "doubly weighted" value we compute by introducing that ratio. When computing points on the curve, we compute the "normal" Bézier value and then divide that by the Bézier value for the curve that only uses ratios, not weights.

This does something unexpected: it turns our polynomial into something that isn't a polynomial anymore. It is now a kind of curve that is a super class of the polynomials, and can do some really cool things that Bézier curves can't do "on their own", such as perfectly describing circles (which we'll see in a later section is literally impossible using standard Bézier curves).

@@ -529,9 +529,9 @@ function RationalBezier(3,t,w[],r[]):

The Bézier interval [0,1]

Now that we know the mathematics behind Bézier curves, there's one curious thing that you may have noticed: they always run from t=0 to t=1. Why that particular interval?

It all has to do with how we run from "the start" of our curve to "the end" of our curve. If we have a value that is a mixture of two other values, then the general formula for this is:

- +

The obvious start and end values here need to be a=1, b=0, so that the mixed value is 100% value 1, and 0% value 2, and a=0, b=1, so that the mixed value is 0% value 1 and 100% value 2. Additionally, we don't want "a" and "b" to be independent: if they are, then we could just pick whatever values we like, and end up with a mixed value that is, for example, 100% value 1 and 100% value 2. In principle that's fine, but for Bézier curves we always want mixed values between the start and end point, so we need to make sure we can never set "a" and "b" to some values that lead to a mix value that sums to more than 100%. And that's easy:

- +

With this we can guarantee that we never sum above 100%. By restricting a to values in the interval [0,1], we will always be somewhere between our two values (inclusively), and we will always sum to a 100% mix.

But... what if we use this form, which is based on the assumption that we will only ever use values between 0 and 1, and instead use values outside of that interval? Do things go horribly wrong? Well... not really, but we get to "see more".

In the case of Bézier curves, extending the interval simply makes our curve "keep going". Bézier curves are simply segments of some polynomial curve, so if we pick a wider interval we simply get to see more of the curve. So what do they look like?

@@ -775,30 +775,30 @@ function drawCurve(points[], t):

One interesting property of Bézier curves is that an nth order curve can always be perfectly represented by an (n+1)th order curve, by giving the higher-order curve specific control points.

If we have a curve with three points, then we can create a curve with four points that exactly reproduces the original curve. First, we give it the same start and end points, and for its two control points we pick "1/3rd start + 2/3rd control" and "2/3rd control + 1/3rd end". Now we have exactly the same curve as before, except represented as a cubic curve rather than a quadratic curve.

The general rule for raising an nth order curve to an (n+1)th order curve is as follows (observing that the start and end weights are the same as the start and end weights for the old curve):

- +

However, this rule also has as direct consequence that you cannot generally safely lower a curve from nth order to (n-1)th order, because the control points cannot be "pulled apart" cleanly. We can try to, but the resulting curve will not be identical to the original, and may in fact look completely different.

However, there is a surprisingly good way to ensure that a lower order curve looks "as close as reasonably possible" to the original curve: we can optimise the "least-squares distance" between the original curve and the lower order curve, in a single operation (also explained over on Sirver's Castle). However, to use it, we'll need to do some calculus work and then switch over to linear algebra. As mentioned in the section on matrix representations, some things can be done much more easily with matrices than with calculus functions, and this is one of those things. So... let's go!

We start by taking the standard Bézier function, and condensing it a little:

- +

Then, we apply one of those silly (actually, super useful) calculus tricks: since our t value is always between zero and one (inclusive), we know that (1-t) plus t always sums to 1. As such, we can express any value as a sum of t and 1-t:

- +

So, with that seemingly trivial observation, we rewrite that Bézier function by splitting it up into a sum of a (1-t) and t component:

- +

So far so good. Now, to see why we did this, let's write out the (1-t) and t parts, and see what that gives us. I promise, it's about to make sense. We start with (1-t):

- +

So by using this seemingly silly trick, we can suddenly express part of our nth order Bézier function in terms of an (n+1)th order Bézier function. And that sounds a lot like raising the curve order! Of course we need to be able to repeat that trick for the t part, but that's not a problem:

- +

So, with both of those changed from an order n expression to an order (n+1) expression, we can put them back together again. Now, where the order n function had a summation from 0 to n, the order n+1 function uses a summation from 0 to n+1, but this shouldn't be a problem as long as we can add some new terms that "contribute nothing". In the next section on derivatives, there is a discussion about why "higher terms than there is a binomial for" and "lower than zero terms" both "contribute nothing". So as long as we can add terms that have the same form as the terms we need, we can just include them in the summation, they'll sit there and do nothing, and the resulting function stays identical to the lower order curve.

Let's do this:

- +

And this is where we switch over from calculus to linear algebra, and matrices: we can now express this relation between Bézier(n,t) and Bézier(n+1,t) as a very simple matrix multiplication:

- +

where the matrix M is an n+1 by n matrix, and looks like:

- +

That might look unwieldy, but it's really just a mostly-zeroes matrix, with a very simply fraction on the diagonal, and an even simpler fraction to the left of it. Multiplying a list of coordinates with this matrix means we can plug the resulting transformed coordinates into the one-order-higher function and get an identical looking curve.

Not too bad!

Equally interesting, though, is that with this matrix operation established, we can now use an incredibly powerful and ridiculously simple way to find out a "best fit" way to reverse the operation, called the normal equation. What it does is minimize the sum of the square differences between one set of values and another set of values. Specifically, if we can express that as some function A x = b, we can use it. And as it so happens, that's exactly what we're dealing with, so:

- +

The steps taken here are:

  1. We have a function in a form that the normal equation can be used with, so
  2. @@ -863,20 +863,20 @@ function drawCurve(points[], t):

    Tangents and normals

    If you want to move objects along a curve, or "away from" a curve, the two vectors you're most interested in are the tangent vector and normal vector for curve points. These are actually really easy to find. For moving and orienting along a curve, we use the tangent, which indicates the direction of travel at specific points, and is literally just the first derivative of our curve:

    - +

    This gives us the directional vector we want. We can normalize it to give us uniform directional vectors (having a length of 1.0) at each point, and then do whatever it is we want to do based on those directions:

    - - + +

    The tangent is very useful for moving along a line, but what if we want to move away from the curve instead, perpendicular to the curve at some point t? In that case we want the normal vector. This vector runs at a right angle to the direction of the curve, and is typically of length 1.0, so all we have to do is rotate the normalized directional vector and we're done:

    - +

    Rotating coordinates is actually very easy, if you know the rule for it. You might find it explained as "applying a rotation matrix, which is what we'll look at here, too. Essentially, the idea is to take the circles over which we can rotate, and simply "sliding the coordinates" over these circles by the desired angle. If we want a quarter circle turn, we take the coordinate, slide it along the cirle by a quarter turn, and done.

    To turn any point (x,y) into a rotated point (x',y') (over 0,0) by some angle φ, we apply this nice and easy computation:

    - +

    Which is the "long" version of the following matrix transformation:

    - +

    And that's all we need to rotate any coordinate. Note that for quarter, half, and three-quarter turns these functions become even easier, since sin and cos for these angles are, respectively: 0 and 1, -1 and 0, and 0 and -1.

    But why does this work? Why this matrix multiplication? Wikipedia (technically, Thomas Herter and Klaus Lott) tells us that a rotation matrix can be treated as a sequence of three (elementary) shear operations. When we combine this into a single matrix operation (because all matrix multiplications can be collapsed), we get the matrix that you see above. DataGenetics have an excellent article about this very thing: it's really quite cool, and I strongly recommend taking a quick break from this primer to read that article.

    @@ -1034,27 +1034,27 @@ treated as a sequence of three (elementary) shear operations. When we combine th

    Now that we understand (well, superficially anyway) the component functions, we can find the extremities of our Bézier curve by finding maxima and minima on the component functions, by solving the equation B'(t) = 0. We've already seen that the derivative of a Bézier curve is a simpler Bézier curve, but how do we solve the equality? Fairly easily, actually, until our derivatives are 4th order or higher... then things get really hard. But let's start simple:

    Quadratic curves: linear derivatives.

    The derivative of a quadratic Bézier curve is a linear Bézier curve, interpolating between just two terms, which means finding the solution for "where is this line 0" is effectively trivial by rewriting it to a function of t and solving. First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

    - +

    And then we turn this into our solution for t using basic arithmetics:

    - +

    Done.

    Although with the caveat that if b-a is zero, there is no solution and we probably shouldn't try to perform that division.

    Cubic curves: the quadratic formula.

    The derivative of a cubic Bézier curve is a quadratic Bézier curve, and finding the roots for a quadratic polynomial means we can apply the Quadratic formula. If you've seen it before, you'll remember it, and if you haven't, it looks like this:

    - +

    So, if we can rewrite the Bézier component function as a plain polynomial, we're done: we just plug in the values into the quadratic formula, check if that square root is negative or not (if it is, there are no roots) and then just compute the two values that come out (because of that plus/minus sign we get two). Any value between 0 and 1 is a root that matters for Bézier curves, anything below or above that is irrelevant (because Bézier curves are only defined over the interval [0,1]). So, how do we convert?

    First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

    - +

    And then, using these v values, we can find out what our a, b, and c should be:

    - +

    This gives us three coefficients {a, b, c} that are expressed in terms of v values, where the v values are expressions of our original coordinate values, so we can do some substitution to get:

    - +

    Easy-peasy. We can now almost trivially find the roots by plugging those values into the quadratic formula.

    And as a cubic curve, there is also a meaningful second derivative, which we can compute by simple taking the derivative of the derivative.

    Quartic curves: Cardano's algorithm.

    We haven't really looked at them before now, but the next step up would be a Quartic curve, a fourth degree Bézier curve. As expected, these have a derivative that is a cubic function, and now things get much harder. Cubic functions don't have a "simple" rule to find their roots, like the quadratic formula, and instead require quite a bit of rewriting to a form that we can even start to try to solve.

    Back in the 16th century, before Bézier curves were a thing, and even before calculus itself was a thing, Gerolamo Cardano figured out that even if the general cubic function is really hard to solve, it can be rewritten to a form for which finding the roots is "easier" (even if not "easy"):

    - +

    We can see that the easier formula only has two constants, rather than four, and only two expressions involving t, rather than three: this makes things considerably easier to solve because it lets us use regular calculus to find the values that satisfy the equasion.

    Now, there is one small hitch: as a cubic function, the solutions may be complex numbers rather than plain numbers... And Cardona realised this, centuries befor complex numbers were a well-understood and established part of number theory. His interpretation of them was "these numbers are impossible but that's okay because they disappear again in later steps", allowing him to not think about them too much, but we have it even easier: as we're trying to find the roots for display purposes, we don't even care about complex numbers: we're going to simplify Cardano's approach just that tiny bit further by throwing away any solution that's not a plain number.

    So, how do we rewrite the hard formula into the easier formula? This is explained in detail over at Ken J. Ward's page for solving the cubic equation, so instead of showing the maths, I'm simply going to show the programming code for solving the cubic equation, with the complex roots getting totally ignored, but if you're interested you should definitely head over to Ken's page and give the procedure a read-through.

    @@ -1152,7 +1152,7 @@ function getCubicRoots(pa, pb, pc, pd) {

    That's a fancy term for saying "rather than trying to find exact answers by manipulating symbols, find approximate answers by describing the underlying process as a combination of steps, each of which can be assigned a number via symbolic manipulation". For example, trying to mathematically compute how much water fits in a completely crazy three dimensional shape is very hard, even if it got you the perfect, precise answer. A much easier approach, which would be less perfect but still entirely useful, would be to just grab a buck and start filling the shape until it was full: just count the number of buckets of water you used. And if we want a more precise answer, we can use smaller buckets.

    So that's what we're going to do here, too: we're going to treat the problem as a sequence of steps, and the smaller we can make each step, the closer we'll get to that "perfect, precise" answer. And as it turns out, there is a really nice numerical root-finding algorithm, called the Newton-Raphson root finding method (yes, after that Newton), which we can make use of. The Newton-Raphson approach consists of taking our impossible-to-solve function f(x), picking some intial value x (literally any value will do), and calculating f(x). We can think of that value as the "height" of the function at x. If that height is zero, we're done, we have found a root. If it isn't, we calculate the tangent line at f(x) and calculate at which x value its height is zero (which we've already seen is very easy). That will give us a new x and we repeat the process until we find a root.

    Mathematically, this means that for some x, at step n=1, we perform the following calculation until fy(x) is zero, so that the next t is the same as the one we already have:

    - +

    (The Wikipedia article has a decent animation for this process, so I will not add a graphic for that here)

    Now, this works well only if we can pick good starting points, and our curve is continuously differentiable and doesn't have oscillations. Glossing over the exact meaning of those terms, the curves we're dealing with conform to those constraints, so as long as we pick good starting points, this will work. So the question is: which starting points do we pick?

    As it turns out, Newton-Raphson is so blindingly fast that we could get away with just not picking: we simply run the algorithm from t=0 to t=1 at small steps (say, 1/200th) and the result will be all the roots we want. Of course, this may pose problems for high order Bézier curves: 200 steps for a 200th order Bézier curve is going to go wrong, but that's okay: there is no reason (at least, none that I know of) to ever use Bézier curves of crazy high orders. You might use a fifth order curve to get the "nicest still remotely workable" approximation of a full circle with a single Bézier curve, but that's pretty much as high as you'll ever need to go.

    @@ -1206,13 +1206,13 @@ function getCubicRoots(pa, pb, pc, pd) {

    Aligning curves

    While there are an incredible number of curves we can define by varying the x- and y-coordinates for the control points, not all curves are actually distinct. For instance, if we define a curve, and then rotate it 90 degrees, it's still the same curve, and we'll find its extremities in the same spots, just at different draw coordinates. As such, one way to make sure we're working with a "unique" curve is to "axis-align" it.

    Aligning also simplifies a curve's functions. We can translate (move) the curve so that the first point lies on (0,0), which turns our n term polynomial functions into n-1 term functions. The order stays the same, but we have less terms. Then, we can rotate the curves so that the last point always lies on the x-axis, too, making its coordinate (...,0). This further simplifies the function for the y-component to an n-2 term function. For instance, if we have a cubic curve such as this:

    - +

    Then translating it so that the first coordinate lies on (0,0), moving all x coordinates by -120, and all y coordinates by -160, gives us:

    - +

    If we then rotate the curve so that its end point lies on the x-axis, the coordinates (integer-rounded for illustrative purposes here) become:

    - +

    If we drop all the zero-terms, this gives us:

    - +

    We can see that our original curve definition has been simplified considerably. The following graphics illustrate the result of aligning our example curves to the x-axis, with the cubic case using the coordinates that were just used in the example formulae:

    @@ -1257,29 +1257,29 @@ function getCubicRoots(pa, pb, pc, pd) {

    Now that we know how to align a curve, there's one more thing we can calculate: inflection points. Imagine we have a variable size circle that we can slide up against our curve. We place it against the curve and adjust its radius so that where it touches the curve, the curvatures of the curve and the circle are the same, and then we start to slide the circle along the curve - for quadratic curves, we can always do this without the circle behaving oddly: we might have to change the radius of the circle as we slide it along, but it'll always sit against the same side of the curve.

    But what happens with cubic curves? Imagine we have an S curve and we place our circle at the start of the curve, and start sliding it along. For a while we can simply adjust the radius and things will be fine, but once we get to the midpoint of that S, something odd happens: the circle "flips" from one side of the curve to the other side, in order for the curvatures to keep matching. This is called an inflection, and we can find out where those happen relatively easily.

    What we need to do is solve a simple equation:

    - +

    What we're saying here is that given the curvature function C(t), we want to know for which values of t this function is zero, meaning there is no "curvature", which will be exactly at the point between our circle being on one side of the curve, and our circle being on the other side of the curve. So what does C(t) look like? Actually something that seems not too hard:

    - +

    The function C(t) is the cross product between the first and second derivative functions for the parametric dimensions of our curve. And, as already shown, derivatives of Bézier curves are just simpler Bézier curves, with very easy to compute new coefficients, so this should be pretty easy.

    However as we've seen in the section on aligning, aligning lets us simplify things a lot, by completely removing the contributions of the first coordinate from most mathematical evaluations, and removing the last y coordinate as well by virtue of the last point lying on the x-axis. So, while we can evaluate C(t) = 0 for our curve, it'll be much easier to first axis-align the curve and then evaluating the curvature function.

    Let's derive the full formula anyway

    Of course, before we do our aligned check, let's see what happens if we compute the curvature function without axis-aligning. We start with the first and second derivatives, given our basis functions:

    - +

    And of course the same functions for y:

    - +

    Asking a computer to now compose the C(t) function for us (and to expand it to a readable form of simple terms) gives us this rather overly complicated set of arithmetic expressions:

    - +

    That is... unwieldy. So, we note that there are a lot of terms that involve multiplications involving x1, y1, and y4, which would all disappear if we axis-align our curve, which is why aligning is a great idea.

    Aligning our curve so that three of the eight coefficients become zero, and observing that scale does not affect finding t values, we end up with the following simple term function for C(t):

    - +

    That's a lot easier to work with: we see a fair number of terms that we can compute and then cache, giving us the following simplification:

    - +

    This is a plain quadratic curve, and we know how to solve C(t) = 0; we use the quadratic formula:

    - +

    We can easily compute this value if the discriminator isn't a negative number (because we only want real roots, not complex roots), and if x is not zero, because divisions by zero are rather useless.

    Taking that into account, we compute t, we disregard any t value that isn't in the Bézier interval [0,1], and we now know at which t value(s) our curve will inflect.

    @@ -1308,13 +1308,13 @@ function getCubicRoots(pa, pb, pc, pd) {
  3. ...anywhere inside the red zone, but not on its boundaries, the curve will either be self-intersecting (yielding a loop). We won't know where it self-intersects (in terms of t values), but we are guaranteed that it does.

  4. ...on the left (red) edge of the red zone, the curve will have a cusp. We again don't know where, but we know there is one. This edge is described by the function:

    - +
  5. ...on the almost circular, lower right (pink) edge, the curve's end point touches the curve, forming a loop. This edge is described by the function:

    - +
  6. ...on the top (blue) edge, the curve's start point touches the curve, forming a loop. This edge is described by the function:

    - +
  7. ...inside the lower (green) zone, past y=1, the curve will have a single inflection (switching concave/convex once).

  8. @@ -1335,24 +1335,24 @@ function getCubicRoots(pa, pb, pc, pd) {

    So now the question becomes: how do we manipulate our curve so that it fits this canonical form, with three fixed points, and one "free" point? Enter linear algebra. Don't worry, I'll be doing all the math for you, as well as show you what the effect is on our curves, but basically we're going to be using linear algebra, rather than calculus, because "it's way easier". Sometimes a calculus approach is very hard to work with, when the equivalent geometrical solution is super obvious.

    The approach is going to start with a curve that doesn't have all-colinear points (so we need to make sure the points don't all fall on a straight line), and then applying three graphics operations that you will probably have heard of: translation (moving all points by some fixed x- and y-distance), scaling (multiplying all points by some x and y scale factor), and shearing (an operation that turns rectangles into parallelograms).

    Step 1: we translate any curve by -p1.x and -p1.y, so that the curve starts at (0,0). We're going to make use of an interesting trick here, by pretending our 2D coordinates are 3D, with the z coordinate simply always being 1. This is an old trick in graphics to overcome the limitations of 2D transformations: without it, we can only turn (x,y) coordinates into new coordinates of the form (ax + by, cx + dy), which means we can't do translation, since that requires we end up with some kind of (x + a, y + b). If we add a bogus z coordinate that is always 1, then we can suddenly add arbitrary values. For example:

    - +

    Sweet! z stays 1, so we can effectively ignore it entirely, but we added some plain values to our x and y coordinates. So, if we want to subtract p1.x and p1.y, we use:

    - +

    Running all our coordinates through this transformation gives a new set of coordinates, let's call those U, where the first coordinate lies on (0,0), and the rest is still somewhat free. Our next job is to make sure point 2 ends up lying on the x=0 line, so what we want is a transformation matrix that, when we run it, subtracts x from whatever x we currently have. This is called shearing, and the typical x-shear matrix and its transformation looks like this:

    - +

    So we want some shearing value that, when multiplied by y, yields -x, so our x coordinate becomes zero. That value is simply -x/y, because *-x/y * y = -x*. Done:

    - +

    Now, running this on all our points generates a new set of coordinates, let's call those V, which now have point 1 on (0,0) and point 2 on (0, some-value), and we wanted it at (0,1), so we need to do some scaling to make sure it ends up at (0,1). Additionally, we want point 3 to end up on (1,1), so we can also scale x to make sure its x-coordinate will be 1 after we run the transform. That means we'll be x-scaling by 1/point3x, and y-scaling by point2y. This is really easy:

    - +

    Then, finally, this generates a new set of coordinates, let's call those W, of which point 1 lies on (0,0), point 2 lies on (0,1), and point three lies on (1, ...) so all that's left is to make sure point 3 ends up at (1,1) - but we can't scale! Point 2 is already in the right place, and y-scaling would move it out of (0,1) again, so our only option is to y-shear point three, just like how we x-sheared point 2 earlier. In this case, we do the same trick, but with y/x rather than x/y because we're not x-shearing but y-shearing. Additionally, we don't actually want to end up at zero (which is what we did before) so we need to shear towards an offset, in this case 1:

    - +

    And this generates our final set of four coordinates. Of these, we already know that points 1 through 3 are (0,0), (0,1) and (1,1), and only the last coordinate is "free". In fact, given any four starting coordinates, the resulting "transformation mapped" coordinate will be:

    - +

    Okay, well, that looks plain ridiculous, but: notice that every coordinate value is being offset by the initial translation, and also notice that a lot of terms in that expression are repeated. Even though the maths looks crazy as a single expression, we can just pull this apart a little and end up with an easy-to-calculate bit of code!

    First, let's just do that translation step as a "preprocessing" operation so we don't have to subtract the values all the time. What does that leave?

    - +

    Suddenly things look a lot simpler: the mapped x is fairly straight forward to compute, and we see that the mapped y actually contains the mapped x in its entirety, so we'll have that part already available when we need to evaluate it. In fact, let's pull out all those common factors to see just how simple this is:

    - +

    That's kind of super-simple to write out in code, I think you'll agree. Coding math tends to be easier than the formulae initially make it look!

    @@ -1385,11 +1385,11 @@ function getCubicRoots(pa, pb, pc, pd) {

    Now, if you look more closely at that right graphic, you'll notice something interesting: if we treat the red line as "the x axis", then the point where the function crosses our line is really just a root for the cubic function x(t) through a shifted "x-axis"... and we've already seen how to calculate roots, so let's just run cubuc root finding - and not even the complicated cubic case either: because of the kind of curve we're starting with, we know there is only root, simplifying the code we need!

    First, let's look at the function for x(t):

    - +

    We can rewrite this to a plain polynomial form, by just fully writing out the expansion and then collecting the polynomial factors, as:

    - +

    Nothing special here: that's a standard cubic polynomial in "power" form (i.e. all the terms are ordered by their power of t). So, given that a, b, c, d, and x(t) are all known constants, we can trivially rewrite this (by moving the x(t) across the equal sign) as:

    - +

    You might be wondering "where did all the other 'minus x' for all the other values a, b, c, and d go?" and the answer there is that they all cancel out, so the only one we actually need to subtract is the one at the end. Handy! So now we just solve this equation using Cardano's algorithm, and we're left with some rather short code:

    // prepare our values for root finding:
     x = a value we already know
    @@ -1416,13 +1416,13 @@ y = curve.get(t).y

    Arc length

    How long is a Bézier curve? As it turns out, that's not actually an easy question, because the answer requires maths that —much like root finding— cannot generally be solved the traditional way. If we have a parametric curve with fx(t) and fy(t), then the length of the curve, measured from start point to some point t = z, is computed using the following seemingly straight forward (if a bit overwhelming) formula:

    - +

    or, more commonly written using Leibnitz notation as:

    - +

    This formula says that the length of a parametric curve is in fact equal to the area underneath a function that looks a remarkable amount like Pythagoras' rule for computing the diagonal of a straight angled triangle. This sounds pretty simple, right? Sadly, it's far from simple... cutting straight to after the chase is over: for quadratic curves, this formula generates an unwieldy computation, and we're simply not going to implement things that way. For cubic Bézier curves, things get even more fun, because there is no "closed form" solution, meaning that due to the way calculus works, there is no generic formula that allows you to calculate the arc length. Let me just repeat this, because it's fairly crucial: for cubic and higher Bézier curves, there is no way to solve this function if you want to use it "for all possible coordinates".

    Seriously: It cannot be done.

    So we turn to numerical approaches again. The method we'll look at here is the Gauss quadrature. This approximation is a really neat trick, because for any nth degree polynomial it finds approximated values for an integral really efficiently. Explaining this procedure in length is way beyond the scope of this page, so if you're interested in finding out why it works, I can recommend the University of South Florida video lecture on the procedure, linked in this very paragraph. The general solution we're looking for is the following:

    - +

    In plain text: an integral function can always be treated as the sum of an (infinite) number of (infinitely thin) rectangular strips sitting "under" the function's plotted graph. To illustrate this idea, the following graph shows the integral for a sinusoid function. The more strips we use (and of course the more we use, the thinner they get) the closer we get to the true area under the curve, and thus the better the approximation:

    @@ -1451,12 +1451,12 @@ y = curve.get(t).y

    Note that one requirement for the approach we'll use is that the integral must run from -1 to 1. That's no good, because we're dealing with Bézier curves, and the length of a section of curve applies to values which run from 0 to "some value smaller than or equal to 1" (let's call that value z). Thankfully, we can quite easily transform any integral interval to any other integral interval, by shifting and scaling the inputs. Doing so, we get the following:

    - +

    That may look a bit more complicated, but the fraction involving z is a fixed number, so the summation, and the evaluation of the f(t) values are still pretty simple.

    So, what do we need to perform this calculation? For one, we'll need an explicit formula for f(t), because that derivative notation is handy on paper, but not when we have to implement it. We'll also need to know what these Ci and ti values should be. Luckily, that's less work because there are actually many tables available that give these values, for any n, so if we want to approximate our integral with only two terms (which is a bit low, really) then these tables would tell us that for n=2 we must use the following values:

    - +

    Which means that in order for us to approximate the integral, we must plug these values into the approximate function, which gives us:

    - +

    We can program that pretty easily, provided we have that f(t) available, which we do, as we know the full description for the Bézier curve functions Bx(t) and By(t).

    @@ -1518,9 +1518,9 @@ y = curve.get(t).y

    That's crazy!

    But that's also one of the things that makes maths so powerful: even if your initial ideas are off the mark, you might be much closer than you thought you were, and the journey from "thinking we're completely wrong" to "actually being remarkably close to being right" is where we can find a lot of insight.

    So, what does the function look like? This:

    - +

    Which is really just a "short form" that glosses over the fact that we're dealing with functions of t, so let's expand that a tiny bit:

    - +

    And while that's a litte more verbose, it's still just as simple to work with as the first function: the curvature at some point on any (and this cannot be overstated: any) curve is a ratio between the first and second derivative cross product, and something that looks oddly similar to the standard Euclidean distance function. And nothing in these functions is hard to calculate either: for Bézier curves, simply knowing our curve coordinates means we know what the first and second derivatives are, and so evaluating this function for any t value is just a matter of basic arithematics.

    In fact, let's just implement it right now:

    function kappa(t, B):
    @@ -1704,24 +1704,24 @@ lli = function(line1, line2):
     

These three values A, B, and C allow us to derive an important identity formula for quadratic and cubic Bézier curves: for any point on the curve with some t value, the ratio of distances from A to B and B to C is fixed: if some t value sets up a C that is 20% away from the start and 80% away from the end, then it doesn't matter where the start, end, or control points are; for that t value, C will always lie at 20% from the start and 80% from the end point. Go ahead, pick an on-curve point in either graphic and then move all the other points around: if you only move the control points, start and end won't move, and so neither will C, and if you move either start or end point, C will move but its relative position will not change.

So, how can we compute C? We start with our observation that C always lies somewhere between the start and ends points, so logically C will have a function that interpolates between those two coordinates:

- +

If we can figure out what the function u(t) looks like, we'll be done. Although we do need to remember that this u(t) will have a different for depending on whether we're working with quadratic or cubic curves. Running through the maths (with thanks to Boris Zbarsky) shows us the following two formulae:

- +

And

- +

So, if we know the start and end coordinates, and we know the t value, we know C, without having to calculate the A or even B coordinates. In fact, we can do the same for the ratio function: as another function of t, we technically don't need to know what A or B or C are, we can express it was a pure function of t, too.

We start by observing that, given A, B, and C, the following always holds:

- +

Working out the maths for this, we see the following two formulae for quadratic and cubic curves:

- +

And

- +

Which now leaves us with some powerful tools: given thee points (start, end, and "some point on the curve"), as well as a t value, we can contruct curves: we can compute C using the start and end points, and our u(t) function, and once we have C, we can use our on-curve point (B) and the ratio(t) function to find A:

- +

With A found, finding e1 and e2 for quadratic curves is a matter of running the linear interpolation with t between start and A to yield e1, and between A and end to yield e2. For cubic curves, there is no single pair of points that can act as e1 and e2: as long as the distance ratio between e1 to B and B to e2 is the Bézier ratio (1-t):t, we can reverse engineer v1 and v2:

- +

And then reverse engineer the curve's control control points:

- +

So: if we have a curve's start and end point, then for any t value we implicitly know all the ABC values, which (combined with an educated guess on appropriate e1 and e2 coordinates for cubic curves) gives us the necessary information to reconstruct a curve's "de Casteljau skeleton". Which means that we can now do several things: we can "fit" curves using only three points, which means we can also "mold" curves by moving an on-curve point but leaving its start and end point, and then reconstructing the curve based on where we moved the on-curve point to. These are very useful things, and we'll look at both in the next few sections.

@@ -1729,7 +1729,7 @@ lli = function(line1, line2):

Creating a curve from three points

Given the preceding section, you might be wondering if we can use that knowledge to just "create" curves by placing some points and having the computer do the rest, to which the answer is: that's exactly what we can now do!

For quadratic curves, things are pretty easy. Technically, we'll need a t value in order to compute the ratio function used in computing the ABC coordinates, but we can just as easily approximate one by treating the distance between the start and B point, and B and end point as a ratio, using

- +

With this code in place, creating a quadratic curve from three points is literally just computing the ABC values, and using A as our curve's control point:

@@ -1748,11 +1748,11 @@ lli = function(line1, line2):

With that covered, we now also know the tangent line to our point B, because the tangent to any point on the circle is a line through that point, perpendicular to the line from that point to the center. That just leaves marking appropriate points e1 and e2 on that tangent, so that we can construct a new cubic curve hull. We use the approach as we did for quadratic curves to automatically determine a reasonable t value, and then our e1 and e2 coordinates must obey the standard de Casteljau rule for linear interpolation:

- +

Where d is the total length of the line segment from e1 to e2. So how long do we make that? There are again all kinds of approaches we can take, and a simple-but-effective one is to set the length of that segment to "one third the length of the baseline". This forces e1 and e2 to always be the "linear curve" distance apart, which means if we place our three points on a line, it will actually look like a line. Nice! The last thing we'll need to do is make sure to flip the sign of d depending on which side of the baseline our B is located, so we don't up creating a funky curve with a loop in it. To do this, we can use the atan2 function:

- +

This angle φ will be between 0 and π if B is "above" the baseline (rotating all three points so that the start is on the left and the end is the right), so we can use a relatively straight forward check to make sure we're using the correct sign for our value d:

- +

The result of this approach looks as follows:

@@ -1804,9 +1804,9 @@ for (coordinate, index) in LUT:

Molding a curve

Armed with knowledge of the "ABC" relation, point-on-curve projection, and guestimating reasonable looking helper values for cubic curve construction, we can finally cover curve molding: updating a curve's shape interactively, by dragging points on the curve around.

For quadratic curve, this is a really simple trick: we project our cursor onto the curve, which gives us a t value and initial B coordinate. We don't even need the latter: with our t value and "whever the cursor is" as target B, we can compute the associated C:

- +

And then the associated A:

- +

And we're done, because that's our new quadratic control point!

@@ -1851,25 +1851,25 @@ for (coordinate, index) in LUT:

Revisiting the matrix representation

Rewriting Bézier functions to matrix form is fairly easy, if you first expand the function, and then arrange them into a multiple line form, where each line corresponds to a power of t, and each column is for a specific coefficient. First, we expand the function:

- +

And then we (trivially) rearrange the terms across multiple lines:

- +

This rearrangement has "factors of t" at each row (the first row is t⁰, i.e. "1", the second row is t¹, i.e. "t", the third row is t²) and "coefficient" at each column (the first column is all terms involving "a", the second all terms involving "b", the third all terms involving "c").

With that arrangement, we can easily decompose this as a matrix multiplication:

- +

We can do the same for the cubic curve, of course. We know the base function for cubics:

- +

So we write out the expansion and rearrange:

- +

Which we can then decompose:

- +

And, of course, we can do this for quartic curves too (skipping the expansion step):

- +

And so and on so on. Now, let's see how to use these T, M, and C, to do some curve fitting.

Let's get started: we're going to assume we picked the right order curve: for n points we're fitting an n-1th order curve, so we "start" with a vector P that represents the coordinates we already know, and for which we want to do curve fitting:

- +

Next, we need to figure out appropriate t values for each point in the curve, because we need something that lets us tie "the actual coordinate" to "some point on the curve". There's a fair number of different ways to do this (and a large part of optimizing "the perfect fit" is about picking appropriate t values), but in this case let's look at two "obvious" choices:

  1. equally spaced t values, and
  2. @@ -1878,27 +1878,27 @@ for (coordinate, index) in LUT:

    The first one is really simple: if we have n points, then we'll just assign each point i a t value of (i-1)/(n-1). So if we have four points, the first point will have t=(1-1)/(4-1)=0/3, the second point will have t=(2-1)/(4-1)=1/3, the third point will have t=2/3, and the last point will be t=1. We're just straight up spacing the t values to match the number of points we have.

    The second one is a little more interesting: since we're doing polynomial regression, we might as well exploit the fact that our base coordinates just constitute a collection of line segments. At the first point, we're fixing t=0, and the last point, we want t=1, and anywhere in between we're simply going to say that t is equal to the distance along the polygon, scaled to the [0,1] domain.

    To get these values, we first compute the general "distance along the polygon" matrix:

    - +

    Where length() is literally just that: the length of the line segment between the point we're looking at, and the previous point. This isn't quite enough, of course: we still need to make sure that all the values between i=1 and i=n fall in the [0,1] interval, so we need to scale all values down by whatever the total length of the polygon is:

    - +

    And now we can move on to the actual "curve fitting" part: what we want is a function that lets us compute "ideal" control point values such that if we build a Bézier curve with them, that curve passes through all our original points. Or, failing that, have an overall error distance that is as close to zero as we can get it. So, let's write out what the error distance looks like.

    As mentioned before, this function is really just "the distance between the actual coordinate, and the coordinate that the curve evaluates to for the associated t value", which we'll square to get rid of any pesky negative signs:

    - +

    Since this function only deals with individual coordinates, we'll need to sum over all coordinates in order to get the full error function. So, we literally just do that; the total error function is simply the sum of all these individual errors:

    - +

    And here's the trick that justifies using matrices: while we can work with individual values using calculus, with matrices we can compute as many values as we make our matrices big, all at the "same time", We can replace the individual terms pi with the full P coordinate matrix, and we can replace Bézier(si) with the matrix representation T x M x C we talked about before, which gives us:

    - +

    In which we can replace the rather cumbersome "squaring" operation with a more conventional matrix equivalent:

    - +

    Here, the letter T is used instead of the number 2, to represent the matrix transpose; each row in the original matrix becomes a column in the transposed matrix instead (row one becomes column one, row two becomes column two, and so on).

    This leaves one problem: T isn't actually the matrix we want: we don't want symbolic t values, we want the actual numerical values that we computed for S, so we need to form a new matrix, which we'll call 𝕋, that makes use of those, and then use that 𝕋 instead of T in our error function:

    - +

    Which, because of the first and last values in S, means:

    - +

    Now we can properly write out the error function as matrix operations:

    - +

    So, we have our error function: we now need to figure out the expression for where that function has minimal value, e.g. where the error between the true coordinates and the coordinates generated by the curve fitting is smallest. Like in standard calculus, this requires taking the derivative, and determining where that derivative is zero:

    - +

    Where did this derivative come from?

    @@ -1908,7 +1908,7 @@ for (coordinate, index) in LUT:

    Now, given the above derivative, we can rearrange the terms (following the rules of matrix algebra) so that we end up with an expression for C:

    - +

    Here, the "to the power negative one" is the notation for the matrix inverse. But that's all we have to do: we're done. Starting with P and inventing some t values based on the polygon the coordinates in P define, we can compute the corresponding Bézier coordinates C that specify a curve that goes through our points. Or, if it can't go through them exactly, as near as possible.

    So before we try that out, how much code is involved in implementing this? Honestly, that answer depends on how much you're going to be writing yourself. If you already have a matrix maths library available, then really not that much code at all. On the other hand, if you are writing this from scratch, you're going to have to write some utility functions for doing your matrix work for you, so it's really anywhere from 50 lines of code to maybe 200 lines of code. Not a bad price to pay for being able to fit curves to prespecified coordinates.

    So let's try it out! The following graphic lets you place points, and will start computing exact-fit curves once you've placed at least three. You can click for more points, and the code will simply try to compute an exact fit using a Bézier curve of the appropriate order. Four points? Cubic Bézier. Five points? Quartic. And so on. Of course, this does break down at some point: depending on where you place your points, it might become mighty hard for the fitter to find an exact fit, and things might actually start looking horribly off once there's enough points for compound floating point rounding errors to start making a difference (which is around 10~11 points).

    @@ -1939,7 +1939,7 @@ for (coordinate, index) in LUT:

    Now, it may look like Catmull-Rom curves are very different from Bézier curves, because these curves can get very long indeed, but what looks like a single Catmull-Rom curve is actually a spline: a single curve built up of lots of identically-computed pieces, similar to if you just took a whole bunch of Bézier curves, placed them end to end, and lined up their control points so that things look like a single curve. For a Catmull-Rom curve, each "piece" between two points is defined by the point's coordinates, and the tangent for those points, the latter of which can trivially be derived from knowing the previous and next point:

    - +

    One downside of this is that—as you may have noticed from the graphic—the first and last point of the overall curve don't actually join up with the rest of the curve: they don't have a previous/next point respectively, and so there is no way to calculate what their tangent should be. Which also makes it rather tricky to fit a Camull-Rom curve to three points like we were able to do for Bézier curves. More on that in the next section.

    In fact, before we move on, let's look at how to actually draw the basic form of these curves (I say basic, because there are a number of variations that make things considerable more complex):

    tension = some value greater than 0, defaulting to 1
    @@ -1968,77 +1968,77 @@ for p = 1 to points.length-3 (inclusive):
     
  3. A Catmull-Rom curve is defined by a start point, a tangent that for that starting point, an end point, and a tangent for that end point, plus a characteristic matrix that we can multiple by the point vector to get on-curve coordinates.
  4. Those are very similar, so let's see exactly how similar they are. We've already see the matrix form for Bézier curves, so how different is the matrix form for Catmull-Rom curves?:

    - +

    That's pretty dang similar. So the question is: how can we convert that expression with Catmull-Rom matrix and vector into an expression of the Bézier matrix and vector? The short answer is of course "by using linear algebra", but the longer answer is the rest of this section, and involves some maths that you may not even care for: if you just want to know the (incredibly simple) conversions between the two curve forms, feel free to skip to the end of the following explanation, but if you want to how we can get one from the other... let's get mathing!

    Deriving the conversion formulae

    In order to convert between Catmull-Rom curves and Bézier curves, we need to know two things. Firstly, how to express the Catmull-Rom curve using a "set of four coordinates", rather than a mix of coordinates and tangents, and secondly, how to convert those Catmull-Rom coordinates to and from Bézier form.

    We start with the first part, to figure out how we can go from Catmull-Rom V coordinates to Bézier P coordinates, by applying "some matrix T". We don't know what that T is yet, but we'll get to that:

    - +

    So, this mapping says that in order to map a Catmull-Rom "point + tangent" vector to something based on an "all coordinates" vector, we need to determine the mapping matrix such that applying T yields P2 as start point, P3 as end point, and two tangents based on the lines between P1 and P3, and P2 nd P4, respectively.

    Computing T is really more "arranging the numbers":

    - +

    Thus:

    - +

    However, we're not quite done, because Catmull-Rom curves have that "tension" parameter, written as τ (a lowercase"tau"), which is a scaling factor for the tangent vectors: the bigger the tension, the smaller the tangents, and the smaller the tension, the bigger the tangents. As such, the tension factor goes in the denominator for the tangents, and before we continue, let's add that tension factor into both our coordinate vector representation, and mapping matrix T:

    - +

    With the mapping matrix properly done, let's rewrite the "point + tangent" Catmull-Rom matrix form to a matrix form in terms of four coordinates, and see what we end up with:

    - +

    Replace point/tangent vector with the expression for all-coordinates:

    - +

    and merge the matrices:

    - +

    This looks a lot like the Bézier matrix form, which as we saw in the chapter on Bézier curves, should look like this:

    - +

    So, if we want to express a Catmull-Rom curve using a Bézier curve, we'll need to turn this Catmull-Rom bit:

    - +

    Into something that looks like this:

    - +

    And the way we do that is with a fairly straight forward bit of matrix rewriting. We start with the equality we need to ensure:

    - +

    Then we remove the coordinate vector from both sides without affecting the equality:

    - +

    Then we can "get rid of" the Bézier matrix on the right by left-multiply both with the inverse of the Bézier matrix:

    - +

    A matrix times its inverse is the matrix equivalent of 1, and because "something times 1" is the same as "something", so we can just outright remove any matrix/inverse pair:

    - +

    And now we're basically done. We just multiply those two matrices and we know what V is:

    - +

    We now have the final piece of our function puzzle. Let's run through each step.

    1. Start with the Catmull-Rom function:
    - +
    1. rewrite to pure coordinate form:
    - +
    1. rewrite for "normal" coordinate vector:
    - +
    1. merge the inner matrices:
    - +
    1. rewrite for Bézier matrix form:
    - +
    1. and transform the coordinates so we have a "pure" Bézier expression:
    - +

    And we're done: we finally know how to convert these two curves!

    If we have a Catmull-Rom curve defined by four coordinates P1 through P4, then we can draw that curve using a Bézier curve that has the vector:

    - +

    Similarly, if we have a Bézier curve defined by four coordinates P1 through P4, we can draw that using a standard tension Catmull-Rom curve with the following coordinate values:

    - +

    Or, if your API allows you to specify Catmull-Rom curves using plain coordinates:

    - +
    @@ -2071,9 +2071,9 @@ for p = 1 to points.length-3 (inclusive):

    Dragging the control points around only affects the curve segments that the control point belongs to, and moving an on-curve point leaves the control points where they are, which is not the most useful for practical modelling purposes. So, let's add in the logic we need to make things a little better. We'll start by linking up control points by ensuring that the "incoming" derivative at an on-curve point is the same as it's "outgoing" derivative:

    - +

    We can effect this quite easily, because we know that the vector from a curve's last control point to its last on-curve point is equal to the derivative vector. If we want to ensure that the first control point of the next curve matches that, all we have to do is mirror that last control point through the last on-curve point. And mirroring any point A through any point B is really simple:

    - +

    So let's implement that and see what it gets us. The following two graphics show a quadratic and a cubic poly-Bézier curve again, but this time moving the control points around moves others, too. However, you might see something unexpected going on for quadratic curves...

    @@ -2133,16 +2133,16 @@ for p = 1 to points.length-3 (inclusive):

    "What do you mean, you can't? Prove it."

    First off, when I say "you can't," what I really mean is "you can't offset a Bézier curve with another Bézier curve", not even by using a really high order curve. You can find the function that describes the offset curve, but it won't be a polynomial, and as such it cannot be represented as a Bézier curve, which has to be a polynomial. Let's look at why this is:

    From a mathematical point of view, an offset curve O(t) is a curve such that, given our original curve B(t), any point on O(t) is a fixed distance d away from coordinate B(t). So let's math that:

    - +

    However, we're working in 2D, and d is a single value, so we want to turn it into a vector. If we want a point distance d "away" from the curve B(t) then what we really mean is that we want a point at d times the "normal vector" from point B(t), where the "normal" is a vector that runs perpendicular ("at a right angle") to the tangent at B(t). Easy enough:

    - +

    Now this still isn't very useful unless we know what the formula for N(t) is, so let's find out. N(t) runs perpendicular to the original curve tangent, and we know that the tangent is simply B'(t), so we could just rotate that 90 degrees and be done with it. However, we need to ensure that N(t) has the same magnitude for every t, or the offset curve won't be at a uniform distance, thus not being an offset curve at all. The easiest way to guarantee this is to make sure N(t) always has length 1, which we can achieve by dividing B'(t) by its magnitude:

    - +

    Determining the length requires computing an arc length, and this is where things get Tricky with a capital T. First off, to compute arc length from some start a to end b, we must use the formula we saw earlier. Noting that "length" is usually denoted with double vertical bars:

    - +

    So if we want the length of the tangent, we plug in B'(t), with t = 0 as start and t = 1 as end:

    - +

    And that's where things go wrong. It doesn't even really matter what the second derivative for B(t) is, that square root is screwing everything up, because it turns our nice polynomials into things that are no longer polynomials.

    There is a small class of polynomials where the square root is also a polynomial, but they're utterly useless to us: any polynomial with unweighted binomial coefficients has a square root that is also a polynomial. Now, you might think that Bézier curves are just fine because they do, but they don't; remember that only the base function has binomial coefficients. That's before we factor in our coordinates, which turn it into a non-binomial polygon. The only way to make sure the functions stay binomial is to make all our coordinates have the same value. And that's not a curve, that's a point. We can already create offset curves for points, we call them circles, and they have much simpler functions than Bézier curves.

    So, since the tangent length isn't a polynomial, the normalised tangent won't be a polynomial either, which means N(t) won't be a polynomial, which means that d times N(t) won't be a polynomial, which means that, ultimately, O(t) won't be a polynomial, which means that even if we can determine the function for O(t) just fine (and that's far from trivial!), it simply cannot be represented as a Bézier curve.

    @@ -2222,25 +2222,25 @@ for p = 1 to points.length-3 (inclusive):

    As you can see, things go horribly wrong quite quickly; even trying to approximate a quarter circle using a quadratic curve is a bad idea. An eighth of a turns might look okay, but how okay is okay? Let's apply some maths and find out. What we're interested in is how far off our on-curve coordinates are with respect to a circular arc, given a specific start and end angle. We'll be looking at how much space there is between the circular arc, and the quadratic curve's midpoint.

    We start out with our start and end point, and for convenience we will place them on a unit circle (a circle around 0,0 with radius 1), at some angle φ:

    - +

    What we want to find is the intersection of the tangents, so we want a point C such that:

    - +

    i.e. we want a point that lies on the vertical line through S (at some distance a from S) and also lies on the tangent line through E (at some distance b from E). Solving this gives us:

    - +

    First we solve for b:

    - +

    which yields:

    - +

    which we can then substitute in the expression for a:

    - +

    A quick check shows that plugging these values for a and b into the expressions for Cx and Cy give the same x/y coordinates for both "a away from A" and "b away from B", so let's continue: now that we know the coordinate values for C, we know where our on-curve point T for t=0.5 (or angle φ/2) is, because we can just evaluate the Bézier polynomial, and we know where the circle arc's actual point P is for angle φ/2:

    - +

    We compute T, observing that if t=0.5, the polynomial values (1-t)², 2(1-t)t, and t² are 0.25, 0.5, and 0.25 respectively:

    - +

    Which, worked out for the x and y components, gives:

    - +

    And the distance between these two is the standard Euclidean distance:

    - +

    So, what does this distance function look like when we plot it for a number of ranges for the angle φ, such as a half circle, quarter circle and eighth circle?

    @@ -2257,7 +2257,7 @@ for p = 1 to points.length-3 (inclusive):

    We now see why the eighth circle arc looks decent, but the quarter circle arc doesn't: an error of roughly 0.06 at t=0.5 means we're 6% off the mark... we will already be off by one pixel on a circle with pixel radius 17. Any decent sized quarter circle arc, say with radius 100px, will be way off if approximated by a quadratic curve! For the eighth circle arc, however, the error is only roughly 0.003, or 0.3%, which explains why it looks so close to the actual eighth circle arc. In fact, if we want a truly tiny error, like 0.001, we'll have to contend with an angle of (rounded) 0.593667, which equates to roughly 34 degrees. We'd need 11 quadratic curves to form a full circle with that precision! (technically, 10 and ten seventeenth, but we can't do partial curves, so we have to round up). That's a whole lot of curves just to get a shape that can be drawn using a simple function!

    In fact, let's flip the function around, so that if we plug in the precision error, labelled ε, we get back the maximum angle for that precision:

    - +

    And frankly, things are starting to look a bit ridiculous at this point, we're doing way more maths than we've ever done, but thankfully this is as far as we need the maths to take us: If we plug in the precisions 0.1, 0.01, 0.001 and 0.0001 we get the radians values 1.748, 1.038, 0.594 and 0.3356; in degrees, that means we can cover roughly 100 degrees (requiring four curves), 59.5 degrees (requiring six curves), 34 degrees (requiring 11 curves), and 19.2 degrees (requiring a whopping nineteen curves).

    The bottom line? Quadratic curves are kind of lousy if you want circular (or elliptical, which are circles that have been squashed in one dimension) curves. We can do better, even if it's just by raising the order of our curve once. So let's try the same thing for cubic curves.

    @@ -2311,7 +2311,7 @@ for p = 1 to points.length-3 (inclusive):

    The distance from our guessed point to the start point is exactly the same as the projection distance we looked at earlier. Using t=0.5 as our point "B" in the "A,B,C" projection, then we know the length of the line segment {C,A}, since it's d1 = {A,B} + d2 = {B,C}:

    So that just leaves us to find the distance from t=0.5 to the baseline for an arbitrary angle φ, which is the distance from the centre of the circle to our t=0.5 point, minus the distance from the centre to the line that runs from start point to end point. The first is the same as the point P we found for the quadratic curve:

    - +

    And the distance from the origin to the line start/end is another application of angles, since the triangle {origin,start,C} has known angles, and two known sides. We can find the length of the line {origin,C}, which lets us trivially compute the coordinate for C:

    With the coordinate C, and knowledge of coordinate B, we can determine coordinate A, and get a vector that is identical to the vector {start,guess}:

    @@ -2427,27 +2427,27 @@ for p = 1 to points.length-3 (inclusive):

    In order to make this interpolation of curves work, the maths is necessarily more complex than the maths for Bézier curves, so let's have a look at how things work.

    How to compute a B-Spline curve: some maths

    Given a B-Spline of degree d and thus order k=d+1 (so a quadratic B-Spline is degree 2 and order 3, a cubic B-Spline is degree 3 and order 4, etc) and n control points P0 through Pn-1, we can compute a point on the curve for some value t in the interval [0,1] (where 0 is the start of the curve, and 1 the end, just like for Bézier curves), by evaluating the following function:

    - +

    Which, honestly, doesn't tell us all that much. All we can see is that a point on a B-Spline curve is defined as "a mix of all the control points, weighted somehow", where the weighting is achieved through the N(...) function, subscripted with an obvious parameter i, which comes from our summation, and some magical parameter k. So we need to know two things: 1. what does N(t) do, and 2. what is that k? Let's cover both, in reverse order.

    The parameter k represents the "knot interval" over which a section of curve is defined. As we learned earlier, a B-Spline curve is itself an interpoliation of curves, and we can treat each transition where a control point starts or stops influencing the total curvature as a "knot on the curve". Doing so for a degree d B-Spline with n control point gives us d + n + 1 knots, defining d + n intervals along the curve, and it is these intervals that the above k subscript to the N() function applies to.

    Then the N() function itself. What does it look like?

    - +

    So this is where we see the interpolation: N(t) for an (i,k) pair (that is, for a step in the above summation, on a specific knot interval) is a mix between N(t) for (i,k-1) and N(t) for (i+1,k-1), so we see that this is a recursive iteration where i goes up, and k goes down, so it seem reasonable to expect that this recursion has to stop at some point; obviously, it does, and specifically it does so for the following i/k values:

    - +

    And this function finally has a straight up evaluation: if a t value lies within a knot-specific interval once we reach a k=1 value, it "counts", otherwise it doesn't. We did cheat a little, though, because for all these values we need to scale our t value first, so that it lies in the interval bounded by knots[d] and knots[n], which are the start point and end point where curvature is controlled by exactly order control points. For instance, for degree 3 (=order 4) and 7 control points, with knot vector [1,2,3,4,5,6,7,8,9,10,11], we map t from [the interval 0,1] to the interval [4,8], and then use that value in the functions above, instead.

    Can we simplify that?

    We can, yes.

    People far smarter than us have looked at this work, and two in particular — Maurice Cox and Carl de Boor — came to a mathematically pleasing solution: to compute a point P(t), we can compute this point by evaluating d(t) on a curve section between knots i and i+1:

    - +

    This is another recursive function, with k values decreasing from the curve order to 1, and the value α (alpha) defined by:

    - +

    That looks complicated, but it's not. Computing alpha is just a fraction involving known, plain numbers. And, once we have our alpha value, we also have (1-alpha) because it's a trivial subtraction. Computing the d() function is thus mostly a matter of computing pretty simple arithmetical statements, with some caching of results so we can refer to them as we recurve. While the recursion might see computationally expensive, the total algorithm is cheap, as each step only involves very simple maths.

    Of course, the recursion does need a stop condition:

    - +

    So, we actually see two stopping conditions: either i becomes 0, in which case d() is zero, or k becomes zero, in which case we get the same "either 1 or 0" that we saw in the N() function above.

    Thanks to Cox and de Boor, we can compute points on a B-Spline pretty easily using the same kind of linear interpolation we saw in de Casteljau's algorithm. For instance, if we write out d() for i=3 and k=3, we get the following recursion diagram:

    - +

    That is, we compute d(3,3) as a mixture of d(2,3) and d(2,2), where those two are themselves a mixture of d(1,3) and d(1,2), and d(1,2) and d(1,1), respectively, which are themselves a mixture of etc. etc. We simply keep expanding our terms until we reach the stop conditions, and then sum everything back up. It's really quite elegant.

    One thing we need to keep in mind is that we're working with a spline that is constrained by its control points, so even though the d(..., k) values are zero or one at the lowest level, they are really "zero or one, times their respective control point", so in the next section you'll see the algorithm for running through the computation in a way that starts with a copy of the control point vector and then works its way up to that single point, rather than first starting "on the left", working our way "to the right" and then summing back up "to the left". We can just start on the right and work our way left immediately.

    Running the computation

    diff --git a/docs/ja-JP/index.html b/docs/ja-JP/index.html index 05ffc7f1..b19d7d1b 100644 --- a/docs/ja-JP/index.html +++ b/docs/ja-JP/index.html @@ -307,14 +307,14 @@

    ベジエ曲線の数学

    ベジエ曲線は「パラメトリック」関数の一種です。数学的に言えば、パラメトリック関数というのはインチキです。というのも、「関数」はきっちり定義された用語であり、いくつかの入力を1つの出力に対応させる写像を表すものだからです。いくつかの数値を入れると、1つの数値が出てきます。入れる数値が変わっても、出てくる数値はやはり1つだけです。パラメトリック関数はインチキです。基本的には「じゃあわかった、値を複数個出したいから、関数を複数個使うことにするよ」ということです。例として、ある値xに何らかの操作を行い、別の値へと写す関数があるとします。

    - +

    f(x)という記法は、これが関数(1つしかない場合は慣習的にfと呼びます)であり、その出力が1つの変数(この場合はxです)に応じて変化する、ということを示す標準的な方法です。xを変化させると、f(x)の出力が変化します。

    ここまでは順調です。では、パラメトリック関数について、これがどうインチキなのかを見てみましょう。以下の2つの関数を考えます。

    - +

    注目すべき箇所は特に何もありません。ただの正弦関数と余弦関数です。ただし、入力が別々の名前になっていることに気づくでしょう。仮にaの値を変えたとしても、f(b)の出力の値は変わらないはずです。なぜなら、こちらの関数にはaは使われていないからです。パラメトリック関数は、これを変えてしまうのでインチキなのです。パラメトリック関数においては、どの関数も変数を共有しています。例えば、

    - +

    複数の関数がありますが、変数は1つだけです。tの値を変えた場合、fa(t)fb(t)の両方の出力が変わります。これがどのように役に立つのか、疑問に思うかもしれません。しかし、実際には答えは至ってシンプルです。fa(t)fb(t)のラベルを、パラメトリック曲線の表示によく使われているもので置き換えてやれば、ぐっとはっきりするかと思います。

    - +

    きました。x/y座標です。謎の値tを通して繫がっています。

    というわけで、普通の関数ではy座標をx座標によって定義しますが、パラメトリック曲線ではそうではなく、座標の値を「制御」変数と結びつけます。tの値を変化させるたびに2つの値が変化するので、これをグラフ上の座標 (x,y)として使うことができます。例えば、先ほどの関数の組は円周上の点を生成します。負の無限大から正の無限大へとtを動かすと、得られる座標(x,y)は常に中心(0,0)・半径1の円の上に乗ります。tを0から5まで変化させてプロットした場合は、このようになります。

    @@ -328,7 +328,7 @@

    ベジエ曲線はパラメトリック関数の一種であり、どの次元に対しても同じ基底関数を使うという点で特徴づけられます。先ほどの例では、xの値とyの値とで異なる関数(正弦関数と余弦関数)を使っていましたが、ベジエ曲線ではxyの両方で「二項係数多項式」を使います。では、二項係数多項式とは何でしょう?

    高校で習った、こんな形の多項式を思い出すかもしれません。

    - +

    最高次の項がであれば3次多項式、であれば2次多項式と呼び、xだけの場合は1次多項式――ただの直線です。(そしてxの入った項が何もなければ、多項式ではありません!)

    ベジエ曲線はxの多項式ではなく、tの多項式です。tの値は0から1までの間に制限され、その係数abなどは「二項係数」の形をとります。というと複雑そうに聞こえますが、実際には値を組み合わせて、とてもシンプルに記述できます。

    @@ -468,9 +468,9 @@ function Bezier(3,t,w[]):

    Controlling Bézier curvatures, part 2: Rational Béziers

    We can further control Bézier curves by "rationalising" them: that is, adding a "ratio" value in addition to the weight value discussed in the previous section, thereby gaining control over "how strongly" each coordinate influences the curve.

    Adding these ratio values to the regular Bézier curve function is fairly easy. Where the regular function is the following:

    - +

    The function for rational Bézier curves has two more terms:

    - +

    In this, the first new term represents an additional weight for each coordinate. For example, if our ratio values are [1, 0.5, 0.5, 1] then ratio0 = 1, ratio1 = 0.5, and so on, and is effectively identical as if we were just using different weight. So far, nothing too special.

    However, the second new term is what makes the difference: every point on the curve isn't just a "double weighted" point, it is a fraction of the "doubly weighted" value we compute by introducing that ratio. When computing points on the curve, we compute the "normal" Bézier value and then divide that by the Bézier value for the curve that only uses ratios, not weights.

    This does something unexpected: it turns our polynomial into something that isn't a polynomial anymore. It is now a kind of curve that is a super class of the polynomials, and can do some really cool things that Bézier curves can't do "on their own", such as perfectly describing circles (which we'll see in a later section is literally impossible using standard Bézier curves).

    @@ -771,30 +771,30 @@ function drawCurve(points[], t):

    One interesting property of Bézier curves is that an nth order curve can always be perfectly represented by an (n+1)th order curve, by giving the higher-order curve specific control points.

    If we have a curve with three points, then we can create a curve with four points that exactly reproduces the original curve. First, we give it the same start and end points, and for its two control points we pick "1/3rd start + 2/3rd control" and "2/3rd control + 1/3rd end". Now we have exactly the same curve as before, except represented as a cubic curve rather than a quadratic curve.

    The general rule for raising an nth order curve to an (n+1)th order curve is as follows (observing that the start and end weights are the same as the start and end weights for the old curve):

    - +

    However, this rule also has as direct consequence that you cannot generally safely lower a curve from nth order to (n-1)th order, because the control points cannot be "pulled apart" cleanly. We can try to, but the resulting curve will not be identical to the original, and may in fact look completely different.

    However, there is a surprisingly good way to ensure that a lower order curve looks "as close as reasonably possible" to the original curve: we can optimise the "least-squares distance" between the original curve and the lower order curve, in a single operation (also explained over on Sirver's Castle). However, to use it, we'll need to do some calculus work and then switch over to linear algebra. As mentioned in the section on matrix representations, some things can be done much more easily with matrices than with calculus functions, and this is one of those things. So... let's go!

    We start by taking the standard Bézier function, and condensing it a little:

    - +

    Then, we apply one of those silly (actually, super useful) calculus tricks: since our t value is always between zero and one (inclusive), we know that (1-t) plus t always sums to 1. As such, we can express any value as a sum of t and 1-t:

    - +

    So, with that seemingly trivial observation, we rewrite that Bézier function by splitting it up into a sum of a (1-t) and t component:

    - +

    So far so good. Now, to see why we did this, let's write out the (1-t) and t parts, and see what that gives us. I promise, it's about to make sense. We start with (1-t):

    - +

    So by using this seemingly silly trick, we can suddenly express part of our nth order Bézier function in terms of an (n+1)th order Bézier function. And that sounds a lot like raising the curve order! Of course we need to be able to repeat that trick for the t part, but that's not a problem:

    - +

    So, with both of those changed from an order n expression to an order (n+1) expression, we can put them back together again. Now, where the order n function had a summation from 0 to n, the order n+1 function uses a summation from 0 to n+1, but this shouldn't be a problem as long as we can add some new terms that "contribute nothing". In the next section on derivatives, there is a discussion about why "higher terms than there is a binomial for" and "lower than zero terms" both "contribute nothing". So as long as we can add terms that have the same form as the terms we need, we can just include them in the summation, they'll sit there and do nothing, and the resulting function stays identical to the lower order curve.

    Let's do this:

    - +

    And this is where we switch over from calculus to linear algebra, and matrices: we can now express this relation between Bézier(n,t) and Bézier(n+1,t) as a very simple matrix multiplication:

    - +

    where the matrix M is an n+1 by n matrix, and looks like:

    - +

    That might look unwieldy, but it's really just a mostly-zeroes matrix, with a very simply fraction on the diagonal, and an even simpler fraction to the left of it. Multiplying a list of coordinates with this matrix means we can plug the resulting transformed coordinates into the one-order-higher function and get an identical looking curve.

    Not too bad!

    Equally interesting, though, is that with this matrix operation established, we can now use an incredibly powerful and ridiculously simple way to find out a "best fit" way to reverse the operation, called the normal equation. What it does is minimize the sum of the square differences between one set of values and another set of values. Specifically, if we can express that as some function A x = b, we can use it. And as it so happens, that's exactly what we're dealing with, so:

    - +

    The steps taken here are:

    1. We have a function in a form that the normal equation can be used with, so
    2. @@ -859,20 +859,20 @@ function drawCurve(points[], t):

      Tangents and normals

      If you want to move objects along a curve, or "away from" a curve, the two vectors you're most interested in are the tangent vector and normal vector for curve points. These are actually really easy to find. For moving and orienting along a curve, we use the tangent, which indicates the direction of travel at specific points, and is literally just the first derivative of our curve:

      - +

      This gives us the directional vector we want. We can normalize it to give us uniform directional vectors (having a length of 1.0) at each point, and then do whatever it is we want to do based on those directions:

      - - + +

      The tangent is very useful for moving along a line, but what if we want to move away from the curve instead, perpendicular to the curve at some point t? In that case we want the normal vector. This vector runs at a right angle to the direction of the curve, and is typically of length 1.0, so all we have to do is rotate the normalized directional vector and we're done:

      - +

      Rotating coordinates is actually very easy, if you know the rule for it. You might find it explained as "applying a rotation matrix, which is what we'll look at here, too. Essentially, the idea is to take the circles over which we can rotate, and simply "sliding the coordinates" over these circles by the desired angle. If we want a quarter circle turn, we take the coordinate, slide it along the cirle by a quarter turn, and done.

      To turn any point (x,y) into a rotated point (x',y') (over 0,0) by some angle φ, we apply this nice and easy computation:

      - +

      Which is the "long" version of the following matrix transformation:

      - +

      And that's all we need to rotate any coordinate. Note that for quarter, half, and three-quarter turns these functions become even easier, since sin and cos for these angles are, respectively: 0 and 1, -1 and 0, and 0 and -1.

      But why does this work? Why this matrix multiplication? Wikipedia (technically, Thomas Herter and Klaus Lott) tells us that a rotation matrix can be treated as a sequence of three (elementary) shear operations. When we combine this into a single matrix operation (because all matrix multiplications can be collapsed), we get the matrix that you see above. DataGenetics have an excellent article about this very thing: it's really quite cool, and I strongly recommend taking a quick break from this primer to read that article.

      @@ -1030,27 +1030,27 @@ treated as a sequence of three (elementary) shear operations. When we combine th

      Now that we understand (well, superficially anyway) the component functions, we can find the extremities of our Bézier curve by finding maxima and minima on the component functions, by solving the equation B'(t) = 0. We've already seen that the derivative of a Bézier curve is a simpler Bézier curve, but how do we solve the equality? Fairly easily, actually, until our derivatives are 4th order or higher... then things get really hard. But let's start simple:

      Quadratic curves: linear derivatives.

      The derivative of a quadratic Bézier curve is a linear Bézier curve, interpolating between just two terms, which means finding the solution for "where is this line 0" is effectively trivial by rewriting it to a function of t and solving. First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

      - +

      And then we turn this into our solution for t using basic arithmetics:

      - +

      Done.

      Although with the caveat that if b-a is zero, there is no solution and we probably shouldn't try to perform that division.

      Cubic curves: the quadratic formula.

      The derivative of a cubic Bézier curve is a quadratic Bézier curve, and finding the roots for a quadratic polynomial means we can apply the Quadratic formula. If you've seen it before, you'll remember it, and if you haven't, it looks like this:

      - +

      So, if we can rewrite the Bézier component function as a plain polynomial, we're done: we just plug in the values into the quadratic formula, check if that square root is negative or not (if it is, there are no roots) and then just compute the two values that come out (because of that plus/minus sign we get two). Any value between 0 and 1 is a root that matters for Bézier curves, anything below or above that is irrelevant (because Bézier curves are only defined over the interval [0,1]). So, how do we convert?

      First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

      - +

      And then, using these v values, we can find out what our a, b, and c should be:

      - +

      This gives us three coefficients {a, b, c} that are expressed in terms of v values, where the v values are expressions of our original coordinate values, so we can do some substitution to get:

      - +

      Easy-peasy. We can now almost trivially find the roots by plugging those values into the quadratic formula.

      And as a cubic curve, there is also a meaningful second derivative, which we can compute by simple taking the derivative of the derivative.

      Quartic curves: Cardano's algorithm.

      We haven't really looked at them before now, but the next step up would be a Quartic curve, a fourth degree Bézier curve. As expected, these have a derivative that is a cubic function, and now things get much harder. Cubic functions don't have a "simple" rule to find their roots, like the quadratic formula, and instead require quite a bit of rewriting to a form that we can even start to try to solve.

      Back in the 16th century, before Bézier curves were a thing, and even before calculus itself was a thing, Gerolamo Cardano figured out that even if the general cubic function is really hard to solve, it can be rewritten to a form for which finding the roots is "easier" (even if not "easy"):

      - +

      We can see that the easier formula only has two constants, rather than four, and only two expressions involving t, rather than three: this makes things considerably easier to solve because it lets us use regular calculus to find the values that satisfy the equasion.

      Now, there is one small hitch: as a cubic function, the solutions may be complex numbers rather than plain numbers... And Cardona realised this, centuries befor complex numbers were a well-understood and established part of number theory. His interpretation of them was "these numbers are impossible but that's okay because they disappear again in later steps", allowing him to not think about them too much, but we have it even easier: as we're trying to find the roots for display purposes, we don't even care about complex numbers: we're going to simplify Cardano's approach just that tiny bit further by throwing away any solution that's not a plain number.

      So, how do we rewrite the hard formula into the easier formula? This is explained in detail over at Ken J. Ward's page for solving the cubic equation, so instead of showing the maths, I'm simply going to show the programming code for solving the cubic equation, with the complex roots getting totally ignored, but if you're interested you should definitely head over to Ken's page and give the procedure a read-through.

      @@ -1148,7 +1148,7 @@ function getCubicRoots(pa, pb, pc, pd) {

      That's a fancy term for saying "rather than trying to find exact answers by manipulating symbols, find approximate answers by describing the underlying process as a combination of steps, each of which can be assigned a number via symbolic manipulation". For example, trying to mathematically compute how much water fits in a completely crazy three dimensional shape is very hard, even if it got you the perfect, precise answer. A much easier approach, which would be less perfect but still entirely useful, would be to just grab a buck and start filling the shape until it was full: just count the number of buckets of water you used. And if we want a more precise answer, we can use smaller buckets.

      So that's what we're going to do here, too: we're going to treat the problem as a sequence of steps, and the smaller we can make each step, the closer we'll get to that "perfect, precise" answer. And as it turns out, there is a really nice numerical root-finding algorithm, called the Newton-Raphson root finding method (yes, after that Newton), which we can make use of. The Newton-Raphson approach consists of taking our impossible-to-solve function f(x), picking some intial value x (literally any value will do), and calculating f(x). We can think of that value as the "height" of the function at x. If that height is zero, we're done, we have found a root. If it isn't, we calculate the tangent line at f(x) and calculate at which x value its height is zero (which we've already seen is very easy). That will give us a new x and we repeat the process until we find a root.

      Mathematically, this means that for some x, at step n=1, we perform the following calculation until fy(x) is zero, so that the next t is the same as the one we already have:

      - +

      (The Wikipedia article has a decent animation for this process, so I will not add a graphic for that here)

      Now, this works well only if we can pick good starting points, and our curve is continuously differentiable and doesn't have oscillations. Glossing over the exact meaning of those terms, the curves we're dealing with conform to those constraints, so as long as we pick good starting points, this will work. So the question is: which starting points do we pick?

      As it turns out, Newton-Raphson is so blindingly fast that we could get away with just not picking: we simply run the algorithm from t=0 to t=1 at small steps (say, 1/200th) and the result will be all the roots we want. Of course, this may pose problems for high order Bézier curves: 200 steps for a 200th order Bézier curve is going to go wrong, but that's okay: there is no reason (at least, none that I know of) to ever use Bézier curves of crazy high orders. You might use a fifth order curve to get the "nicest still remotely workable" approximation of a full circle with a single Bézier curve, but that's pretty much as high as you'll ever need to go.

      @@ -1202,13 +1202,13 @@ function getCubicRoots(pa, pb, pc, pd) {

      Aligning curves

      While there are an incredible number of curves we can define by varying the x- and y-coordinates for the control points, not all curves are actually distinct. For instance, if we define a curve, and then rotate it 90 degrees, it's still the same curve, and we'll find its extremities in the same spots, just at different draw coordinates. As such, one way to make sure we're working with a "unique" curve is to "axis-align" it.

      Aligning also simplifies a curve's functions. We can translate (move) the curve so that the first point lies on (0,0), which turns our n term polynomial functions into n-1 term functions. The order stays the same, but we have less terms. Then, we can rotate the curves so that the last point always lies on the x-axis, too, making its coordinate (...,0). This further simplifies the function for the y-component to an n-2 term function. For instance, if we have a cubic curve such as this:

      - +

      Then translating it so that the first coordinate lies on (0,0), moving all x coordinates by -120, and all y coordinates by -160, gives us:

      - +

      If we then rotate the curve so that its end point lies on the x-axis, the coordinates (integer-rounded for illustrative purposes here) become:

      - +

      If we drop all the zero-terms, this gives us:

      - +

      We can see that our original curve definition has been simplified considerably. The following graphics illustrate the result of aligning our example curves to the x-axis, with the cubic case using the coordinates that were just used in the example formulae:

      @@ -1253,29 +1253,29 @@ function getCubicRoots(pa, pb, pc, pd) {

      Now that we know how to align a curve, there's one more thing we can calculate: inflection points. Imagine we have a variable size circle that we can slide up against our curve. We place it against the curve and adjust its radius so that where it touches the curve, the curvatures of the curve and the circle are the same, and then we start to slide the circle along the curve - for quadratic curves, we can always do this without the circle behaving oddly: we might have to change the radius of the circle as we slide it along, but it'll always sit against the same side of the curve.

      But what happens with cubic curves? Imagine we have an S curve and we place our circle at the start of the curve, and start sliding it along. For a while we can simply adjust the radius and things will be fine, but once we get to the midpoint of that S, something odd happens: the circle "flips" from one side of the curve to the other side, in order for the curvatures to keep matching. This is called an inflection, and we can find out where those happen relatively easily.

      What we need to do is solve a simple equation:

      - +

      What we're saying here is that given the curvature function C(t), we want to know for which values of t this function is zero, meaning there is no "curvature", which will be exactly at the point between our circle being on one side of the curve, and our circle being on the other side of the curve. So what does C(t) look like? Actually something that seems not too hard:

      - +

      The function C(t) is the cross product between the first and second derivative functions for the parametric dimensions of our curve. And, as already shown, derivatives of Bézier curves are just simpler Bézier curves, with very easy to compute new coefficients, so this should be pretty easy.

      However as we've seen in the section on aligning, aligning lets us simplify things a lot, by completely removing the contributions of the first coordinate from most mathematical evaluations, and removing the last y coordinate as well by virtue of the last point lying on the x-axis. So, while we can evaluate C(t) = 0 for our curve, it'll be much easier to first axis-align the curve and then evaluating the curvature function.

      Let's derive the full formula anyway

      Of course, before we do our aligned check, let's see what happens if we compute the curvature function without axis-aligning. We start with the first and second derivatives, given our basis functions:

      - +

      And of course the same functions for y:

      - +

      Asking a computer to now compose the C(t) function for us (and to expand it to a readable form of simple terms) gives us this rather overly complicated set of arithmetic expressions:

      - +

      That is... unwieldy. So, we note that there are a lot of terms that involve multiplications involving x1, y1, and y4, which would all disappear if we axis-align our curve, which is why aligning is a great idea.

      Aligning our curve so that three of the eight coefficients become zero, and observing that scale does not affect finding t values, we end up with the following simple term function for C(t):

      - +

      That's a lot easier to work with: we see a fair number of terms that we can compute and then cache, giving us the following simplification:

      - +

      This is a plain quadratic curve, and we know how to solve C(t) = 0; we use the quadratic formula:

      - +

      We can easily compute this value if the discriminator isn't a negative number (because we only want real roots, not complex roots), and if x is not zero, because divisions by zero are rather useless.

      Taking that into account, we compute t, we disregard any t value that isn't in the Bézier interval [0,1], and we now know at which t value(s) our curve will inflect.

      @@ -1304,13 +1304,13 @@ function getCubicRoots(pa, pb, pc, pd) {
    3. ...anywhere inside the red zone, but not on its boundaries, the curve will either be self-intersecting (yielding a loop). We won't know where it self-intersects (in terms of t values), but we are guaranteed that it does.

    4. ...on the left (red) edge of the red zone, the curve will have a cusp. We again don't know where, but we know there is one. This edge is described by the function:

      - +
    5. ...on the almost circular, lower right (pink) edge, the curve's end point touches the curve, forming a loop. This edge is described by the function:

      - +
    6. ...on the top (blue) edge, the curve's start point touches the curve, forming a loop. This edge is described by the function:

      - +
    7. ...inside the lower (green) zone, past y=1, the curve will have a single inflection (switching concave/convex once).

    8. @@ -1331,24 +1331,24 @@ function getCubicRoots(pa, pb, pc, pd) {

      So now the question becomes: how do we manipulate our curve so that it fits this canonical form, with three fixed points, and one "free" point? Enter linear algebra. Don't worry, I'll be doing all the math for you, as well as show you what the effect is on our curves, but basically we're going to be using linear algebra, rather than calculus, because "it's way easier". Sometimes a calculus approach is very hard to work with, when the equivalent geometrical solution is super obvious.

      The approach is going to start with a curve that doesn't have all-colinear points (so we need to make sure the points don't all fall on a straight line), and then applying three graphics operations that you will probably have heard of: translation (moving all points by some fixed x- and y-distance), scaling (multiplying all points by some x and y scale factor), and shearing (an operation that turns rectangles into parallelograms).

      Step 1: we translate any curve by -p1.x and -p1.y, so that the curve starts at (0,0). We're going to make use of an interesting trick here, by pretending our 2D coordinates are 3D, with the z coordinate simply always being 1. This is an old trick in graphics to overcome the limitations of 2D transformations: without it, we can only turn (x,y) coordinates into new coordinates of the form (ax + by, cx + dy), which means we can't do translation, since that requires we end up with some kind of (x + a, y + b). If we add a bogus z coordinate that is always 1, then we can suddenly add arbitrary values. For example:

      - +

      Sweet! z stays 1, so we can effectively ignore it entirely, but we added some plain values to our x and y coordinates. So, if we want to subtract p1.x and p1.y, we use:

      - +

      Running all our coordinates through this transformation gives a new set of coordinates, let's call those U, where the first coordinate lies on (0,0), and the rest is still somewhat free. Our next job is to make sure point 2 ends up lying on the x=0 line, so what we want is a transformation matrix that, when we run it, subtracts x from whatever x we currently have. This is called shearing, and the typical x-shear matrix and its transformation looks like this:

      - +

      So we want some shearing value that, when multiplied by y, yields -x, so our x coordinate becomes zero. That value is simply -x/y, because *-x/y * y = -x*. Done:

      - +

      Now, running this on all our points generates a new set of coordinates, let's call those V, which now have point 1 on (0,0) and point 2 on (0, some-value), and we wanted it at (0,1), so we need to do some scaling to make sure it ends up at (0,1). Additionally, we want point 3 to end up on (1,1), so we can also scale x to make sure its x-coordinate will be 1 after we run the transform. That means we'll be x-scaling by 1/point3x, and y-scaling by point2y. This is really easy:

      - +

      Then, finally, this generates a new set of coordinates, let's call those W, of which point 1 lies on (0,0), point 2 lies on (0,1), and point three lies on (1, ...) so all that's left is to make sure point 3 ends up at (1,1) - but we can't scale! Point 2 is already in the right place, and y-scaling would move it out of (0,1) again, so our only option is to y-shear point three, just like how we x-sheared point 2 earlier. In this case, we do the same trick, but with y/x rather than x/y because we're not x-shearing but y-shearing. Additionally, we don't actually want to end up at zero (which is what we did before) so we need to shear towards an offset, in this case 1:

      - +

      And this generates our final set of four coordinates. Of these, we already know that points 1 through 3 are (0,0), (0,1) and (1,1), and only the last coordinate is "free". In fact, given any four starting coordinates, the resulting "transformation mapped" coordinate will be:

      - +

      Okay, well, that looks plain ridiculous, but: notice that every coordinate value is being offset by the initial translation, and also notice that a lot of terms in that expression are repeated. Even though the maths looks crazy as a single expression, we can just pull this apart a little and end up with an easy-to-calculate bit of code!

      First, let's just do that translation step as a "preprocessing" operation so we don't have to subtract the values all the time. What does that leave?

      - +

      Suddenly things look a lot simpler: the mapped x is fairly straight forward to compute, and we see that the mapped y actually contains the mapped x in its entirety, so we'll have that part already available when we need to evaluate it. In fact, let's pull out all those common factors to see just how simple this is:

      - +

      That's kind of super-simple to write out in code, I think you'll agree. Coding math tends to be easier than the formulae initially make it look!

      @@ -1381,11 +1381,11 @@ function getCubicRoots(pa, pb, pc, pd) {

      Now, if you look more closely at that right graphic, you'll notice something interesting: if we treat the red line as "the x axis", then the point where the function crosses our line is really just a root for the cubic function x(t) through a shifted "x-axis"... and we've already seen how to calculate roots, so let's just run cubuc root finding - and not even the complicated cubic case either: because of the kind of curve we're starting with, we know there is only root, simplifying the code we need!

      First, let's look at the function for x(t):

      - +

      We can rewrite this to a plain polynomial form, by just fully writing out the expansion and then collecting the polynomial factors, as:

      - +

      Nothing special here: that's a standard cubic polynomial in "power" form (i.e. all the terms are ordered by their power of t). So, given that a, b, c, d, and x(t) are all known constants, we can trivially rewrite this (by moving the x(t) across the equal sign) as:

      - +

      You might be wondering "where did all the other 'minus x' for all the other values a, b, c, and d go?" and the answer there is that they all cancel out, so the only one we actually need to subtract is the one at the end. Handy! So now we just solve this equation using Cardano's algorithm, and we're left with some rather short code:

      // prepare our values for root finding:
       x = a value we already know
      @@ -1412,13 +1412,13 @@ y = curve.get(t).y

      Arc length

      How long is a Bézier curve? As it turns out, that's not actually an easy question, because the answer requires maths that —much like root finding— cannot generally be solved the traditional way. If we have a parametric curve with fx(t) and fy(t), then the length of the curve, measured from start point to some point t = z, is computed using the following seemingly straight forward (if a bit overwhelming) formula:

      - +

      or, more commonly written using Leibnitz notation as:

      - +

      This formula says that the length of a parametric curve is in fact equal to the area underneath a function that looks a remarkable amount like Pythagoras' rule for computing the diagonal of a straight angled triangle. This sounds pretty simple, right? Sadly, it's far from simple... cutting straight to after the chase is over: for quadratic curves, this formula generates an unwieldy computation, and we're simply not going to implement things that way. For cubic Bézier curves, things get even more fun, because there is no "closed form" solution, meaning that due to the way calculus works, there is no generic formula that allows you to calculate the arc length. Let me just repeat this, because it's fairly crucial: for cubic and higher Bézier curves, there is no way to solve this function if you want to use it "for all possible coordinates".

      Seriously: It cannot be done.

      So we turn to numerical approaches again. The method we'll look at here is the Gauss quadrature. This approximation is a really neat trick, because for any nth degree polynomial it finds approximated values for an integral really efficiently. Explaining this procedure in length is way beyond the scope of this page, so if you're interested in finding out why it works, I can recommend the University of South Florida video lecture on the procedure, linked in this very paragraph. The general solution we're looking for is the following:

      - +

      In plain text: an integral function can always be treated as the sum of an (infinite) number of (infinitely thin) rectangular strips sitting "under" the function's plotted graph. To illustrate this idea, the following graph shows the integral for a sinusoid function. The more strips we use (and of course the more we use, the thinner they get) the closer we get to the true area under the curve, and thus the better the approximation:

      @@ -1447,12 +1447,12 @@ y = curve.get(t).y

      Note that one requirement for the approach we'll use is that the integral must run from -1 to 1. That's no good, because we're dealing with Bézier curves, and the length of a section of curve applies to values which run from 0 to "some value smaller than or equal to 1" (let's call that value z). Thankfully, we can quite easily transform any integral interval to any other integral interval, by shifting and scaling the inputs. Doing so, we get the following:

      - +

      That may look a bit more complicated, but the fraction involving z is a fixed number, so the summation, and the evaluation of the f(t) values are still pretty simple.

      So, what do we need to perform this calculation? For one, we'll need an explicit formula for f(t), because that derivative notation is handy on paper, but not when we have to implement it. We'll also need to know what these Ci and ti values should be. Luckily, that's less work because there are actually many tables available that give these values, for any n, so if we want to approximate our integral with only two terms (which is a bit low, really) then these tables would tell us that for n=2 we must use the following values:

      - +

      Which means that in order for us to approximate the integral, we must plug these values into the approximate function, which gives us:

      - +

      We can program that pretty easily, provided we have that f(t) available, which we do, as we know the full description for the Bézier curve functions Bx(t) and By(t).

      @@ -1514,9 +1514,9 @@ y = curve.get(t).y

      That's crazy!

      But that's also one of the things that makes maths so powerful: even if your initial ideas are off the mark, you might be much closer than you thought you were, and the journey from "thinking we're completely wrong" to "actually being remarkably close to being right" is where we can find a lot of insight.

      So, what does the function look like? This:

      - +

      Which is really just a "short form" that glosses over the fact that we're dealing with functions of t, so let's expand that a tiny bit:

      - +

      And while that's a litte more verbose, it's still just as simple to work with as the first function: the curvature at some point on any (and this cannot be overstated: any) curve is a ratio between the first and second derivative cross product, and something that looks oddly similar to the standard Euclidean distance function. And nothing in these functions is hard to calculate either: for Bézier curves, simply knowing our curve coordinates means we know what the first and second derivatives are, and so evaluating this function for any t value is just a matter of basic arithematics.

      In fact, let's just implement it right now:

      function kappa(t, B):
      @@ -1700,24 +1700,24 @@ lli = function(line1, line2):
       

    These three values A, B, and C allow us to derive an important identity formula for quadratic and cubic Bézier curves: for any point on the curve with some t value, the ratio of distances from A to B and B to C is fixed: if some t value sets up a C that is 20% away from the start and 80% away from the end, then it doesn't matter where the start, end, or control points are; for that t value, C will always lie at 20% from the start and 80% from the end point. Go ahead, pick an on-curve point in either graphic and then move all the other points around: if you only move the control points, start and end won't move, and so neither will C, and if you move either start or end point, C will move but its relative position will not change.

    So, how can we compute C? We start with our observation that C always lies somewhere between the start and ends points, so logically C will have a function that interpolates between those two coordinates:

    - +

    If we can figure out what the function u(t) looks like, we'll be done. Although we do need to remember that this u(t) will have a different for depending on whether we're working with quadratic or cubic curves. Running through the maths (with thanks to Boris Zbarsky) shows us the following two formulae:

    - +

    And

    - +

    So, if we know the start and end coordinates, and we know the t value, we know C, without having to calculate the A or even B coordinates. In fact, we can do the same for the ratio function: as another function of t, we technically don't need to know what A or B or C are, we can express it was a pure function of t, too.

    We start by observing that, given A, B, and C, the following always holds:

    - +

    Working out the maths for this, we see the following two formulae for quadratic and cubic curves:

    - +

    And

    - +

    Which now leaves us with some powerful tools: given thee points (start, end, and "some point on the curve"), as well as a t value, we can contruct curves: we can compute C using the start and end points, and our u(t) function, and once we have C, we can use our on-curve point (B) and the ratio(t) function to find A:

    - +

    With A found, finding e1 and e2 for quadratic curves is a matter of running the linear interpolation with t between start and A to yield e1, and between A and end to yield e2. For cubic curves, there is no single pair of points that can act as e1 and e2: as long as the distance ratio between e1 to B and B to e2 is the Bézier ratio (1-t):t, we can reverse engineer v1 and v2:

    - +

    And then reverse engineer the curve's control control points:

    - +

    So: if we have a curve's start and end point, then for any t value we implicitly know all the ABC values, which (combined with an educated guess on appropriate e1 and e2 coordinates for cubic curves) gives us the necessary information to reconstruct a curve's "de Casteljau skeleton". Which means that we can now do several things: we can "fit" curves using only three points, which means we can also "mold" curves by moving an on-curve point but leaving its start and end point, and then reconstructing the curve based on where we moved the on-curve point to. These are very useful things, and we'll look at both in the next few sections.

    @@ -1725,7 +1725,7 @@ lli = function(line1, line2):

    Creating a curve from three points

    Given the preceding section, you might be wondering if we can use that knowledge to just "create" curves by placing some points and having the computer do the rest, to which the answer is: that's exactly what we can now do!

    For quadratic curves, things are pretty easy. Technically, we'll need a t value in order to compute the ratio function used in computing the ABC coordinates, but we can just as easily approximate one by treating the distance between the start and B point, and B and end point as a ratio, using

    - +

    With this code in place, creating a quadratic curve from three points is literally just computing the ABC values, and using A as our curve's control point:

    @@ -1744,11 +1744,11 @@ lli = function(line1, line2):

    With that covered, we now also know the tangent line to our point B, because the tangent to any point on the circle is a line through that point, perpendicular to the line from that point to the center. That just leaves marking appropriate points e1 and e2 on that tangent, so that we can construct a new cubic curve hull. We use the approach as we did for quadratic curves to automatically determine a reasonable t value, and then our e1 and e2 coordinates must obey the standard de Casteljau rule for linear interpolation:

    - +

    Where d is the total length of the line segment from e1 to e2. So how long do we make that? There are again all kinds of approaches we can take, and a simple-but-effective one is to set the length of that segment to "one third the length of the baseline". This forces e1 and e2 to always be the "linear curve" distance apart, which means if we place our three points on a line, it will actually look like a line. Nice! The last thing we'll need to do is make sure to flip the sign of d depending on which side of the baseline our B is located, so we don't up creating a funky curve with a loop in it. To do this, we can use the atan2 function:

    - +

    This angle φ will be between 0 and π if B is "above" the baseline (rotating all three points so that the start is on the left and the end is the right), so we can use a relatively straight forward check to make sure we're using the correct sign for our value d:

    - +

    The result of this approach looks as follows:

    @@ -1800,9 +1800,9 @@ for (coordinate, index) in LUT:

    Molding a curve

    Armed with knowledge of the "ABC" relation, point-on-curve projection, and guestimating reasonable looking helper values for cubic curve construction, we can finally cover curve molding: updating a curve's shape interactively, by dragging points on the curve around.

    For quadratic curve, this is a really simple trick: we project our cursor onto the curve, which gives us a t value and initial B coordinate. We don't even need the latter: with our t value and "whever the cursor is" as target B, we can compute the associated C:

    - +

    And then the associated A:

    - +

    And we're done, because that's our new quadratic control point!

    @@ -1847,25 +1847,25 @@ for (coordinate, index) in LUT:

    Revisiting the matrix representation

    Rewriting Bézier functions to matrix form is fairly easy, if you first expand the function, and then arrange them into a multiple line form, where each line corresponds to a power of t, and each column is for a specific coefficient. First, we expand the function:

    - +

    And then we (trivially) rearrange the terms across multiple lines:

    - +

    This rearrangement has "factors of t" at each row (the first row is t⁰, i.e. "1", the second row is t¹, i.e. "t", the third row is t²) and "coefficient" at each column (the first column is all terms involving "a", the second all terms involving "b", the third all terms involving "c").

    With that arrangement, we can easily decompose this as a matrix multiplication:

    - +

    We can do the same for the cubic curve, of course. We know the base function for cubics:

    - +

    So we write out the expansion and rearrange:

    - +

    Which we can then decompose:

    - +

    And, of course, we can do this for quartic curves too (skipping the expansion step):

    - +

    And so and on so on. Now, let's see how to use these T, M, and C, to do some curve fitting.

    Let's get started: we're going to assume we picked the right order curve: for n points we're fitting an n-1th order curve, so we "start" with a vector P that represents the coordinates we already know, and for which we want to do curve fitting:

    - +

    Next, we need to figure out appropriate t values for each point in the curve, because we need something that lets us tie "the actual coordinate" to "some point on the curve". There's a fair number of different ways to do this (and a large part of optimizing "the perfect fit" is about picking appropriate t values), but in this case let's look at two "obvious" choices:

    1. equally spaced t values, and
    2. @@ -1874,27 +1874,27 @@ for (coordinate, index) in LUT:

      The first one is really simple: if we have n points, then we'll just assign each point i a t value of (i-1)/(n-1). So if we have four points, the first point will have t=(1-1)/(4-1)=0/3, the second point will have t=(2-1)/(4-1)=1/3, the third point will have t=2/3, and the last point will be t=1. We're just straight up spacing the t values to match the number of points we have.

      The second one is a little more interesting: since we're doing polynomial regression, we might as well exploit the fact that our base coordinates just constitute a collection of line segments. At the first point, we're fixing t=0, and the last point, we want t=1, and anywhere in between we're simply going to say that t is equal to the distance along the polygon, scaled to the [0,1] domain.

      To get these values, we first compute the general "distance along the polygon" matrix:

      - +

      Where length() is literally just that: the length of the line segment between the point we're looking at, and the previous point. This isn't quite enough, of course: we still need to make sure that all the values between i=1 and i=n fall in the [0,1] interval, so we need to scale all values down by whatever the total length of the polygon is:

      - +

      And now we can move on to the actual "curve fitting" part: what we want is a function that lets us compute "ideal" control point values such that if we build a Bézier curve with them, that curve passes through all our original points. Or, failing that, have an overall error distance that is as close to zero as we can get it. So, let's write out what the error distance looks like.

      As mentioned before, this function is really just "the distance between the actual coordinate, and the coordinate that the curve evaluates to for the associated t value", which we'll square to get rid of any pesky negative signs:

      - +

      Since this function only deals with individual coordinates, we'll need to sum over all coordinates in order to get the full error function. So, we literally just do that; the total error function is simply the sum of all these individual errors:

      - +

      And here's the trick that justifies using matrices: while we can work with individual values using calculus, with matrices we can compute as many values as we make our matrices big, all at the "same time", We can replace the individual terms pi with the full P coordinate matrix, and we can replace Bézier(si) with the matrix representation T x M x C we talked about before, which gives us:

      - +

      In which we can replace the rather cumbersome "squaring" operation with a more conventional matrix equivalent:

      - +

      Here, the letter T is used instead of the number 2, to represent the matrix transpose; each row in the original matrix becomes a column in the transposed matrix instead (row one becomes column one, row two becomes column two, and so on).

      This leaves one problem: T isn't actually the matrix we want: we don't want symbolic t values, we want the actual numerical values that we computed for S, so we need to form a new matrix, which we'll call 𝕋, that makes use of those, and then use that 𝕋 instead of T in our error function:

      - +

      Which, because of the first and last values in S, means:

      - +

      Now we can properly write out the error function as matrix operations:

      - +

      So, we have our error function: we now need to figure out the expression for where that function has minimal value, e.g. where the error between the true coordinates and the coordinates generated by the curve fitting is smallest. Like in standard calculus, this requires taking the derivative, and determining where that derivative is zero:

      - +

      Where did this derivative come from?

      @@ -1904,7 +1904,7 @@ for (coordinate, index) in LUT:

      Now, given the above derivative, we can rearrange the terms (following the rules of matrix algebra) so that we end up with an expression for C:

      - +

      Here, the "to the power negative one" is the notation for the matrix inverse. But that's all we have to do: we're done. Starting with P and inventing some t values based on the polygon the coordinates in P define, we can compute the corresponding Bézier coordinates C that specify a curve that goes through our points. Or, if it can't go through them exactly, as near as possible.

      So before we try that out, how much code is involved in implementing this? Honestly, that answer depends on how much you're going to be writing yourself. If you already have a matrix maths library available, then really not that much code at all. On the other hand, if you are writing this from scratch, you're going to have to write some utility functions for doing your matrix work for you, so it's really anywhere from 50 lines of code to maybe 200 lines of code. Not a bad price to pay for being able to fit curves to prespecified coordinates.

      So let's try it out! The following graphic lets you place points, and will start computing exact-fit curves once you've placed at least three. You can click for more points, and the code will simply try to compute an exact fit using a Bézier curve of the appropriate order. Four points? Cubic Bézier. Five points? Quartic. And so on. Of course, this does break down at some point: depending on where you place your points, it might become mighty hard for the fitter to find an exact fit, and things might actually start looking horribly off once there's enough points for compound floating point rounding errors to start making a difference (which is around 10~11 points).

      @@ -1935,7 +1935,7 @@ for (coordinate, index) in LUT:

      Now, it may look like Catmull-Rom curves are very different from Bézier curves, because these curves can get very long indeed, but what looks like a single Catmull-Rom curve is actually a spline: a single curve built up of lots of identically-computed pieces, similar to if you just took a whole bunch of Bézier curves, placed them end to end, and lined up their control points so that things look like a single curve. For a Catmull-Rom curve, each "piece" between two points is defined by the point's coordinates, and the tangent for those points, the latter of which can trivially be derived from knowing the previous and next point:

      - +

      One downside of this is that—as you may have noticed from the graphic—the first and last point of the overall curve don't actually join up with the rest of the curve: they don't have a previous/next point respectively, and so there is no way to calculate what their tangent should be. Which also makes it rather tricky to fit a Camull-Rom curve to three points like we were able to do for Bézier curves. More on that in the next section.

      In fact, before we move on, let's look at how to actually draw the basic form of these curves (I say basic, because there are a number of variations that make things considerable more complex):

      tension = some value greater than 0, defaulting to 1
      @@ -1964,77 +1964,77 @@ for p = 1 to points.length-3 (inclusive):
       
    3. A Catmull-Rom curve is defined by a start point, a tangent that for that starting point, an end point, and a tangent for that end point, plus a characteristic matrix that we can multiple by the point vector to get on-curve coordinates.
    4. Those are very similar, so let's see exactly how similar they are. We've already see the matrix form for Bézier curves, so how different is the matrix form for Catmull-Rom curves?:

      - +

      That's pretty dang similar. So the question is: how can we convert that expression with Catmull-Rom matrix and vector into an expression of the Bézier matrix and vector? The short answer is of course "by using linear algebra", but the longer answer is the rest of this section, and involves some maths that you may not even care for: if you just want to know the (incredibly simple) conversions between the two curve forms, feel free to skip to the end of the following explanation, but if you want to how we can get one from the other... let's get mathing!

      Deriving the conversion formulae

      In order to convert between Catmull-Rom curves and Bézier curves, we need to know two things. Firstly, how to express the Catmull-Rom curve using a "set of four coordinates", rather than a mix of coordinates and tangents, and secondly, how to convert those Catmull-Rom coordinates to and from Bézier form.

      We start with the first part, to figure out how we can go from Catmull-Rom V coordinates to Bézier P coordinates, by applying "some matrix T". We don't know what that T is yet, but we'll get to that:

      - +

      So, this mapping says that in order to map a Catmull-Rom "point + tangent" vector to something based on an "all coordinates" vector, we need to determine the mapping matrix such that applying T yields P2 as start point, P3 as end point, and two tangents based on the lines between P1 and P3, and P2 nd P4, respectively.

      Computing T is really more "arranging the numbers":

      - +

      Thus:

      - +

      However, we're not quite done, because Catmull-Rom curves have that "tension" parameter, written as τ (a lowercase"tau"), which is a scaling factor for the tangent vectors: the bigger the tension, the smaller the tangents, and the smaller the tension, the bigger the tangents. As such, the tension factor goes in the denominator for the tangents, and before we continue, let's add that tension factor into both our coordinate vector representation, and mapping matrix T:

      - +

      With the mapping matrix properly done, let's rewrite the "point + tangent" Catmull-Rom matrix form to a matrix form in terms of four coordinates, and see what we end up with:

      - +

      Replace point/tangent vector with the expression for all-coordinates:

      - +

      and merge the matrices:

      - +

      This looks a lot like the Bézier matrix form, which as we saw in the chapter on Bézier curves, should look like this:

      - +

      So, if we want to express a Catmull-Rom curve using a Bézier curve, we'll need to turn this Catmull-Rom bit:

      - +

      Into something that looks like this:

      - +

      And the way we do that is with a fairly straight forward bit of matrix rewriting. We start with the equality we need to ensure:

      - +

      Then we remove the coordinate vector from both sides without affecting the equality:

      - +

      Then we can "get rid of" the Bézier matrix on the right by left-multiply both with the inverse of the Bézier matrix:

      - +

      A matrix times its inverse is the matrix equivalent of 1, and because "something times 1" is the same as "something", so we can just outright remove any matrix/inverse pair:

      - +

      And now we're basically done. We just multiply those two matrices and we know what V is:

      - +

      We now have the final piece of our function puzzle. Let's run through each step.

      1. Start with the Catmull-Rom function:
      - +
      1. rewrite to pure coordinate form:
      - +
      1. rewrite for "normal" coordinate vector:
      - +
      1. merge the inner matrices:
      - +
      1. rewrite for Bézier matrix form:
      - +
      1. and transform the coordinates so we have a "pure" Bézier expression:
      - +

      And we're done: we finally know how to convert these two curves!

      If we have a Catmull-Rom curve defined by four coordinates P1 through P4, then we can draw that curve using a Bézier curve that has the vector:

      - +

      Similarly, if we have a Bézier curve defined by four coordinates P1 through P4, we can draw that using a standard tension Catmull-Rom curve with the following coordinate values:

      - +

      Or, if your API allows you to specify Catmull-Rom curves using plain coordinates:

      - +
      @@ -2067,9 +2067,9 @@ for p = 1 to points.length-3 (inclusive):

      Dragging the control points around only affects the curve segments that the control point belongs to, and moving an on-curve point leaves the control points where they are, which is not the most useful for practical modelling purposes. So, let's add in the logic we need to make things a little better. We'll start by linking up control points by ensuring that the "incoming" derivative at an on-curve point is the same as it's "outgoing" derivative:

      - +

      We can effect this quite easily, because we know that the vector from a curve's last control point to its last on-curve point is equal to the derivative vector. If we want to ensure that the first control point of the next curve matches that, all we have to do is mirror that last control point through the last on-curve point. And mirroring any point A through any point B is really simple:

      - +

      So let's implement that and see what it gets us. The following two graphics show a quadratic and a cubic poly-Bézier curve again, but this time moving the control points around moves others, too. However, you might see something unexpected going on for quadratic curves...

      @@ -2129,16 +2129,16 @@ for p = 1 to points.length-3 (inclusive):

      "What do you mean, you can't? Prove it."

      First off, when I say "you can't," what I really mean is "you can't offset a Bézier curve with another Bézier curve", not even by using a really high order curve. You can find the function that describes the offset curve, but it won't be a polynomial, and as such it cannot be represented as a Bézier curve, which has to be a polynomial. Let's look at why this is:

      From a mathematical point of view, an offset curve O(t) is a curve such that, given our original curve B(t), any point on O(t) is a fixed distance d away from coordinate B(t). So let's math that:

      - +

      However, we're working in 2D, and d is a single value, so we want to turn it into a vector. If we want a point distance d "away" from the curve B(t) then what we really mean is that we want a point at d times the "normal vector" from point B(t), where the "normal" is a vector that runs perpendicular ("at a right angle") to the tangent at B(t). Easy enough:

      - +

      Now this still isn't very useful unless we know what the formula for N(t) is, so let's find out. N(t) runs perpendicular to the original curve tangent, and we know that the tangent is simply B'(t), so we could just rotate that 90 degrees and be done with it. However, we need to ensure that N(t) has the same magnitude for every t, or the offset curve won't be at a uniform distance, thus not being an offset curve at all. The easiest way to guarantee this is to make sure N(t) always has length 1, which we can achieve by dividing B'(t) by its magnitude:

      - +

      Determining the length requires computing an arc length, and this is where things get Tricky with a capital T. First off, to compute arc length from some start a to end b, we must use the formula we saw earlier. Noting that "length" is usually denoted with double vertical bars:

      - +

      So if we want the length of the tangent, we plug in B'(t), with t = 0 as start and t = 1 as end:

      - +

      And that's where things go wrong. It doesn't even really matter what the second derivative for B(t) is, that square root is screwing everything up, because it turns our nice polynomials into things that are no longer polynomials.

      There is a small class of polynomials where the square root is also a polynomial, but they're utterly useless to us: any polynomial with unweighted binomial coefficients has a square root that is also a polynomial. Now, you might think that Bézier curves are just fine because they do, but they don't; remember that only the base function has binomial coefficients. That's before we factor in our coordinates, which turn it into a non-binomial polygon. The only way to make sure the functions stay binomial is to make all our coordinates have the same value. And that's not a curve, that's a point. We can already create offset curves for points, we call them circles, and they have much simpler functions than Bézier curves.

      So, since the tangent length isn't a polynomial, the normalised tangent won't be a polynomial either, which means N(t) won't be a polynomial, which means that d times N(t) won't be a polynomial, which means that, ultimately, O(t) won't be a polynomial, which means that even if we can determine the function for O(t) just fine (and that's far from trivial!), it simply cannot be represented as a Bézier curve.

      @@ -2218,25 +2218,25 @@ for p = 1 to points.length-3 (inclusive):

      As you can see, things go horribly wrong quite quickly; even trying to approximate a quarter circle using a quadratic curve is a bad idea. An eighth of a turns might look okay, but how okay is okay? Let's apply some maths and find out. What we're interested in is how far off our on-curve coordinates are with respect to a circular arc, given a specific start and end angle. We'll be looking at how much space there is between the circular arc, and the quadratic curve's midpoint.

      We start out with our start and end point, and for convenience we will place them on a unit circle (a circle around 0,0 with radius 1), at some angle φ:

      - +

      What we want to find is the intersection of the tangents, so we want a point C such that:

      - +

      i.e. we want a point that lies on the vertical line through S (at some distance a from S) and also lies on the tangent line through E (at some distance b from E). Solving this gives us:

      - +

      First we solve for b:

      - +

      which yields:

      - +

      which we can then substitute in the expression for a:

      - +

      A quick check shows that plugging these values for a and b into the expressions for Cx and Cy give the same x/y coordinates for both "a away from A" and "b away from B", so let's continue: now that we know the coordinate values for C, we know where our on-curve point T for t=0.5 (or angle φ/2) is, because we can just evaluate the Bézier polynomial, and we know where the circle arc's actual point P is for angle φ/2:

      - +

      We compute T, observing that if t=0.5, the polynomial values (1-t)², 2(1-t)t, and t² are 0.25, 0.5, and 0.25 respectively:

      - +

      Which, worked out for the x and y components, gives:

      - +

      And the distance between these two is the standard Euclidean distance:

      - +

      So, what does this distance function look like when we plot it for a number of ranges for the angle φ, such as a half circle, quarter circle and eighth circle?

      @@ -2253,7 +2253,7 @@ for p = 1 to points.length-3 (inclusive):

      We now see why the eighth circle arc looks decent, but the quarter circle arc doesn't: an error of roughly 0.06 at t=0.5 means we're 6% off the mark... we will already be off by one pixel on a circle with pixel radius 17. Any decent sized quarter circle arc, say with radius 100px, will be way off if approximated by a quadratic curve! For the eighth circle arc, however, the error is only roughly 0.003, or 0.3%, which explains why it looks so close to the actual eighth circle arc. In fact, if we want a truly tiny error, like 0.001, we'll have to contend with an angle of (rounded) 0.593667, which equates to roughly 34 degrees. We'd need 11 quadratic curves to form a full circle with that precision! (technically, 10 and ten seventeenth, but we can't do partial curves, so we have to round up). That's a whole lot of curves just to get a shape that can be drawn using a simple function!

      In fact, let's flip the function around, so that if we plug in the precision error, labelled ε, we get back the maximum angle for that precision:

      - +

      And frankly, things are starting to look a bit ridiculous at this point, we're doing way more maths than we've ever done, but thankfully this is as far as we need the maths to take us: If we plug in the precisions 0.1, 0.01, 0.001 and 0.0001 we get the radians values 1.748, 1.038, 0.594 and 0.3356; in degrees, that means we can cover roughly 100 degrees (requiring four curves), 59.5 degrees (requiring six curves), 34 degrees (requiring 11 curves), and 19.2 degrees (requiring a whopping nineteen curves).

      The bottom line? Quadratic curves are kind of lousy if you want circular (or elliptical, which are circles that have been squashed in one dimension) curves. We can do better, even if it's just by raising the order of our curve once. So let's try the same thing for cubic curves.

      @@ -2307,7 +2307,7 @@ for p = 1 to points.length-3 (inclusive):

      The distance from our guessed point to the start point is exactly the same as the projection distance we looked at earlier. Using t=0.5 as our point "B" in the "A,B,C" projection, then we know the length of the line segment {C,A}, since it's d1 = {A,B} + d2 = {B,C}:

      So that just leaves us to find the distance from t=0.5 to the baseline for an arbitrary angle φ, which is the distance from the centre of the circle to our t=0.5 point, minus the distance from the centre to the line that runs from start point to end point. The first is the same as the point P we found for the quadratic curve:

      - +

      And the distance from the origin to the line start/end is another application of angles, since the triangle {origin,start,C} has known angles, and two known sides. We can find the length of the line {origin,C}, which lets us trivially compute the coordinate for C:

      With the coordinate C, and knowledge of coordinate B, we can determine coordinate A, and get a vector that is identical to the vector {start,guess}:

      @@ -2423,27 +2423,27 @@ for p = 1 to points.length-3 (inclusive):

      In order to make this interpolation of curves work, the maths is necessarily more complex than the maths for Bézier curves, so let's have a look at how things work.

      How to compute a B-Spline curve: some maths

      Given a B-Spline of degree d and thus order k=d+1 (so a quadratic B-Spline is degree 2 and order 3, a cubic B-Spline is degree 3 and order 4, etc) and n control points P0 through Pn-1, we can compute a point on the curve for some value t in the interval [0,1] (where 0 is the start of the curve, and 1 the end, just like for Bézier curves), by evaluating the following function:

      - +

      Which, honestly, doesn't tell us all that much. All we can see is that a point on a B-Spline curve is defined as "a mix of all the control points, weighted somehow", where the weighting is achieved through the N(...) function, subscripted with an obvious parameter i, which comes from our summation, and some magical parameter k. So we need to know two things: 1. what does N(t) do, and 2. what is that k? Let's cover both, in reverse order.

      The parameter k represents the "knot interval" over which a section of curve is defined. As we learned earlier, a B-Spline curve is itself an interpoliation of curves, and we can treat each transition where a control point starts or stops influencing the total curvature as a "knot on the curve". Doing so for a degree d B-Spline with n control point gives us d + n + 1 knots, defining d + n intervals along the curve, and it is these intervals that the above k subscript to the N() function applies to.

      Then the N() function itself. What does it look like?

      - +

      So this is where we see the interpolation: N(t) for an (i,k) pair (that is, for a step in the above summation, on a specific knot interval) is a mix between N(t) for (i,k-1) and N(t) for (i+1,k-1), so we see that this is a recursive iteration where i goes up, and k goes down, so it seem reasonable to expect that this recursion has to stop at some point; obviously, it does, and specifically it does so for the following i/k values:

      - +

      And this function finally has a straight up evaluation: if a t value lies within a knot-specific interval once we reach a k=1 value, it "counts", otherwise it doesn't. We did cheat a little, though, because for all these values we need to scale our t value first, so that it lies in the interval bounded by knots[d] and knots[n], which are the start point and end point where curvature is controlled by exactly order control points. For instance, for degree 3 (=order 4) and 7 control points, with knot vector [1,2,3,4,5,6,7,8,9,10,11], we map t from [the interval 0,1] to the interval [4,8], and then use that value in the functions above, instead.

      Can we simplify that?

      We can, yes.

      People far smarter than us have looked at this work, and two in particular — Maurice Cox and Carl de Boor — came to a mathematically pleasing solution: to compute a point P(t), we can compute this point by evaluating d(t) on a curve section between knots i and i+1:

      - +

      This is another recursive function, with k values decreasing from the curve order to 1, and the value α (alpha) defined by:

      - +

      That looks complicated, but it's not. Computing alpha is just a fraction involving known, plain numbers. And, once we have our alpha value, we also have (1-alpha) because it's a trivial subtraction. Computing the d() function is thus mostly a matter of computing pretty simple arithmetical statements, with some caching of results so we can refer to them as we recurve. While the recursion might see computationally expensive, the total algorithm is cheap, as each step only involves very simple maths.

      Of course, the recursion does need a stop condition:

      - +

      So, we actually see two stopping conditions: either i becomes 0, in which case d() is zero, or k becomes zero, in which case we get the same "either 1 or 0" that we saw in the N() function above.

      Thanks to Cox and de Boor, we can compute points on a B-Spline pretty easily using the same kind of linear interpolation we saw in de Casteljau's algorithm. For instance, if we write out d() for i=3 and k=3, we get the following recursion diagram:

      - +

      That is, we compute d(3,3) as a mixture of d(2,3) and d(2,2), where those two are themselves a mixture of d(1,3) and d(1,2), and d(1,2) and d(1,1), respectively, which are themselves a mixture of etc. etc. We simply keep expanding our terms until we reach the stop conditions, and then sum everything back up. It's really quite elegant.

      One thing we need to keep in mind is that we're working with a spline that is constrained by its control points, so even though the d(..., k) values are zero or one at the lowest level, they are really "zero or one, times their respective control point", so in the next section you'll see the algorithm for running through the computation in a way that starts with a copy of the control point vector and then works its way up to that single point, rather than first starting "on the left", working our way "to the right" and then summing back up "to the left". We can just start on the right and work our way left immediately.

      Running the computation

      diff --git a/docs/zh-CN/index.html b/docs/zh-CN/index.html index 4d56d012..b1071cd2 100644 --- a/docs/zh-CN/index.html +++ b/docs/zh-CN/index.html @@ -282,7 +282,7 @@

      操作点的移动,看看曲线的变化,可能让你感受到了贝塞尔曲线是如何表现的。但贝塞尔曲线究竟什么呢?有两种方式来解释贝塞尔曲线,并且可以证明它们完全相等,但是其中一种用到了复杂的数学,另外一种比较简单。所以...我们先从简单的开始吧:

      贝塞尔曲线是线性插值的结果。这听起来很复杂,但你在很小的时候就做过线性插值:当你指向两个物体中的另外一个物体时,你就用到了线性插值。它就是很简单的“选出两点之间的一个点”。

      如果我们知道两点之间的距离,并想找出离第一个点20%间距的一个新的点(也就是离第二个点80%的间距),我们可以通过简单的计算来得到:

      - +

      让我们来通过实际操作看一下:下面的图形都是可交互的,因此你可以通过上下键来增加或减少插值距离,来观察图形的变化。我们从三个点构成的两条线段开始。通过对各条线段进行线性插值得到两个点,对点之间的线段再进行线性插值,产生一个新的点。最终这些点——所有的点都可以通过选取不同的距离插值产生——构成了贝塞尔曲线 : @@ -301,14 +301,14 @@

      贝塞尔曲线的数学原理

      贝塞尔曲线是“参数”方程的一种形式。从数学上讲,参数方程作弊了:“方程”实际上是一个从输入到唯一输出的、良好定义的映射关系。几个输入进来,一个输出返回。改变输入变量,还是只有一个输出值。参数方程在这里作弊了。它们基本上干了这么件事,“好吧,我们想要更多的输出值,所以我们用了多个方程”。举个例子:假如我们有一个方程,通过一些计算,将假设为x的一些值映射到另外的值:

      - +

      记号f(x)是表示函数的标准方式(为了方便起见,如果只有一个的话,我们称函数为f),函数的输出根据一个变量(本例中是x)变化。改变xf(x)的输出值也会变。

      到目前没什么问题。现在,让我们来看一下参数方程,以及它们是怎么作弊的。我们取以下两个方程:

      - +

      这俩方程没什么让人印象深刻的,只不过是正弦函数和余弦函数,但正如你所见,输入变量有两个不同的名字。如果我们改变了a的值,f(b)的输出不会有变化,因为这个方程没有用到a。参数方程通过改变这点来作弊。在参数方程中,所有不同的方程共用一个变量,如下所示:

      - +

      多个方程,但只有一个变量。如果我们改变了t的值,fa(t)fb(t)的输出都会发生变化。你可能会好奇这有什么用,答案其实很简单:对于参数曲线,如果我们用常用的标记来替代fa(t)fb(t),看起来就有些明朗了:

      - +

      好了,通过一些神秘的t值将x/y坐标系联系起来。

      所以,参数曲线不像一般函数那样,通过x坐标来定义y坐标,而是用一个“控制”变量将它们连接起来。如果改变t的值,每次变化时我们都能得到两个值,这可以作为图形中的(x,y)坐标。比如上面的方程组,生成位于一个圆上的点:我们可以使t在正负极值间变化,得到的输出(x,y)都会位于一个以原点(0,0)为中心且半径为1的圆上。如果我们画出t从0到5时的值,将得到如下图像:

      @@ -322,17 +322,17 @@

      贝塞尔曲线是(一种)参数方程,并在它的多个维度上使用相同的基本方程。在上述的例子中x值和y值使用了不同的方程,与此不同的是,贝塞尔曲线的xy都用了“二项多项式”。那什么是二项多项式呢?

      你可能记得高中所学的多项式,看起来像这样:

      - +

      如果它的最高次项是就称为“三次”多项式,如果最高次项是,称为“二次”多项式,如果只含有x的项,它就是一条线(不过不含任何x的项它就不是一个多项式!)

      贝塞尔曲线不是x的多项式,它是t的多项式,t的值被限制在0和1之间,并且含有ab等参数。它采用了二次项的形式,听起来很神奇但实际上就是混合不同值的简单描述:

      - +

      我明白你在想什么:这看起来并不简单,但如果我们拿掉t并让系数乘以1,事情就会立马简单很多,看看这些二次项:

      - +

      需要注意的是,2与1+1相同,3相当于2+1或1+2,6相当于3+3...如你所见,每次我们增加一个维度,只要简单地将头尾置为1,中间的操作都是“将上面的两个数字相加”。现在就能很容易地记住了。

      还有一个简单的办法可以弄清参数项怎么工作的:如果我们将(1-t)重命名为a,将t重命名为b,暂时把权重删掉,可以得到这个:

      - +

      基本上它就是“每个ab结合项”的和,在每个加号后面逐步的将a换成b。因此这也很简单。现在你已经知道了二次多项式,为了叙述的完整性,我将给出一般方程:

      - +

      这就是贝塞尔曲线完整的描述。在这个函数中的Σ表示了这是一系列的加法(用Σ下面的变量,从...=<值>开始,直到Σ上面的数字结束)。

      @@ -462,9 +462,9 @@ function Bezier(3,t,w[]):

      Controlling Bézier curvatures, part 2: Rational Béziers

      We can further control Bézier curves by "rationalising" them: that is, adding a "ratio" value in addition to the weight value discussed in the previous section, thereby gaining control over "how strongly" each coordinate influences the curve.

      Adding these ratio values to the regular Bézier curve function is fairly easy. Where the regular function is the following:

      - +

      The function for rational Bézier curves has two more terms:

      - +

      In this, the first new term represents an additional weight for each coordinate. For example, if our ratio values are [1, 0.5, 0.5, 1] then ratio0 = 1, ratio1 = 0.5, and so on, and is effectively identical as if we were just using different weight. So far, nothing too special.

      However, the second new term is what makes the difference: every point on the curve isn't just a "double weighted" point, it is a fraction of the "doubly weighted" value we compute by introducing that ratio. When computing points on the curve, we compute the "normal" Bézier value and then divide that by the Bézier value for the curve that only uses ratios, not weights.

      This does something unexpected: it turns our polynomial into something that isn't a polynomial anymore. It is now a kind of curve that is a super class of the polynomials, and can do some really cool things that Bézier curves can't do "on their own", such as perfectly describing circles (which we'll see in a later section is literally impossible using standard Bézier curves).

      @@ -520,9 +520,9 @@ function RationalBezier(3,t,w[],r[]):

      贝塞尔区间[0,1]

      既然我们知道了贝塞尔曲线背后的数学原理,你可能会注意到一件奇怪的事:它们都是从t=0t=1。为什么是这个特殊区间?

      这一切都与我们如何从曲线的“起点”变化到曲线“终点”有关。如果有一个值是另外两个值的混合,一般方程如下:

      - +

      很显然,起始值需要a=1, b=0,混合值就为100%的value 1和0%的value 2。终点值需要a=0, b=1,则混合值是0%的value 1和100%的value 2。另外,我们不想让“a”和“b”是互相独立的:如果它们是互相独立的话,我们可以任意选出自己喜欢的值,并得到混合值,比如说100%的value1和100%的value2。原则上这是可以的,但是对于贝塞尔曲线来说,我们通常想要的是起始值和终点值之间的混合值,所以要确保我们不会设置一些“a”和"b"而导致混合值超过100%。这很简单:

      - +

      用这个式子我们可以保证相加的值永远不会超过100%。通过将a限制在区间[0,1],我们将会一直处于这两个值之间(包括这两个端点),并且相加为100%。

      但是...如果我们没有假定只使用0到1之间的数,而是用一些区间外的值呢,事情会变得很糟糕吗?好吧...不全是,我们接下来看看。

      对于贝塞尔曲线的例子,扩展区间只会使我们的曲线“保持延伸”。贝塞尔曲线是多项式曲线上简单的片段,如果我们选一个更大的区间,会看到曲线更多部分。它们看起来是什么样的呢?

      @@ -765,30 +765,30 @@ function drawCurve(points[], t):

      One interesting property of Bézier curves is that an nth order curve can always be perfectly represented by an (n+1)th order curve, by giving the higher-order curve specific control points.

      If we have a curve with three points, then we can create a curve with four points that exactly reproduces the original curve. First, we give it the same start and end points, and for its two control points we pick "1/3rd start + 2/3rd control" and "2/3rd control + 1/3rd end". Now we have exactly the same curve as before, except represented as a cubic curve rather than a quadratic curve.

      The general rule for raising an nth order curve to an (n+1)th order curve is as follows (observing that the start and end weights are the same as the start and end weights for the old curve):

      - +

      However, this rule also has as direct consequence that you cannot generally safely lower a curve from nth order to (n-1)th order, because the control points cannot be "pulled apart" cleanly. We can try to, but the resulting curve will not be identical to the original, and may in fact look completely different.

      However, there is a surprisingly good way to ensure that a lower order curve looks "as close as reasonably possible" to the original curve: we can optimise the "least-squares distance" between the original curve and the lower order curve, in a single operation (also explained over on Sirver's Castle). However, to use it, we'll need to do some calculus work and then switch over to linear algebra. As mentioned in the section on matrix representations, some things can be done much more easily with matrices than with calculus functions, and this is one of those things. So... let's go!

      We start by taking the standard Bézier function, and condensing it a little:

      - +

      Then, we apply one of those silly (actually, super useful) calculus tricks: since our t value is always between zero and one (inclusive), we know that (1-t) plus t always sums to 1. As such, we can express any value as a sum of t and 1-t:

      - +

      So, with that seemingly trivial observation, we rewrite that Bézier function by splitting it up into a sum of a (1-t) and t component:

      - +

      So far so good. Now, to see why we did this, let's write out the (1-t) and t parts, and see what that gives us. I promise, it's about to make sense. We start with (1-t):

      - +

      So by using this seemingly silly trick, we can suddenly express part of our nth order Bézier function in terms of an (n+1)th order Bézier function. And that sounds a lot like raising the curve order! Of course we need to be able to repeat that trick for the t part, but that's not a problem:

      - +

      So, with both of those changed from an order n expression to an order (n+1) expression, we can put them back together again. Now, where the order n function had a summation from 0 to n, the order n+1 function uses a summation from 0 to n+1, but this shouldn't be a problem as long as we can add some new terms that "contribute nothing". In the next section on derivatives, there is a discussion about why "higher terms than there is a binomial for" and "lower than zero terms" both "contribute nothing". So as long as we can add terms that have the same form as the terms we need, we can just include them in the summation, they'll sit there and do nothing, and the resulting function stays identical to the lower order curve.

      Let's do this:

      - +

      And this is where we switch over from calculus to linear algebra, and matrices: we can now express this relation between Bézier(n,t) and Bézier(n+1,t) as a very simple matrix multiplication:

      - +

      where the matrix M is an n+1 by n matrix, and looks like:

      - +

      That might look unwieldy, but it's really just a mostly-zeroes matrix, with a very simply fraction on the diagonal, and an even simpler fraction to the left of it. Multiplying a list of coordinates with this matrix means we can plug the resulting transformed coordinates into the one-order-higher function and get an identical looking curve.

      Not too bad!

      Equally interesting, though, is that with this matrix operation established, we can now use an incredibly powerful and ridiculously simple way to find out a "best fit" way to reverse the operation, called the normal equation. What it does is minimize the sum of the square differences between one set of values and another set of values. Specifically, if we can express that as some function A x = b, we can use it. And as it so happens, that's exactly what we're dealing with, so:

      - +

      The steps taken here are:

      1. We have a function in a form that the normal equation can be used with, so
      2. @@ -853,20 +853,20 @@ function drawCurve(points[], t):

        Tangents and normals

        If you want to move objects along a curve, or "away from" a curve, the two vectors you're most interested in are the tangent vector and normal vector for curve points. These are actually really easy to find. For moving and orienting along a curve, we use the tangent, which indicates the direction of travel at specific points, and is literally just the first derivative of our curve:

        - +

        This gives us the directional vector we want. We can normalize it to give us uniform directional vectors (having a length of 1.0) at each point, and then do whatever it is we want to do based on those directions:

        - - + +

        The tangent is very useful for moving along a line, but what if we want to move away from the curve instead, perpendicular to the curve at some point t? In that case we want the normal vector. This vector runs at a right angle to the direction of the curve, and is typically of length 1.0, so all we have to do is rotate the normalized directional vector and we're done:

        - +

        Rotating coordinates is actually very easy, if you know the rule for it. You might find it explained as "applying a rotation matrix, which is what we'll look at here, too. Essentially, the idea is to take the circles over which we can rotate, and simply "sliding the coordinates" over these circles by the desired angle. If we want a quarter circle turn, we take the coordinate, slide it along the cirle by a quarter turn, and done.

        To turn any point (x,y) into a rotated point (x',y') (over 0,0) by some angle φ, we apply this nice and easy computation:

        - +

        Which is the "long" version of the following matrix transformation:

        - +

        And that's all we need to rotate any coordinate. Note that for quarter, half, and three-quarter turns these functions become even easier, since sin and cos for these angles are, respectively: 0 and 1, -1 and 0, and 0 and -1.

        But why does this work? Why this matrix multiplication? Wikipedia (technically, Thomas Herter and Klaus Lott) tells us that a rotation matrix can be treated as a sequence of three (elementary) shear operations. When we combine this into a single matrix operation (because all matrix multiplications can be collapsed), we get the matrix that you see above. DataGenetics have an excellent article about this very thing: it's really quite cool, and I strongly recommend taking a quick break from this primer to read that article.

        @@ -1024,27 +1024,27 @@ treated as a sequence of three (elementary) shear operations. When we combine th

        Now that we understand (well, superficially anyway) the component functions, we can find the extremities of our Bézier curve by finding maxima and minima on the component functions, by solving the equation B'(t) = 0. We've already seen that the derivative of a Bézier curve is a simpler Bézier curve, but how do we solve the equality? Fairly easily, actually, until our derivatives are 4th order or higher... then things get really hard. But let's start simple:

        Quadratic curves: linear derivatives.

        The derivative of a quadratic Bézier curve is a linear Bézier curve, interpolating between just two terms, which means finding the solution for "where is this line 0" is effectively trivial by rewriting it to a function of t and solving. First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

        - +

        And then we turn this into our solution for t using basic arithmetics:

        - +

        Done.

        Although with the caveat that if b-a is zero, there is no solution and we probably shouldn't try to perform that division.

        Cubic curves: the quadratic formula.

        The derivative of a cubic Bézier curve is a quadratic Bézier curve, and finding the roots for a quadratic polynomial means we can apply the Quadratic formula. If you've seen it before, you'll remember it, and if you haven't, it looks like this:

        - +

        So, if we can rewrite the Bézier component function as a plain polynomial, we're done: we just plug in the values into the quadratic formula, check if that square root is negative or not (if it is, there are no roots) and then just compute the two values that come out (because of that plus/minus sign we get two). Any value between 0 and 1 is a root that matters for Bézier curves, anything below or above that is irrelevant (because Bézier curves are only defined over the interval [0,1]). So, how do we convert?

        First we turn our cubic Bézier function into a quadratic one, by following the rule mentioned at the end of the derivatives section:

        - +

        And then, using these v values, we can find out what our a, b, and c should be:

        - +

        This gives us three coefficients {a, b, c} that are expressed in terms of v values, where the v values are expressions of our original coordinate values, so we can do some substitution to get:

        - +

        Easy-peasy. We can now almost trivially find the roots by plugging those values into the quadratic formula.

        And as a cubic curve, there is also a meaningful second derivative, which we can compute by simple taking the derivative of the derivative.

        Quartic curves: Cardano's algorithm.

        We haven't really looked at them before now, but the next step up would be a Quartic curve, a fourth degree Bézier curve. As expected, these have a derivative that is a cubic function, and now things get much harder. Cubic functions don't have a "simple" rule to find their roots, like the quadratic formula, and instead require quite a bit of rewriting to a form that we can even start to try to solve.

        Back in the 16th century, before Bézier curves were a thing, and even before calculus itself was a thing, Gerolamo Cardano figured out that even if the general cubic function is really hard to solve, it can be rewritten to a form for which finding the roots is "easier" (even if not "easy"):

        - +

        We can see that the easier formula only has two constants, rather than four, and only two expressions involving t, rather than three: this makes things considerably easier to solve because it lets us use regular calculus to find the values that satisfy the equasion.

        Now, there is one small hitch: as a cubic function, the solutions may be complex numbers rather than plain numbers... And Cardona realised this, centuries befor complex numbers were a well-understood and established part of number theory. His interpretation of them was "these numbers are impossible but that's okay because they disappear again in later steps", allowing him to not think about them too much, but we have it even easier: as we're trying to find the roots for display purposes, we don't even care about complex numbers: we're going to simplify Cardano's approach just that tiny bit further by throwing away any solution that's not a plain number.

        So, how do we rewrite the hard formula into the easier formula? This is explained in detail over at Ken J. Ward's page for solving the cubic equation, so instead of showing the maths, I'm simply going to show the programming code for solving the cubic equation, with the complex roots getting totally ignored, but if you're interested you should definitely head over to Ken's page and give the procedure a read-through.

        @@ -1142,7 +1142,7 @@ function getCubicRoots(pa, pb, pc, pd) {

        That's a fancy term for saying "rather than trying to find exact answers by manipulating symbols, find approximate answers by describing the underlying process as a combination of steps, each of which can be assigned a number via symbolic manipulation". For example, trying to mathematically compute how much water fits in a completely crazy three dimensional shape is very hard, even if it got you the perfect, precise answer. A much easier approach, which would be less perfect but still entirely useful, would be to just grab a buck and start filling the shape until it was full: just count the number of buckets of water you used. And if we want a more precise answer, we can use smaller buckets.

        So that's what we're going to do here, too: we're going to treat the problem as a sequence of steps, and the smaller we can make each step, the closer we'll get to that "perfect, precise" answer. And as it turns out, there is a really nice numerical root-finding algorithm, called the Newton-Raphson root finding method (yes, after that Newton), which we can make use of. The Newton-Raphson approach consists of taking our impossible-to-solve function f(x), picking some intial value x (literally any value will do), and calculating f(x). We can think of that value as the "height" of the function at x. If that height is zero, we're done, we have found a root. If it isn't, we calculate the tangent line at f(x) and calculate at which x value its height is zero (which we've already seen is very easy). That will give us a new x and we repeat the process until we find a root.

        Mathematically, this means that for some x, at step n=1, we perform the following calculation until fy(x) is zero, so that the next t is the same as the one we already have:

        - +

        (The Wikipedia article has a decent animation for this process, so I will not add a graphic for that here)

        Now, this works well only if we can pick good starting points, and our curve is continuously differentiable and doesn't have oscillations. Glossing over the exact meaning of those terms, the curves we're dealing with conform to those constraints, so as long as we pick good starting points, this will work. So the question is: which starting points do we pick?

        As it turns out, Newton-Raphson is so blindingly fast that we could get away with just not picking: we simply run the algorithm from t=0 to t=1 at small steps (say, 1/200th) and the result will be all the roots we want. Of course, this may pose problems for high order Bézier curves: 200 steps for a 200th order Bézier curve is going to go wrong, but that's okay: there is no reason (at least, none that I know of) to ever use Bézier curves of crazy high orders. You might use a fifth order curve to get the "nicest still remotely workable" approximation of a full circle with a single Bézier curve, but that's pretty much as high as you'll ever need to go.

        @@ -1196,13 +1196,13 @@ function getCubicRoots(pa, pb, pc, pd) {

        Aligning curves

        While there are an incredible number of curves we can define by varying the x- and y-coordinates for the control points, not all curves are actually distinct. For instance, if we define a curve, and then rotate it 90 degrees, it's still the same curve, and we'll find its extremities in the same spots, just at different draw coordinates. As such, one way to make sure we're working with a "unique" curve is to "axis-align" it.

        Aligning also simplifies a curve's functions. We can translate (move) the curve so that the first point lies on (0,0), which turns our n term polynomial functions into n-1 term functions. The order stays the same, but we have less terms. Then, we can rotate the curves so that the last point always lies on the x-axis, too, making its coordinate (...,0). This further simplifies the function for the y-component to an n-2 term function. For instance, if we have a cubic curve such as this:

        - +

        Then translating it so that the first coordinate lies on (0,0), moving all x coordinates by -120, and all y coordinates by -160, gives us:

        - +

        If we then rotate the curve so that its end point lies on the x-axis, the coordinates (integer-rounded for illustrative purposes here) become:

        - +

        If we drop all the zero-terms, this gives us:

        - +

        We can see that our original curve definition has been simplified considerably. The following graphics illustrate the result of aligning our example curves to the x-axis, with the cubic case using the coordinates that were just used in the example formulae:

        @@ -1247,29 +1247,29 @@ function getCubicRoots(pa, pb, pc, pd) {

        Now that we know how to align a curve, there's one more thing we can calculate: inflection points. Imagine we have a variable size circle that we can slide up against our curve. We place it against the curve and adjust its radius so that where it touches the curve, the curvatures of the curve and the circle are the same, and then we start to slide the circle along the curve - for quadratic curves, we can always do this without the circle behaving oddly: we might have to change the radius of the circle as we slide it along, but it'll always sit against the same side of the curve.

        But what happens with cubic curves? Imagine we have an S curve and we place our circle at the start of the curve, and start sliding it along. For a while we can simply adjust the radius and things will be fine, but once we get to the midpoint of that S, something odd happens: the circle "flips" from one side of the curve to the other side, in order for the curvatures to keep matching. This is called an inflection, and we can find out where those happen relatively easily.

        What we need to do is solve a simple equation:

        - +

        What we're saying here is that given the curvature function C(t), we want to know for which values of t this function is zero, meaning there is no "curvature", which will be exactly at the point between our circle being on one side of the curve, and our circle being on the other side of the curve. So what does C(t) look like? Actually something that seems not too hard:

        - +

        The function C(t) is the cross product between the first and second derivative functions for the parametric dimensions of our curve. And, as already shown, derivatives of Bézier curves are just simpler Bézier curves, with very easy to compute new coefficients, so this should be pretty easy.

        However as we've seen in the section on aligning, aligning lets us simplify things a lot, by completely removing the contributions of the first coordinate from most mathematical evaluations, and removing the last y coordinate as well by virtue of the last point lying on the x-axis. So, while we can evaluate C(t) = 0 for our curve, it'll be much easier to first axis-align the curve and then evaluating the curvature function.

        Let's derive the full formula anyway

        Of course, before we do our aligned check, let's see what happens if we compute the curvature function without axis-aligning. We start with the first and second derivatives, given our basis functions:

        - +

        And of course the same functions for y:

        - +

        Asking a computer to now compose the C(t) function for us (and to expand it to a readable form of simple terms) gives us this rather overly complicated set of arithmetic expressions:

        - +

        That is... unwieldy. So, we note that there are a lot of terms that involve multiplications involving x1, y1, and y4, which would all disappear if we axis-align our curve, which is why aligning is a great idea.

        Aligning our curve so that three of the eight coefficients become zero, and observing that scale does not affect finding t values, we end up with the following simple term function for C(t):

        - +

        That's a lot easier to work with: we see a fair number of terms that we can compute and then cache, giving us the following simplification:

        - +

        This is a plain quadratic curve, and we know how to solve C(t) = 0; we use the quadratic formula:

        - +

        We can easily compute this value if the discriminator isn't a negative number (because we only want real roots, not complex roots), and if x is not zero, because divisions by zero are rather useless.

        Taking that into account, we compute t, we disregard any t value that isn't in the Bézier interval [0,1], and we now know at which t value(s) our curve will inflect.

        @@ -1298,13 +1298,13 @@ function getCubicRoots(pa, pb, pc, pd) {
      3. ...anywhere inside the red zone, but not on its boundaries, the curve will either be self-intersecting (yielding a loop). We won't know where it self-intersects (in terms of t values), but we are guaranteed that it does.

      4. ...on the left (red) edge of the red zone, the curve will have a cusp. We again don't know where, but we know there is one. This edge is described by the function:

        - +
      5. ...on the almost circular, lower right (pink) edge, the curve's end point touches the curve, forming a loop. This edge is described by the function:

        - +
      6. ...on the top (blue) edge, the curve's start point touches the curve, forming a loop. This edge is described by the function:

        - +
      7. ...inside the lower (green) zone, past y=1, the curve will have a single inflection (switching concave/convex once).

      8. @@ -1325,24 +1325,24 @@ function getCubicRoots(pa, pb, pc, pd) {

        So now the question becomes: how do we manipulate our curve so that it fits this canonical form, with three fixed points, and one "free" point? Enter linear algebra. Don't worry, I'll be doing all the math for you, as well as show you what the effect is on our curves, but basically we're going to be using linear algebra, rather than calculus, because "it's way easier". Sometimes a calculus approach is very hard to work with, when the equivalent geometrical solution is super obvious.

        The approach is going to start with a curve that doesn't have all-colinear points (so we need to make sure the points don't all fall on a straight line), and then applying three graphics operations that you will probably have heard of: translation (moving all points by some fixed x- and y-distance), scaling (multiplying all points by some x and y scale factor), and shearing (an operation that turns rectangles into parallelograms).

        Step 1: we translate any curve by -p1.x and -p1.y, so that the curve starts at (0,0). We're going to make use of an interesting trick here, by pretending our 2D coordinates are 3D, with the z coordinate simply always being 1. This is an old trick in graphics to overcome the limitations of 2D transformations: without it, we can only turn (x,y) coordinates into new coordinates of the form (ax + by, cx + dy), which means we can't do translation, since that requires we end up with some kind of (x + a, y + b). If we add a bogus z coordinate that is always 1, then we can suddenly add arbitrary values. For example:

        - +

        Sweet! z stays 1, so we can effectively ignore it entirely, but we added some plain values to our x and y coordinates. So, if we want to subtract p1.x and p1.y, we use:

        - +

        Running all our coordinates through this transformation gives a new set of coordinates, let's call those U, where the first coordinate lies on (0,0), and the rest is still somewhat free. Our next job is to make sure point 2 ends up lying on the x=0 line, so what we want is a transformation matrix that, when we run it, subtracts x from whatever x we currently have. This is called shearing, and the typical x-shear matrix and its transformation looks like this:

        - +

        So we want some shearing value that, when multiplied by y, yields -x, so our x coordinate becomes zero. That value is simply -x/y, because *-x/y * y = -x*. Done:

        - +

        Now, running this on all our points generates a new set of coordinates, let's call those V, which now have point 1 on (0,0) and point 2 on (0, some-value), and we wanted it at (0,1), so we need to do some scaling to make sure it ends up at (0,1). Additionally, we want point 3 to end up on (1,1), so we can also scale x to make sure its x-coordinate will be 1 after we run the transform. That means we'll be x-scaling by 1/point3x, and y-scaling by point2y. This is really easy:

        - +

        Then, finally, this generates a new set of coordinates, let's call those W, of which point 1 lies on (0,0), point 2 lies on (0,1), and point three lies on (1, ...) so all that's left is to make sure point 3 ends up at (1,1) - but we can't scale! Point 2 is already in the right place, and y-scaling would move it out of (0,1) again, so our only option is to y-shear point three, just like how we x-sheared point 2 earlier. In this case, we do the same trick, but with y/x rather than x/y because we're not x-shearing but y-shearing. Additionally, we don't actually want to end up at zero (which is what we did before) so we need to shear towards an offset, in this case 1:

        - +

        And this generates our final set of four coordinates. Of these, we already know that points 1 through 3 are (0,0), (0,1) and (1,1), and only the last coordinate is "free". In fact, given any four starting coordinates, the resulting "transformation mapped" coordinate will be:

        - +

        Okay, well, that looks plain ridiculous, but: notice that every coordinate value is being offset by the initial translation, and also notice that a lot of terms in that expression are repeated. Even though the maths looks crazy as a single expression, we can just pull this apart a little and end up with an easy-to-calculate bit of code!

        First, let's just do that translation step as a "preprocessing" operation so we don't have to subtract the values all the time. What does that leave?

        - +

        Suddenly things look a lot simpler: the mapped x is fairly straight forward to compute, and we see that the mapped y actually contains the mapped x in its entirety, so we'll have that part already available when we need to evaluate it. In fact, let's pull out all those common factors to see just how simple this is:

        - +

        That's kind of super-simple to write out in code, I think you'll agree. Coding math tends to be easier than the formulae initially make it look!

        @@ -1375,11 +1375,11 @@ function getCubicRoots(pa, pb, pc, pd) {

        Now, if you look more closely at that right graphic, you'll notice something interesting: if we treat the red line as "the x axis", then the point where the function crosses our line is really just a root for the cubic function x(t) through a shifted "x-axis"... and we've already seen how to calculate roots, so let's just run cubuc root finding - and not even the complicated cubic case either: because of the kind of curve we're starting with, we know there is only root, simplifying the code we need!

        First, let's look at the function for x(t):

        - +

        We can rewrite this to a plain polynomial form, by just fully writing out the expansion and then collecting the polynomial factors, as:

        - +

        Nothing special here: that's a standard cubic polynomial in "power" form (i.e. all the terms are ordered by their power of t). So, given that a, b, c, d, and x(t) are all known constants, we can trivially rewrite this (by moving the x(t) across the equal sign) as:

        - +

        You might be wondering "where did all the other 'minus x' for all the other values a, b, c, and d go?" and the answer there is that they all cancel out, so the only one we actually need to subtract is the one at the end. Handy! So now we just solve this equation using Cardano's algorithm, and we're left with some rather short code:

        // prepare our values for root finding:
         x = a value we already know
        @@ -1406,13 +1406,13 @@ y = curve.get(t).y

        Arc length

        How long is a Bézier curve? As it turns out, that's not actually an easy question, because the answer requires maths that —much like root finding— cannot generally be solved the traditional way. If we have a parametric curve with fx(t) and fy(t), then the length of the curve, measured from start point to some point t = z, is computed using the following seemingly straight forward (if a bit overwhelming) formula:

        - +

        or, more commonly written using Leibnitz notation as:

        - +

        This formula says that the length of a parametric curve is in fact equal to the area underneath a function that looks a remarkable amount like Pythagoras' rule for computing the diagonal of a straight angled triangle. This sounds pretty simple, right? Sadly, it's far from simple... cutting straight to after the chase is over: for quadratic curves, this formula generates an unwieldy computation, and we're simply not going to implement things that way. For cubic Bézier curves, things get even more fun, because there is no "closed form" solution, meaning that due to the way calculus works, there is no generic formula that allows you to calculate the arc length. Let me just repeat this, because it's fairly crucial: for cubic and higher Bézier curves, there is no way to solve this function if you want to use it "for all possible coordinates".

        Seriously: It cannot be done.

        So we turn to numerical approaches again. The method we'll look at here is the Gauss quadrature. This approximation is a really neat trick, because for any nth degree polynomial it finds approximated values for an integral really efficiently. Explaining this procedure in length is way beyond the scope of this page, so if you're interested in finding out why it works, I can recommend the University of South Florida video lecture on the procedure, linked in this very paragraph. The general solution we're looking for is the following:

        - +

        In plain text: an integral function can always be treated as the sum of an (infinite) number of (infinitely thin) rectangular strips sitting "under" the function's plotted graph. To illustrate this idea, the following graph shows the integral for a sinusoid function. The more strips we use (and of course the more we use, the thinner they get) the closer we get to the true area under the curve, and thus the better the approximation:

        @@ -1441,12 +1441,12 @@ y = curve.get(t).y

        Note that one requirement for the approach we'll use is that the integral must run from -1 to 1. That's no good, because we're dealing with Bézier curves, and the length of a section of curve applies to values which run from 0 to "some value smaller than or equal to 1" (let's call that value z). Thankfully, we can quite easily transform any integral interval to any other integral interval, by shifting and scaling the inputs. Doing so, we get the following:

        - +

        That may look a bit more complicated, but the fraction involving z is a fixed number, so the summation, and the evaluation of the f(t) values are still pretty simple.

        So, what do we need to perform this calculation? For one, we'll need an explicit formula for f(t), because that derivative notation is handy on paper, but not when we have to implement it. We'll also need to know what these Ci and ti values should be. Luckily, that's less work because there are actually many tables available that give these values, for any n, so if we want to approximate our integral with only two terms (which is a bit low, really) then these tables would tell us that for n=2 we must use the following values:

        - +

        Which means that in order for us to approximate the integral, we must plug these values into the approximate function, which gives us:

        - +

        We can program that pretty easily, provided we have that f(t) available, which we do, as we know the full description for the Bézier curve functions Bx(t) and By(t).

        @@ -1508,9 +1508,9 @@ y = curve.get(t).y

        That's crazy!

        But that's also one of the things that makes maths so powerful: even if your initial ideas are off the mark, you might be much closer than you thought you were, and the journey from "thinking we're completely wrong" to "actually being remarkably close to being right" is where we can find a lot of insight.

        So, what does the function look like? This:

        - +

        Which is really just a "short form" that glosses over the fact that we're dealing with functions of t, so let's expand that a tiny bit:

        - +

        And while that's a litte more verbose, it's still just as simple to work with as the first function: the curvature at some point on any (and this cannot be overstated: any) curve is a ratio between the first and second derivative cross product, and something that looks oddly similar to the standard Euclidean distance function. And nothing in these functions is hard to calculate either: for Bézier curves, simply knowing our curve coordinates means we know what the first and second derivatives are, and so evaluating this function for any t value is just a matter of basic arithematics.

        In fact, let's just implement it right now:

        function kappa(t, B):
        @@ -1694,24 +1694,24 @@ lli = function(line1, line2):
         

      These three values A, B, and C allow us to derive an important identity formula for quadratic and cubic Bézier curves: for any point on the curve with some t value, the ratio of distances from A to B and B to C is fixed: if some t value sets up a C that is 20% away from the start and 80% away from the end, then it doesn't matter where the start, end, or control points are; for that t value, C will always lie at 20% from the start and 80% from the end point. Go ahead, pick an on-curve point in either graphic and then move all the other points around: if you only move the control points, start and end won't move, and so neither will C, and if you move either start or end point, C will move but its relative position will not change.

      So, how can we compute C? We start with our observation that C always lies somewhere between the start and ends points, so logically C will have a function that interpolates between those two coordinates:

      - +

      If we can figure out what the function u(t) looks like, we'll be done. Although we do need to remember that this u(t) will have a different for depending on whether we're working with quadratic or cubic curves. Running through the maths (with thanks to Boris Zbarsky) shows us the following two formulae:

      - +

      And

      - +

      So, if we know the start and end coordinates, and we know the t value, we know C, without having to calculate the A or even B coordinates. In fact, we can do the same for the ratio function: as another function of t, we technically don't need to know what A or B or C are, we can express it was a pure function of t, too.

      We start by observing that, given A, B, and C, the following always holds:

      - +

      Working out the maths for this, we see the following two formulae for quadratic and cubic curves:

      - +

      And

      - +

      Which now leaves us with some powerful tools: given thee points (start, end, and "some point on the curve"), as well as a t value, we can contruct curves: we can compute C using the start and end points, and our u(t) function, and once we have C, we can use our on-curve point (B) and the ratio(t) function to find A:

      - +

      With A found, finding e1 and e2 for quadratic curves is a matter of running the linear interpolation with t between start and A to yield e1, and between A and end to yield e2. For cubic curves, there is no single pair of points that can act as e1 and e2: as long as the distance ratio between e1 to B and B to e2 is the Bézier ratio (1-t):t, we can reverse engineer v1 and v2:

      - +

      And then reverse engineer the curve's control control points:

      - +

      So: if we have a curve's start and end point, then for any t value we implicitly know all the ABC values, which (combined with an educated guess on appropriate e1 and e2 coordinates for cubic curves) gives us the necessary information to reconstruct a curve's "de Casteljau skeleton". Which means that we can now do several things: we can "fit" curves using only three points, which means we can also "mold" curves by moving an on-curve point but leaving its start and end point, and then reconstructing the curve based on where we moved the on-curve point to. These are very useful things, and we'll look at both in the next few sections.

      @@ -1719,7 +1719,7 @@ lli = function(line1, line2):

      Creating a curve from three points

      Given the preceding section, you might be wondering if we can use that knowledge to just "create" curves by placing some points and having the computer do the rest, to which the answer is: that's exactly what we can now do!

      For quadratic curves, things are pretty easy. Technically, we'll need a t value in order to compute the ratio function used in computing the ABC coordinates, but we can just as easily approximate one by treating the distance between the start and B point, and B and end point as a ratio, using

      - +

      With this code in place, creating a quadratic curve from three points is literally just computing the ABC values, and using A as our curve's control point:

      @@ -1738,11 +1738,11 @@ lli = function(line1, line2):

      With that covered, we now also know the tangent line to our point B, because the tangent to any point on the circle is a line through that point, perpendicular to the line from that point to the center. That just leaves marking appropriate points e1 and e2 on that tangent, so that we can construct a new cubic curve hull. We use the approach as we did for quadratic curves to automatically determine a reasonable t value, and then our e1 and e2 coordinates must obey the standard de Casteljau rule for linear interpolation:

      - +

      Where d is the total length of the line segment from e1 to e2. So how long do we make that? There are again all kinds of approaches we can take, and a simple-but-effective one is to set the length of that segment to "one third the length of the baseline". This forces e1 and e2 to always be the "linear curve" distance apart, which means if we place our three points on a line, it will actually look like a line. Nice! The last thing we'll need to do is make sure to flip the sign of d depending on which side of the baseline our B is located, so we don't up creating a funky curve with a loop in it. To do this, we can use the atan2 function:

      - +

      This angle φ will be between 0 and π if B is "above" the baseline (rotating all three points so that the start is on the left and the end is the right), so we can use a relatively straight forward check to make sure we're using the correct sign for our value d:

      - +

      The result of this approach looks as follows:

      @@ -1794,9 +1794,9 @@ for (coordinate, index) in LUT:

      Molding a curve

      Armed with knowledge of the "ABC" relation, point-on-curve projection, and guestimating reasonable looking helper values for cubic curve construction, we can finally cover curve molding: updating a curve's shape interactively, by dragging points on the curve around.

      For quadratic curve, this is a really simple trick: we project our cursor onto the curve, which gives us a t value and initial B coordinate. We don't even need the latter: with our t value and "whever the cursor is" as target B, we can compute the associated C:

      - +

      And then the associated A:

      - +

      And we're done, because that's our new quadratic control point!

      @@ -1841,25 +1841,25 @@ for (coordinate, index) in LUT:

      Revisiting the matrix representation

      Rewriting Bézier functions to matrix form is fairly easy, if you first expand the function, and then arrange them into a multiple line form, where each line corresponds to a power of t, and each column is for a specific coefficient. First, we expand the function:

      - +

      And then we (trivially) rearrange the terms across multiple lines:

      - +

      This rearrangement has "factors of t" at each row (the first row is t⁰, i.e. "1", the second row is t¹, i.e. "t", the third row is t²) and "coefficient" at each column (the first column is all terms involving "a", the second all terms involving "b", the third all terms involving "c").

      With that arrangement, we can easily decompose this as a matrix multiplication:

      - +

      We can do the same for the cubic curve, of course. We know the base function for cubics:

      - +

      So we write out the expansion and rearrange:

      - +

      Which we can then decompose:

      - +

      And, of course, we can do this for quartic curves too (skipping the expansion step):

      - +

      And so and on so on. Now, let's see how to use these T, M, and C, to do some curve fitting.

      Let's get started: we're going to assume we picked the right order curve: for n points we're fitting an n-1th order curve, so we "start" with a vector P that represents the coordinates we already know, and for which we want to do curve fitting:

      - +

      Next, we need to figure out appropriate t values for each point in the curve, because we need something that lets us tie "the actual coordinate" to "some point on the curve". There's a fair number of different ways to do this (and a large part of optimizing "the perfect fit" is about picking appropriate t values), but in this case let's look at two "obvious" choices:

      1. equally spaced t values, and
      2. @@ -1868,27 +1868,27 @@ for (coordinate, index) in LUT:

        The first one is really simple: if we have n points, then we'll just assign each point i a t value of (i-1)/(n-1). So if we have four points, the first point will have t=(1-1)/(4-1)=0/3, the second point will have t=(2-1)/(4-1)=1/3, the third point will have t=2/3, and the last point will be t=1. We're just straight up spacing the t values to match the number of points we have.

        The second one is a little more interesting: since we're doing polynomial regression, we might as well exploit the fact that our base coordinates just constitute a collection of line segments. At the first point, we're fixing t=0, and the last point, we want t=1, and anywhere in between we're simply going to say that t is equal to the distance along the polygon, scaled to the [0,1] domain.

        To get these values, we first compute the general "distance along the polygon" matrix:

        - +

        Where length() is literally just that: the length of the line segment between the point we're looking at, and the previous point. This isn't quite enough, of course: we still need to make sure that all the values between i=1 and i=n fall in the [0,1] interval, so we need to scale all values down by whatever the total length of the polygon is:

        - +

        And now we can move on to the actual "curve fitting" part: what we want is a function that lets us compute "ideal" control point values such that if we build a Bézier curve with them, that curve passes through all our original points. Or, failing that, have an overall error distance that is as close to zero as we can get it. So, let's write out what the error distance looks like.

        As mentioned before, this function is really just "the distance between the actual coordinate, and the coordinate that the curve evaluates to for the associated t value", which we'll square to get rid of any pesky negative signs:

        - +

        Since this function only deals with individual coordinates, we'll need to sum over all coordinates in order to get the full error function. So, we literally just do that; the total error function is simply the sum of all these individual errors:

        - +

        And here's the trick that justifies using matrices: while we can work with individual values using calculus, with matrices we can compute as many values as we make our matrices big, all at the "same time", We can replace the individual terms pi with the full P coordinate matrix, and we can replace Bézier(si) with the matrix representation T x M x C we talked about before, which gives us:

        - +

        In which we can replace the rather cumbersome "squaring" operation with a more conventional matrix equivalent:

        - +

        Here, the letter T is used instead of the number 2, to represent the matrix transpose; each row in the original matrix becomes a column in the transposed matrix instead (row one becomes column one, row two becomes column two, and so on).

        This leaves one problem: T isn't actually the matrix we want: we don't want symbolic t values, we want the actual numerical values that we computed for S, so we need to form a new matrix, which we'll call 𝕋, that makes use of those, and then use that 𝕋 instead of T in our error function:

        - +

        Which, because of the first and last values in S, means:

        - +

        Now we can properly write out the error function as matrix operations:

        - +

        So, we have our error function: we now need to figure out the expression for where that function has minimal value, e.g. where the error between the true coordinates and the coordinates generated by the curve fitting is smallest. Like in standard calculus, this requires taking the derivative, and determining where that derivative is zero:

        - +

        Where did this derivative come from?

        @@ -1898,7 +1898,7 @@ for (coordinate, index) in LUT:

        Now, given the above derivative, we can rearrange the terms (following the rules of matrix algebra) so that we end up with an expression for C:

        - +

        Here, the "to the power negative one" is the notation for the matrix inverse. But that's all we have to do: we're done. Starting with P and inventing some t values based on the polygon the coordinates in P define, we can compute the corresponding Bézier coordinates C that specify a curve that goes through our points. Or, if it can't go through them exactly, as near as possible.

        So before we try that out, how much code is involved in implementing this? Honestly, that answer depends on how much you're going to be writing yourself. If you already have a matrix maths library available, then really not that much code at all. On the other hand, if you are writing this from scratch, you're going to have to write some utility functions for doing your matrix work for you, so it's really anywhere from 50 lines of code to maybe 200 lines of code. Not a bad price to pay for being able to fit curves to prespecified coordinates.

        So let's try it out! The following graphic lets you place points, and will start computing exact-fit curves once you've placed at least three. You can click for more points, and the code will simply try to compute an exact fit using a Bézier curve of the appropriate order. Four points? Cubic Bézier. Five points? Quartic. And so on. Of course, this does break down at some point: depending on where you place your points, it might become mighty hard for the fitter to find an exact fit, and things might actually start looking horribly off once there's enough points for compound floating point rounding errors to start making a difference (which is around 10~11 points).

        @@ -1929,7 +1929,7 @@ for (coordinate, index) in LUT:

        Now, it may look like Catmull-Rom curves are very different from Bézier curves, because these curves can get very long indeed, but what looks like a single Catmull-Rom curve is actually a spline: a single curve built up of lots of identically-computed pieces, similar to if you just took a whole bunch of Bézier curves, placed them end to end, and lined up their control points so that things look like a single curve. For a Catmull-Rom curve, each "piece" between two points is defined by the point's coordinates, and the tangent for those points, the latter of which can trivially be derived from knowing the previous and next point:

        - +

        One downside of this is that—as you may have noticed from the graphic—the first and last point of the overall curve don't actually join up with the rest of the curve: they don't have a previous/next point respectively, and so there is no way to calculate what their tangent should be. Which also makes it rather tricky to fit a Camull-Rom curve to three points like we were able to do for Bézier curves. More on that in the next section.

        In fact, before we move on, let's look at how to actually draw the basic form of these curves (I say basic, because there are a number of variations that make things considerable more complex):

        tension = some value greater than 0, defaulting to 1
        @@ -1958,77 +1958,77 @@ for p = 1 to points.length-3 (inclusive):
         
      3. A Catmull-Rom curve is defined by a start point, a tangent that for that starting point, an end point, and a tangent for that end point, plus a characteristic matrix that we can multiple by the point vector to get on-curve coordinates.
      4. Those are very similar, so let's see exactly how similar they are. We've already see the matrix form for Bézier curves, so how different is the matrix form for Catmull-Rom curves?:

        - +

        That's pretty dang similar. So the question is: how can we convert that expression with Catmull-Rom matrix and vector into an expression of the Bézier matrix and vector? The short answer is of course "by using linear algebra", but the longer answer is the rest of this section, and involves some maths that you may not even care for: if you just want to know the (incredibly simple) conversions between the two curve forms, feel free to skip to the end of the following explanation, but if you want to how we can get one from the other... let's get mathing!

        Deriving the conversion formulae

        In order to convert between Catmull-Rom curves and Bézier curves, we need to know two things. Firstly, how to express the Catmull-Rom curve using a "set of four coordinates", rather than a mix of coordinates and tangents, and secondly, how to convert those Catmull-Rom coordinates to and from Bézier form.

        We start with the first part, to figure out how we can go from Catmull-Rom V coordinates to Bézier P coordinates, by applying "some matrix T". We don't know what that T is yet, but we'll get to that:

        - +

        So, this mapping says that in order to map a Catmull-Rom "point + tangent" vector to something based on an "all coordinates" vector, we need to determine the mapping matrix such that applying T yields P2 as start point, P3 as end point, and two tangents based on the lines between P1 and P3, and P2 nd P4, respectively.

        Computing T is really more "arranging the numbers":

        - +

        Thus:

        - +

        However, we're not quite done, because Catmull-Rom curves have that "tension" parameter, written as τ (a lowercase"tau"), which is a scaling factor for the tangent vectors: the bigger the tension, the smaller the tangents, and the smaller the tension, the bigger the tangents. As such, the tension factor goes in the denominator for the tangents, and before we continue, let's add that tension factor into both our coordinate vector representation, and mapping matrix T:

        - +

        With the mapping matrix properly done, let's rewrite the "point + tangent" Catmull-Rom matrix form to a matrix form in terms of four coordinates, and see what we end up with:

        - +

        Replace point/tangent vector with the expression for all-coordinates:

        - +

        and merge the matrices:

        - +

        This looks a lot like the Bézier matrix form, which as we saw in the chapter on Bézier curves, should look like this:

        - +

        So, if we want to express a Catmull-Rom curve using a Bézier curve, we'll need to turn this Catmull-Rom bit:

        - +

        Into something that looks like this:

        - +

        And the way we do that is with a fairly straight forward bit of matrix rewriting. We start with the equality we need to ensure:

        - +

        Then we remove the coordinate vector from both sides without affecting the equality:

        - +

        Then we can "get rid of" the Bézier matrix on the right by left-multiply both with the inverse of the Bézier matrix:

        - +

        A matrix times its inverse is the matrix equivalent of 1, and because "something times 1" is the same as "something", so we can just outright remove any matrix/inverse pair:

        - +

        And now we're basically done. We just multiply those two matrices and we know what V is:

        - +

        We now have the final piece of our function puzzle. Let's run through each step.

        1. Start with the Catmull-Rom function:
        - +
        1. rewrite to pure coordinate form:
        - +
        1. rewrite for "normal" coordinate vector:
        - +
        1. merge the inner matrices:
        - +
        1. rewrite for Bézier matrix form:
        - +
        1. and transform the coordinates so we have a "pure" Bézier expression:
        - +

        And we're done: we finally know how to convert these two curves!

        If we have a Catmull-Rom curve defined by four coordinates P1 through P4, then we can draw that curve using a Bézier curve that has the vector:

        - +

        Similarly, if we have a Bézier curve defined by four coordinates P1 through P4, we can draw that using a standard tension Catmull-Rom curve with the following coordinate values:

        - +

        Or, if your API allows you to specify Catmull-Rom curves using plain coordinates:

        - +
        @@ -2061,9 +2061,9 @@ for p = 1 to points.length-3 (inclusive):

        Dragging the control points around only affects the curve segments that the control point belongs to, and moving an on-curve point leaves the control points where they are, which is not the most useful for practical modelling purposes. So, let's add in the logic we need to make things a little better. We'll start by linking up control points by ensuring that the "incoming" derivative at an on-curve point is the same as it's "outgoing" derivative:

        - +

        We can effect this quite easily, because we know that the vector from a curve's last control point to its last on-curve point is equal to the derivative vector. If we want to ensure that the first control point of the next curve matches that, all we have to do is mirror that last control point through the last on-curve point. And mirroring any point A through any point B is really simple:

        - +

        So let's implement that and see what it gets us. The following two graphics show a quadratic and a cubic poly-Bézier curve again, but this time moving the control points around moves others, too. However, you might see something unexpected going on for quadratic curves...

        @@ -2123,16 +2123,16 @@ for p = 1 to points.length-3 (inclusive):

        "What do you mean, you can't? Prove it."

        First off, when I say "you can't," what I really mean is "you can't offset a Bézier curve with another Bézier curve", not even by using a really high order curve. You can find the function that describes the offset curve, but it won't be a polynomial, and as such it cannot be represented as a Bézier curve, which has to be a polynomial. Let's look at why this is:

        From a mathematical point of view, an offset curve O(t) is a curve such that, given our original curve B(t), any point on O(t) is a fixed distance d away from coordinate B(t). So let's math that:

        - +

        However, we're working in 2D, and d is a single value, so we want to turn it into a vector. If we want a point distance d "away" from the curve B(t) then what we really mean is that we want a point at d times the "normal vector" from point B(t), where the "normal" is a vector that runs perpendicular ("at a right angle") to the tangent at B(t). Easy enough:

        - +

        Now this still isn't very useful unless we know what the formula for N(t) is, so let's find out. N(t) runs perpendicular to the original curve tangent, and we know that the tangent is simply B'(t), so we could just rotate that 90 degrees and be done with it. However, we need to ensure that N(t) has the same magnitude for every t, or the offset curve won't be at a uniform distance, thus not being an offset curve at all. The easiest way to guarantee this is to make sure N(t) always has length 1, which we can achieve by dividing B'(t) by its magnitude:

        - +

        Determining the length requires computing an arc length, and this is where things get Tricky with a capital T. First off, to compute arc length from some start a to end b, we must use the formula we saw earlier. Noting that "length" is usually denoted with double vertical bars:

        - +

        So if we want the length of the tangent, we plug in B'(t), with t = 0 as start and t = 1 as end:

        - +

        And that's where things go wrong. It doesn't even really matter what the second derivative for B(t) is, that square root is screwing everything up, because it turns our nice polynomials into things that are no longer polynomials.

        There is a small class of polynomials where the square root is also a polynomial, but they're utterly useless to us: any polynomial with unweighted binomial coefficients has a square root that is also a polynomial. Now, you might think that Bézier curves are just fine because they do, but they don't; remember that only the base function has binomial coefficients. That's before we factor in our coordinates, which turn it into a non-binomial polygon. The only way to make sure the functions stay binomial is to make all our coordinates have the same value. And that's not a curve, that's a point. We can already create offset curves for points, we call them circles, and they have much simpler functions than Bézier curves.

        So, since the tangent length isn't a polynomial, the normalised tangent won't be a polynomial either, which means N(t) won't be a polynomial, which means that d times N(t) won't be a polynomial, which means that, ultimately, O(t) won't be a polynomial, which means that even if we can determine the function for O(t) just fine (and that's far from trivial!), it simply cannot be represented as a Bézier curve.

        @@ -2212,25 +2212,25 @@ for p = 1 to points.length-3 (inclusive):

        As you can see, things go horribly wrong quite quickly; even trying to approximate a quarter circle using a quadratic curve is a bad idea. An eighth of a turns might look okay, but how okay is okay? Let's apply some maths and find out. What we're interested in is how far off our on-curve coordinates are with respect to a circular arc, given a specific start and end angle. We'll be looking at how much space there is between the circular arc, and the quadratic curve's midpoint.

        We start out with our start and end point, and for convenience we will place them on a unit circle (a circle around 0,0 with radius 1), at some angle φ:

        - +

        What we want to find is the intersection of the tangents, so we want a point C such that:

        - +

        i.e. we want a point that lies on the vertical line through S (at some distance a from S) and also lies on the tangent line through E (at some distance b from E). Solving this gives us:

        - +

        First we solve for b:

        - +

        which yields:

        - +

        which we can then substitute in the expression for a:

        - +

        A quick check shows that plugging these values for a and b into the expressions for Cx and Cy give the same x/y coordinates for both "a away from A" and "b away from B", so let's continue: now that we know the coordinate values for C, we know where our on-curve point T for t=0.5 (or angle φ/2) is, because we can just evaluate the Bézier polynomial, and we know where the circle arc's actual point P is for angle φ/2:

        - +

        We compute T, observing that if t=0.5, the polynomial values (1-t)², 2(1-t)t, and t² are 0.25, 0.5, and 0.25 respectively:

        - +

        Which, worked out for the x and y components, gives:

        - +

        And the distance between these two is the standard Euclidean distance:

        - +

        So, what does this distance function look like when we plot it for a number of ranges for the angle φ, such as a half circle, quarter circle and eighth circle?

        @@ -2247,7 +2247,7 @@ for p = 1 to points.length-3 (inclusive):

        We now see why the eighth circle arc looks decent, but the quarter circle arc doesn't: an error of roughly 0.06 at t=0.5 means we're 6% off the mark... we will already be off by one pixel on a circle with pixel radius 17. Any decent sized quarter circle arc, say with radius 100px, will be way off if approximated by a quadratic curve! For the eighth circle arc, however, the error is only roughly 0.003, or 0.3%, which explains why it looks so close to the actual eighth circle arc. In fact, if we want a truly tiny error, like 0.001, we'll have to contend with an angle of (rounded) 0.593667, which equates to roughly 34 degrees. We'd need 11 quadratic curves to form a full circle with that precision! (technically, 10 and ten seventeenth, but we can't do partial curves, so we have to round up). That's a whole lot of curves just to get a shape that can be drawn using a simple function!

        In fact, let's flip the function around, so that if we plug in the precision error, labelled ε, we get back the maximum angle for that precision:

        - +

        And frankly, things are starting to look a bit ridiculous at this point, we're doing way more maths than we've ever done, but thankfully this is as far as we need the maths to take us: If we plug in the precisions 0.1, 0.01, 0.001 and 0.0001 we get the radians values 1.748, 1.038, 0.594 and 0.3356; in degrees, that means we can cover roughly 100 degrees (requiring four curves), 59.5 degrees (requiring six curves), 34 degrees (requiring 11 curves), and 19.2 degrees (requiring a whopping nineteen curves).

        The bottom line? Quadratic curves are kind of lousy if you want circular (or elliptical, which are circles that have been squashed in one dimension) curves. We can do better, even if it's just by raising the order of our curve once. So let's try the same thing for cubic curves.

        @@ -2301,7 +2301,7 @@ for p = 1 to points.length-3 (inclusive):

        The distance from our guessed point to the start point is exactly the same as the projection distance we looked at earlier. Using t=0.5 as our point "B" in the "A,B,C" projection, then we know the length of the line segment {C,A}, since it's d1 = {A,B} + d2 = {B,C}:

        So that just leaves us to find the distance from t=0.5 to the baseline for an arbitrary angle φ, which is the distance from the centre of the circle to our t=0.5 point, minus the distance from the centre to the line that runs from start point to end point. The first is the same as the point P we found for the quadratic curve:

        - +

        And the distance from the origin to the line start/end is another application of angles, since the triangle {origin,start,C} has known angles, and two known sides. We can find the length of the line {origin,C}, which lets us trivially compute the coordinate for C:

        With the coordinate C, and knowledge of coordinate B, we can determine coordinate A, and get a vector that is identical to the vector {start,guess}:

        @@ -2417,27 +2417,27 @@ for p = 1 to points.length-3 (inclusive):

        In order to make this interpolation of curves work, the maths is necessarily more complex than the maths for Bézier curves, so let's have a look at how things work.

        How to compute a B-Spline curve: some maths

        Given a B-Spline of degree d and thus order k=d+1 (so a quadratic B-Spline is degree 2 and order 3, a cubic B-Spline is degree 3 and order 4, etc) and n control points P0 through Pn-1, we can compute a point on the curve for some value t in the interval [0,1] (where 0 is the start of the curve, and 1 the end, just like for Bézier curves), by evaluating the following function:

        - +

        Which, honestly, doesn't tell us all that much. All we can see is that a point on a B-Spline curve is defined as "a mix of all the control points, weighted somehow", where the weighting is achieved through the N(...) function, subscripted with an obvious parameter i, which comes from our summation, and some magical parameter k. So we need to know two things: 1. what does N(t) do, and 2. what is that k? Let's cover both, in reverse order.

        The parameter k represents the "knot interval" over which a section of curve is defined. As we learned earlier, a B-Spline curve is itself an interpoliation of curves, and we can treat each transition where a control point starts or stops influencing the total curvature as a "knot on the curve". Doing so for a degree d B-Spline with n control point gives us d + n + 1 knots, defining d + n intervals along the curve, and it is these intervals that the above k subscript to the N() function applies to.

        Then the N() function itself. What does it look like?

        - +

        So this is where we see the interpolation: N(t) for an (i,k) pair (that is, for a step in the above summation, on a specific knot interval) is a mix between N(t) for (i,k-1) and N(t) for (i+1,k-1), so we see that this is a recursive iteration where i goes up, and k goes down, so it seem reasonable to expect that this recursion has to stop at some point; obviously, it does, and specifically it does so for the following i/k values:

        - +

        And this function finally has a straight up evaluation: if a t value lies within a knot-specific interval once we reach a k=1 value, it "counts", otherwise it doesn't. We did cheat a little, though, because for all these values we need to scale our t value first, so that it lies in the interval bounded by knots[d] and knots[n], which are the start point and end point where curvature is controlled by exactly order control points. For instance, for degree 3 (=order 4) and 7 control points, with knot vector [1,2,3,4,5,6,7,8,9,10,11], we map t from [the interval 0,1] to the interval [4,8], and then use that value in the functions above, instead.

        Can we simplify that?

        We can, yes.

        People far smarter than us have looked at this work, and two in particular — Maurice Cox and Carl de Boor — came to a mathematically pleasing solution: to compute a point P(t), we can compute this point by evaluating d(t) on a curve section between knots i and i+1:

        - +

        This is another recursive function, with k values decreasing from the curve order to 1, and the value α (alpha) defined by:

        - +

        That looks complicated, but it's not. Computing alpha is just a fraction involving known, plain numbers. And, once we have our alpha value, we also have (1-alpha) because it's a trivial subtraction. Computing the d() function is thus mostly a matter of computing pretty simple arithmetical statements, with some caching of results so we can refer to them as we recurve. While the recursion might see computationally expensive, the total algorithm is cheap, as each step only involves very simple maths.

        Of course, the recursion does need a stop condition:

        - +

        So, we actually see two stopping conditions: either i becomes 0, in which case d() is zero, or k becomes zero, in which case we get the same "either 1 or 0" that we saw in the N() function above.

        Thanks to Cox and de Boor, we can compute points on a B-Spline pretty easily using the same kind of linear interpolation we saw in de Casteljau's algorithm. For instance, if we write out d() for i=3 and k=3, we get the following recursion diagram:

        - +

        That is, we compute d(3,3) as a mixture of d(2,3) and d(2,2), where those two are themselves a mixture of d(1,3) and d(1,2), and d(1,2) and d(1,1), respectively, which are themselves a mixture of etc. etc. We simply keep expanding our terms until we reach the stop conditions, and then sum everything back up. It's really quite elegant.

        One thing we need to keep in mind is that we're working with a spline that is constrained by its control points, so even though the d(..., k) values are zero or one at the lowest level, they are really "zero or one, times their respective control point", so in the next section you'll see the algorithm for running through the computation in a way that starts with a copy of the control point vector and then works its way up to that single point, rather than first starting "on the left", working our way "to the right" and then summing back up "to the left". We can just start on the right and work our way left immediately.

        Running the computation