More updates to procedural meshes post

content/posts/2021-07-27-procedural-meshes.org

@@ -7,11 +7,11 @@ tags:
 draft: true
 ---
 
-(TODO: a note to me, reading later: you don't need to give your entire
-life story here.)
+# (TODO: a note to me, reading later: you don't need to give your entire
+# life story here.)
 
-(TODO: pictures will make this post make a *lot* more sense, and it
-may need a lot of them)
+# (TODO: pictures will make this post make a *lot* more sense, and it
+# may need a lot of them)
 
 Context Free is one of my favorite projects since I discovered it
 about 2010.  It's one I've written about before (TODO: link to my
@@ -115,15 +115,15 @@ shaders)
 (TODO: Maybe split these off into sections for each one?)
 
 I put some serious effort into [[https://github.com/Hodapp87/prosha][Prosha]] and was conflicted on shelving
-the project, but the issues didn't look easily solvable.  Part of
-those issues were implementation issues with Rust - not that Rust
-could have really done anything "better" here, but that it just wasn't
-the right tool for what I was doing.  In short, I had spent a lot of
-time and effort trying to badly and unintentionally implement a Lisp
-inside of Rust instead of just picking a Lispier language, or perhaps
-using an embeddable Rust-based scripting language like [[https://github.com/koto-lang/koto][Koto]] or [[https://github.com/rhaiscript/rhai][Rhai]]. I
-had ignored that many things that functional programming left me very
-accustomed to - like first-class functions and closures - were
+the project indefinitely, but the issues didn't look easily solvable.
+Part of those issues were implementation issues with Rust - not that
+Rust could have really done anything "better" here, but that it just
+wasn't the right tool for what I was doing.  In short, I had spent a
+lot of that effort trying to badly and unintentionally implement/embed
+a Lisp inside of Rust instead of just picking a Lispier language, or
+perhaps using an embeddable Rust-based scripting language like [[https://github.com/koto-lang/koto][Koto]] or
+[[https://github.com/rhaiscript/rhai][Rhai]]. I had ignored that many things that functional programming left
+me very accustomed to - like first-class functions and closures - were
 dependent on garbage collection.  When I realized this and did a big
 refactor to remove this entire layer of complexity, I was left with
 very little "core" code - just a handful of library functions, and the
@@ -172,6 +172,9 @@ guides the final mesh.  Further, I didn't even need to bother with
 OpenSubdiv's C++ API, I just needed to get the geometry into Blender,
 and Blender would handle the subdivision on-demand via OpenSubdiv.
 
+# TODO: This definitely needs examples of a control cage, and of edge
+# creases
+
 One minor issue is that this control cage isn't just a triangle mesh,
 but a triangle mesh plus edge creases.  I needed a way to get this
 data into Blender.  However, the only format Blender can read edge
@@ -190,8 +193,8 @@ Debugging this mostly inside Blender also made the process vastly
 faster.  Further, because I was letting Blender handle all of the
 heavy lifting with mesh processing (and it in turn was using things
 like OpenSubdiv), the extra overhead of Python compared to Rust didn't
-matter - I was handling so much less data when only producing the
-control cage, not the full mesh.
+matter - I was handling so much less data because I was generating
+only a control cage, not a full mesh.
 
 I'm still a little stuck at how to build higher 'geometric'
 abstractions here and compose them.  I have felt like most of the
@@ -200,4 +203,4 @@ Free and Structure Synth definitely don't have this problem.  This is
 particularly annoying because a lot of the power of these recursive
 grammars comes from their ability to be abstracted away and composed.
 
-(TODO: Show some examples)
+# (TODO: Show some examples)