From 7a770bb53385a1e9a416b21b993cdb71ccb5514d Mon Sep 17 00:00:00 2001
From: Chris Hodapp <hodapp87@gmail.com>
Date: Sat, 7 Mar 2020 22:24:37 -0500
Subject: [PATCH] Added some parameters to Twist

---
 README.md       | 26 ++++++++++++++++++--------
 src/examples.rs | 12 +++++++-----
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/README.md b/README.md
index 4681a8c..14d609b 100644
--- a/README.md
+++ b/README.md
@@ -2,17 +2,26 @@
 
 ## Highest priority:
 
-- Implement some of the tougher examples from the above too, e.g. the
-  triple nested spiral.  See `examples.py`.
+- See `automata_scratch/examples.py` and implement some of the tougher
+  examples.
+  - `spiral_nested_2` & `spiral_nested_3` (how to compose
+    efficiently?)
+  - `twisty_torus`
+  - `ram_horn_branch` - how do I pass depth in order to do this right?
 
 ## Important but less critical:
 
-- Why must I repeat myself so much in these definitions?
-- The notation for transforms is really cumbersome.  Some syntactic
-  sugar might go far.
-- What patterns can I factor out?  I do some things regularly, like:
-  the clockwise boundaries, the zigzag connections, the iterating over
-  a `Vec<Vertex>` to transform each element and make another vector.
+- Elegance & succinctness:
+  - Why must I repeat myself so much in these definitions?
+  - The notation for transforms is really cumbersome.  Some syntactic
+    sugar might go far.
+  - What patterns can I factor out?  I do some things regularly, like:
+    the clockwise boundaries, the zigzag connections, the iterating over
+    a `Vec<Vertex>` to transform each element and make another vector.
+  - I have seen many of my bugs come from: all this arithmetic on
+    indices.  I generate vertex maps more or less manually.
+  - Helper method to transform `Vec<Vertex>` and such.  I do this
+    often.
 - Docs on modules
 - Grep for all TODOs in code, really.
 - Look at everything in README.md in automata_scratch.
@@ -23,3 +32,4 @@
 - Look in https://www.nalgebra.org/quick_reference/# for "pour
   obtain".  Can I fix this somehow?  Looks like a French-ism that made
   its way in.
+- Multithread!  This looks very task-parallel anywhere that I branch.
diff --git a/src/examples.rs b/src/examples.rs
index 3b754af..3747a59 100644
--- a/src/examples.rs
+++ b/src/examples.rs
@@ -301,8 +301,7 @@ struct Twist {
 
 impl Twist {
 
-    pub fn init() -> (Twist, Rule<Twist>) {
-        let subdiv = 2;
+    pub fn init(f: f32, subdiv: usize) -> (Twist, Rule<Twist>) {
         let xf = geometry::Rotation3::from_axis_angle(&Vector3::x_axis(), -0.7).to_homogeneous();
         let seed = vec![
             vertex(-0.5,  0.0, -0.5),
@@ -313,8 +312,8 @@ impl Twist {
         let seed_sub = util::subdivide_cycle(&seed, subdiv);
         let t = Twist {
             dx0: 2.0,
-            dy: 0.1,
-            ang: 0.1,
+            dy: 0.1/f,
+            ang: 0.1/f,
             count: 4,
             seed: seed,
             seed_sub: seed_sub,
@@ -442,5 +441,8 @@ pub fn main() {
     // TODO: If I increase the above from 100 to ~150, Blender reports
     // that the very tips are non-manifold.  I am wondering if this is
     // some sort of numerical precision issue.
-    run_test_iter(Twist::init(), 100, "twist2");
+    
+    run_test_iter(Twist::init(1.0, 2), 100, "twist2");
+    // This is a stress test:
+    //run_test_iter(Twist::init(10.0, 16), 800, "twist2");
 }