diff --git a/content/posts/2021-07-27-procedural-meshes/index.org b/content/posts/2021-07-27-procedural-meshes/index.org
index 5405f89..353211b 100644
--- a/content/posts/2021-07-27-procedural-meshes/index.org
+++ b/content/posts/2021-07-27-procedural-meshes/index.org
@@ -54,35 +54,71 @@ ever, for introducing me to it awhile ago).  See also [[https://kronpano.github.
 However, at some point I realized they weren't exactly what I wanted.
 Structure Synth lets you combine together 3D primitives to build up a
 more complex scene - but doesn't try to properly handle any sort of
-*joining* of these primitives in a way that respects many of the
+/joining/ of these primitives in a way that respects many of the
 'rules' of geometry that are necessary for a lot of tools, like having
 a well-defined inside/outside, not being self-intersecting, being
 manifold, and so forth.
 
+Here are a few images from an hour or two of my dabbling in Structure
+Synth - one Blender screenshot, and two [[https://appleseedhq.net/][appleseed]] renders from when I
+was trying to work with it:
+
+{{< gallery >}}
+    {{< figure resource="structure-synth-mesh.png">}}
+    {{< figure page="images" resource="placeholder/appleseed_spiral_thing2.jpg">}}
+    {{< figure page="images" resource="placeholder/appleseed_spiral_thing.jpg">}}
+{{< /gallery >}}
+
+That's a "Hello World" tier design I try out when something gives me
+geometric transforms and recursion.  The first image (the Blender one)
+snhould show the bits of unconnected and half-connected and
+self-intersecting geometry - that is what I wanted to work around.
+You can look at this and say, "That really makes no difference, and
+Structure Synth is capable of anything you /practically/ want to
+create, but you're just searching for something to nitpick and
+complain about so that you have a justification for why you reinvented
+it badly," and you're probably more right than wrong, but you're also
+still reading, so the joke's on you.
+
 Tools like [[https://openscad.org/][OpenSCAD]], based on [[https://www.cgal.org/][CGAL]], handle the details of this, and I
 suspect that [[https://www.opencascade.com/][Open CASCADE]] (thus [[https://www.freecadweb.org/][FreeCAD]]) also does.  In CAD work, it's
-crucial.  I experimented with similar recursive systems with some of
-these, but I quickly ran into a problem: they were made for actual
-practical applications in CAD, not so much for my generative art, and
-they scaled quite poorly with the sort of recursion I was asking for.
+crucial.  Here's something similar I threw together in OpenSCAD with
+the help of some automatically generated code:
 
-Implicit surfaces (or one of the many related-but-not-identical things
-around this, e.g. [[https://en.wikipedia.org/wiki/Function_representation][F-Reps]] or distance bounds or [[https://en.wikipedia.org/wiki/Signed_distance_function][SDFs]] or isosurfaces)
-handle almost all of this well! They express [[https://en.wikipedia.org/wiki/Constructive_solid_geometry][CSG]] operations, they can
-be rendered directly on the GPU via shaders, operations like blending
-shapes or twisting them are easy... for more on this, see [[http://blog.hvidtfeldts.net/][Syntopia]]
-again, or nearly anything by [[https://iquilezles.org/][Inigo Quilez]], or look up raymarching and
-sphere tracing, or see [[https://ntopology.com/][nTopology]], or Matt Keeter's work with [[https://www.libfive.com/][libfive]]
-and [[https://www.mattkeeter.com/research/mpr/][MPR]].  They're pure magic, they're wonderfully elegant, and I'll
-probably have many other posts on them.  (TODO: Link to my CS6460
-stuff)
+{{< gallery >}}
+    {{< figure resource="openscad-mesh.png">}}
+    {{< figure resource="openscad-mesh2.png">}}
+{{< /gallery >}}
+
+In the second image you can see how it properly handled intersecting
+geometry, and facetizing the curve I purposely stuck in there.  The
+mesh looks great, but I quickly ran into a problem: OpenSCAD scales
+pretty poorly with this level of complexity - and as far as that goes,
+this geometry is even fairly mild.  This really isn't surprising, as
+tools like this were made for practical applications in CAD, and not
+so much for my silly explorations in generative art.
+
+But wait! Implicit surfaces handle almost all of this well! (Or call
+them one of the many related-but-not-identical things around this,
+e.g. [[https://en.wikipedia.org/wiki/Function_representation][F-Reps]] or distance bounds or [[https://en.wikipedia.org/wiki/Signed_distance_function][SDFs]] or isosurfaces...) They express
+[[https://en.wikipedia.org/wiki/Constructive_solid_geometry][CSG]] operations, they can be rendered directly on the GPU via shaders,
+operations like blending shapes or twisting them are easy... for more
+on this, see [[http://blog.hvidtfeldts.net/][Syntopia]] again, or nearly anything by [[https://iquilezles.org/][Inigo Quilez]], or
+look up raymarching and sphere tracing, or see [[https://ntopology.com/][nTopology]], or Matt
+Keeter's work with [[https://www.libfive.com/][libfive]] and [[https://www.mattkeeter.com/research/mpr/][MPR]].  They're pure magic, they're
+wonderfully elegant, and I'll probably have many other posts on them.
+(TODO: Link to my CS6460 stuff)
 
 However, there is one big issue: turning implicit surfaces to good
-meshes for rendering /is a huge pain/, and while many renderers can
+meshes for rendering /is a huge pain/.  While many renderers can
 handle implicit surfaces directly, Blender's renderers cannot. I will
 have other posts going into more detail on this subject, but for now,
-take it on faith.  This is why I did not try to use implicit surfaces
-for this project.  (TODO: Make those posts.)
+take it on faith.  If you don't believe me, believe Matt Keeter in
+[[https://www.mattkeeter.com/research/mpr/keeter_mpr20.pdf][his paper]] when he says in a rather understated way, "Having implemented
+many of these algorithms, we've found it extremely difficult to make
+them robust." This is why I did not try to use implicit surfaces for
+this project.
+(TODO: Make those posts.)
 
 With these limitations in mind, around 2018 June I had started jotting
 some ideas down.  The gist is that I wanted to create
@@ -131,6 +167,9 @@ shaders)
 (TODO: Maybe split these off into sections for each one?  That'd make
 explanations/pictures easier.)
 
+(TODO: The whole blog post is about my meandering path and should
+probably include some Structure Synth things as part of this)
+
 I put some serious effort into [[https://github.com/Hodapp87/prosha][Prosha]] and was conflicted on shelving
 the project indefinitely, but the issues didn't look easily solvable.
 Part of those issues were implementation issues with Rust - not that