wip

Author: acharneski

_config.yml

@@ -14,6 +14,7 @@ lang: en
 markdown: kramdown
 theme: minima
 mathjax: true
+mermaid: true
 highlighter: rouge
 exclude:
   - Gemfile

_layouts/post.html

@@ -196,5 +196,40 @@ <h3>Related Posts</h3>
         addRandomGlitch();
     }
 </script>
+
+<!-- Mermaid.js integration -->
+{% if page.mermaid or site.mermaid %}
+<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
+<script>
+    document.addEventListener('DOMContentLoaded', function() {
+        mermaid.initialize({
+            startOnLoad: false, // Disable automatic start
+            theme: 'default', // or 'dark', 'forest', 'neutral'
+            securityLevel: 'loose', // Use 'loose' if you have complex diagrams or external links
+            // Add other configuration options as needed
+        });
+        // Transform fenced code blocks with class 'language-mermaid' into mermaid divs.
+        // Jekyll/Kramdown with Rouge highlighter typically places the 'language-mermaid' class on the <code> tag,
+        // not the <pre> tag. This script finds the <code> tag, extracts its content,
+        // and replaces its parent <pre> tag with a new <div class="mermaid">.
+        document.querySelectorAll('code.language-mermaid').forEach(function(codeElement) {
+            const mermaidDiv = document.createElement('div');
+            mermaidDiv.className = 'mermaid';
+            mermaidDiv.textContent = codeElement.textContent; // Get the raw diagram definition
+
+            const preElement = codeElement.parentNode; // The <pre> tag is the parent of the <code> tag
+            if (preElement && preElement.tagName === 'PRE') {
+                preElement.parentNode.replaceChild(mermaidDiv, preElement);
+            } else {
+                // Fallback: if for some reason the parent isn't a <pre>, replace the code element itself
+                codeElement.parentNode.replaceChild(mermaidDiv, codeElement);
+            }
+        });
+        // Manually run Mermaid after transformations
+        mermaid.run();
+    });
+ </script>
+ {% endif %}
+
 </body>
 </html>

_posts/creative_writing/2025-11-24-constrained-voxel-gears.md

@@ -0,0 +1,234 @@
+---
+title: "Kinematic Voxel Carving: A Framework for Procedural Mechanism Synthesis"
+layout: "post"
+date: 2025-11-24
+last_modified: 2025-11-24 10:00:00
+
+category: creative_writing
+subcategory: "Generative Design"
+tags:
+  - Optimization
+  - Computational-Analysis
+  - Mathematical-Modeling
+  - Topology
+  - Robotics
+  - Technical-Report
+  - Research-Paper
+  - Full-Implementation
+  - Future-Projections
+  - Industry-Applications
+  - Voxel-Based Topology Optimization
+  - Kinematic Subtraction
+  - Cellular Automata
+  - Multigrid Approach
+  - Gears
+  - Mechanisms
+  - 3D Printing
+  - Generative Design
+  - Computational Geometry
+keywords:
+  - voxel carving
+  - kinematic synthesis
+  - procedural generation
+  - 3D mechanisms
+  - gears
+  - cellular automata
+  - topology optimization
+  - print-in-place
+  - digital fabrication
+  - computational design
+  - mechanical engineering
+
+status: "stable"
+last_thought_date: 2025-11-24
+thought_generation: 1
+
+difficulty_level: "advanced"
+reading_time_minutes: 6 # Estimated based on ~1500 words
+
+document_type: "framework"
+thinking_style: 
+  - "analytical"
+  - "mathematical"
+  - "experimental"
+engagement_type: "analytical"
+reader_participation: "passive"
+cognitive_load: "intense"
+
+# Discovery & SEO
+description: "A computational framework for generating 3D mechanical linkages like gears and kinematic couplings using voxel-based topology optimization and kinematic subtraction."
+excerpt: "This document outlines a novel computational framework for generating complex 3D mechanical linkages, such as gears and kinematic couplings, through Voxel-Based Topology Optimization. By simulating kinematic constraints within a discretized voxel grid, the system 'discovers' optimal mechanical shapes, enabling the creation of non-standard gears, print-in-place mechanisms, and organic linkages difficult to design with traditional CAD."
+featured_image: "/assets/images/constrained-voxel-gears.png"
+og_image: "/assets/images/constrained-voxel-gears-social.png"
+meta_title: "Kinematic Voxel Carving: Procedural Mechanism Synthesis Framework"
+meta_description: "Explore a framework for generating 3D mechanical gears and linkages using voxel-based topology optimization, kinematic subtraction, and cellular automata for digital fabrication."
+meta_keywords: "voxel carving, kinematic synthesis, procedural generation, 3D mechanisms, gears, cellular automata, topology optimization, print-in-place, digital fabrication, computational design, mechanical engineering"
+og_title: "Kinematic Voxel Carving: A Framework for Procedural Mechanism Synthesis"
+og_description: "Discover a novel approach to designing complex 3D mechanical linkages through simulated kinematic constraints and voxel-based topology optimization."
+og_type: "article"
+og_locale: "en_US"
+og_site_name: "Fractal Thought Engine"
+schema_type: "TechArticle"
+schema_headline: "Kinematic Voxel Carving: A Framework for Procedural Mechanism Synthesis"
+schema_author: "AI Assistant"
+schema_publisher: "Fractal Thought Engine"
+schema_date_published: 2025-11-24
+schema_date_modified: 2025-11-24
+schema_image: "/assets/images/constrained-voxel-gears-schema.png"
+schema_word_count: 1500
+schema_reading_time: "PT6M"
+canonical_url: "https://fractalthoughtengine.com/creative_writing/constrained-voxel-gears"
+robots: "index,follow"
+googlebot: "index,follow"
+bingbot: "index,follow"
+content_rating: "general"
+content_language: "en"
+geo_region: "Global"
+priority: 0.8
+changefreq: "monthly"
+sitemap_exclude: false
+search_exclude: false
+is_featured: true
+is_cornerstone: true
+is_gateway: true
+is_synthesis: true
+---
+
+# Kinematic Voxel Carving: A Framework for Procedural Mechanism Synthesis
+
+## 1. Abstract
+This document outlines a computational framework for generating 3D mechanical linkages—specifically gears and kinematic couplings—using **Voxel-Based Topology Optimization**. Unlike traditional CAD methods that rely on analytical geometry (e.g., involute curves), this system "discovers" optimal mechanical shapes by simulating the kinematic constraints of rotating or moving bodies within a discretized voxel grid.
+
+By defining the motion paths and bounding volumes of two or more bodies, the system iteratively solves for a configuration where bodies maximize their volume without violating spatial constraints. This approach enables the creation of non-standard gears, print-in-place locking mechanisms, and complex organic linkages that are mathematically difficult to describe but physically functional.
+
+---
+
+## 2. Core Philosophy
+The central thesis of this engine is **Kinematic Subtraction over Time** combined with **Cellular Automata (CA) Smoothing**.
+
+1.  **Implicit Definition:** We do not draw teeth. We define *motion* and *volume*. The teeth are the emergent result of these definitions.
+2.  **Resolution Agnostic:** The physics are solved at a coarse level first. High-fidelity details are only calculated where necessary (at the interface surfaces).
+3.  **Structural Emergence:** Connectivity and structural integrity are enforced via local neighbor rules (CA), preventing "floating islands" of geometry.
+
+---
+
+## 3. System Architecture
+
+### 3.1. The Body Definition
+A "Body" is a container for a voxel grid and its kinematic properties.
+*   **Extent (Bounding Volume):** The maximum possible shape of the object (e.g., a cylinder, a cone, a torus, or an arbitrary mesh).
+*   **Kinematic Frame:** A function $T(t)$ that returns a $4\times4$ transformation matrix (Rotation + Translation) for any given time $t$.
+*   **Symmetry Constraints:** Rules defining required repetition (e.g., "Radial Symmetry: 8" implies that if voxel $V$ exists, $V_{rotated}$ must also exist).
+
+### 3.2. The Voxel Grid
+Instead of a Cartesian grid or Octree, the system utilizes a **Cylindrical Voxel Grid** optimized for rotational bodies.
+*   **Geometry:** Voxels are defined in cylindrical coordinates $(r, \theta, z)$. Each voxel is a "slice of cake" (a frustum of a sector) defined by a range for radius $r$, angle $\theta$, and height $z$.
+*   **State:** Each voxel holds a state: `SOLID`, `EMPTY`, or `UNKNOWN` (during solving).
+*   **Metadata:** Each voxel may store `FitnessScore` or `ConstraintViolationCount`.
+
+---
+
+## 4. The Solver Engine
+
+The solver operates in a loop of **Constraint Application** and **Volume Optimization**.
+
+### 4.1. The Constraint Matrix
+The fundamental rule is: *Two bodies cannot occupy the same point in World Space at the same time $t$.*
+
+Let $V_A$ be a voxel in Body A and $V_B$ be a voxel in Body B.
+For a full rotation cycle $t \in [0, 360^\circ]$:
+1.  Transform $V_A$ to World Space: $P_{world} = T_A(t) \cdot V_A$.
+2.  Transform $P_{world}$ into Body B's local space: $P_B = T_B(t)^{-1} \cdot P_{world}$.
+3.  If $P_B$ lands inside a voxel coordinate currently marked `SOLID` in Body B, a **Constraint Violation** is recorded.
+
+### 4.2. Optimization Strategy (Maximally-Filled)
+We do not simply subtract B from A. We want *both* to be as large as possible to ensure strength.
+*   **Heuristic:** If a collision occurs, which voxel do we delete?
+*   **The "Center of Mass" Bias:** Voxels closer to the kinematic axis of their respective body are weighted higher. We prefer to delete voxels at the periphery (teeth tips) rather than the core (hub).
+*   **Symmetry Enforcement:** If we delete voxel $V$, we must immediately delete all its symmetric counterparts to maintain balance.
+
+### 4.3. Handling Locking and Interference
+*   **Standard Gears:** The solver removes all collisions, resulting in smooth running.
+*   **Locking Mechanisms:** If the user desires a lock (e.g., a ratchet), the kinematic definition includes a "Stop" phase. The solver will carve geometry that permits rotation up to a point, then physically collides (locks) because no valid subtraction exists to allow further movement without destroying the core volume.
+
+---
+
+## 5. Iterative Resolution & Refinement
+
+To make this computationally feasible, we use a **Multigrid Approach**.
+
+### Phase 1: Coarse Solve
+*   **Grid Size:** Low (e.g., $32^3$ voxels).
+*   **Action:** Solve the kinematic constraints.
+*   **Result:** Blocky, Minecraft-like gears that roughly mesh.
+
+### Phase 2: Boundary Detection
+*   Identify **Surface Voxels**: Any `SOLID` voxel adjacent to an `EMPTY` voxel.
+*   Identify **Interaction Zones**: Any voxel in Body A that comes within distance $D$ of Body B during the rotation cycle.
+*   **Optimization:** We *only* care about these zones. The internal volume of the gear is static.
+
+### Phase 3: Sub-division (Refinement)
+*   Subdivide the Surface Voxels into $2 \times 2 \times 2$ smaller voxels.
+*   Re-run the Constraint Solver *only* on these new smaller voxels.
+*   Repeat this process until the desired physical resolution (e.g., 0.1mm for 3D printing) is reached.
+
+---
+
+## 6. Cellular Automata (CA) & Structural Integrity
+
+Raw kinematic subtraction often leaves "floating islands" (debris) or impossibly thin connections. We solve this using **Voxel Neighborhood Fitness Functions** akin to Cellular Automata rules.
+
+**The "Life" Rules for Mechanical Voxels:**
+After every constraint pass, run a CA simulation:
+
+1.  **The Island Rule:** If a voxel has 0 neighbors, it dies (becomes `EMPTY`).
+2.  **The Strut Rule:** If a voxel has only 1 neighbor, it is structurally weak. It either dies (pruning) or triggers a "growth" event to connect to a nearby solid (reinforcement), depending on user settings.
+3.  **The Smoothing Rule:** If an `EMPTY` voxel is surrounded by $\ge 6$ `SOLID` neighbors, it becomes `SOLID` (filling internal voids).
+4.  **The Axis Anchor:** Voxels touching the central rotation axis are immutable (infinite fitness). Connectivity is traced from the axis outward. Any voxel not connected to the axis via a chain of neighbors is culled.
+
+---
+
+## 7. Potential Applications
+
+This engine allows for the generation of mechanisms that are difficult to design in CAD:
+
+1.  **Non-Parallel Axis Gears:**
+    *   Simply define Axis A as vertical and Axis B as tilted $45^\circ$. The solver will naturally carve **Hypoid** or **Bevel** geometries without the user needing to know the complex math.
+2.  **Variable Ratio Gears:**
+    *   Define the rotation speed of Body A as constant, and Body B as a sine wave. The system will generate **Non-Circular Gears** (elliptical/nautilus gears).
+3.  **Print-in-Place Assemblies:**
+    *   Define a "gap tolerance" (e.g., 2 voxels). The solver ensures that even at the tightest mesh point, there is a physical gap, allowing the mechanism to be printed pre-assembled and fused, then broken free.
+4.  **Internal/Cavity Gears:**
+    *   Body A is a sphere, Body B is a star shape inside it. The system generates a 3D internal track mechanism.
+
+---
+
+## 8. Implementation Roadmap
+
+### Step 1: The Data Structure
+*   Implement a cylindrical voxel grid class.
+*   Implement basic geometric primitives (Cylinder, Cube) to populate the grid.
+
+### Step 2: The Kinematic Loop
+*   Implement the "Time Step" loop.
+*   Implement Matrix transformations for voxels.
+*   Create a visualizer (Point cloud or basic mesh) to debug the "Swept Volume."
+
+### Step 3: The Constraint Solver (Coarse)
+*   Implement the collision detection logic.
+*   Implement the "Delete" logic (Boolean subtraction).
+*   Implement Symmetry mirroring.
+
+### Step 4: The CA Post-Processor
+*   Implement the "Flood Fill" algorithm to detect disconnected islands.
+*   Implement the neighbor-count pruning rules.
+
+### Step 5: Refinement & Meshing
+*   Implement the Cylindrical subdivision for boundary voxels (splitting $r, \theta, z$).
+*   Implement **Dual Contouring** or **Marching Cubes** to convert the final voxel state into an STL/OBJ file.
+*   Add Laplacian Smoothing to the final mesh to remove "voxel stepping" artifacts.
+
+---
+
+## 9. Conclusion
+This document describes a generative design engine that trades analytical precision for simulation-based robustness. By treating mechanical design as a space-time constraint problem, we can automate the creation of complex, functional, and novel mechanisms ready for digital fabrication.