Grid.Space Applications

repository·master·Indexed 21 days ago

https://github.com/gridspace/grid-apps

Browser-based and desktop tools for 3D printing (Kiri:Moto), CNC milling, laser cutting, and mesh repair (Mesh:Tool). Version 4.7.0 provides Javascript Slicing APIs for G-code generation and asynchronous slicing, along with a modular framework for initializing applications via @gridspace/app-server.

Tokens
62.8K
Snippets
133
Records
237
Agent score
75%

What's inside grid-apps

  1. Overview of GridBot 3D Printer

    master

    GridBot is an open-source, Core-XY, FDM 3D printer designed with a lightweight yet rigid structure. The design features an enclosed aesthetic by housing motors and rails inside the frame, which facilitates the addition of an enclosure.

    Key resources:

    • CAD Models: Publicly available in Onshape.
    • Control Software: A custom GCode sender optimized for the Raspberry Pi 7" touchscreen, hosted on GitHub.
    • Community Support: Progress updates and build discussions are hosted on the Grid.Space forum.
  2. Overview of Grid.Space Applications

    master
    Grid.Space provides free, open-source, and open-design applications and hardware designed for makers. The ecosystem includes browser-based tools for manufacturing and open-source hardware projects for DIY enthusiasts.
  3. Workflow Overview for Kiri:Moto CAM Mode

    master

    Kiri:Moto's CAM (Computer Aided Manufacturing) mode is a browser-based workflow for subtractive manufacturing, such as CNC milling. The workflow follows a linear progression:

    1. Arrange: Import models and position them on the workspace.
    2. Slice: Generate toolpaths based on CAM operations.
    3. Preview: Inspect toolpaths, speeds, and offsets to detect collisions or gouges.
    4. Animate: Visualize tool movement through the stock to verify depth and path accuracy.
    5. Export: Generate G-code for the machine.

    Note: Changing profile options, machine settings, or tool library settings after slicing will require you to re-slice the model to update the toolpaths.

  4. How the Selection and Hover System works

    master

    Selection is handled by a unified SelectionResolver pipeline that takes ray hits, the current mode, and an intent mask as input to produce ranked candidates.

    Ranking Rules

    Candidates are ranked by proximity and containment:

    1. Point proximity: Always wins if within the threshold.
    2. Segment: Wins if the distance-to-curve is below the threshold.
    3. Boundary/Region: Wins if the cursor is inside the region and not near a point or segment.
    4. Surface: Wins if no other entity is hit.

    Mode-Specific Intent Masks

    Different application modes restrict what can be selected:

    • Sketch mode: point, segment, boundary, surface(region projection)
    • Extrude mode: region only
    • Chamfer mode: segment only (includes face-to-edge expansion)
    • Boolean mode: surface/body selection groups
  5. Understand the Geometric Chamfer Pipeline

    master

    Unlike the legacy boolean method which subtracts a cutter prism from a solid, the geometric_offset chamfer is a topology and geometry transform. It follows a five-stage pipeline to ensure watertight, manifold results without the fragility of boolean operations:

    1. Topology Extraction: Builds edge-to-incident-face adjacency and identifies valid manifold edges.
    2. Per-Edge Offset Construction: Computes incident face normals, constructs offset planes, and determines the chamfer line via plane-plane intersection.
    3. Face Trimming + Insertion: Trims original faces against the new chamfer boundaries and inserts new chamfer quad/tri strip faces.
    4. Vertex Corner Solver: Solves multi-edge vertex neighborhoods (2-edge, n-edge star, etc.) by calculating intersection polygons in a tangent frame to create watertight corner patches.
    5. Rebuild + Mapping: Rebuilds the indexed mesh and recomputes boundary segments and canonical edge references while preserving provenance.
  6. Automatic settings persistence in Onshape

    master
    When accessing Kiri:Moto from within the Onshape environment, settings are automatically persisted on the Onshape server and associated with your Onshape User ID. This ensures that your configuration is automatically imported whenever you access Kiri:Moto from a different computer while logged into Onshape.
  7. How Void Constraints V2 works (Planegcs-First Architecture)

    master

    The Void Constraints V2 architecture moves from a dual-solver model to a planegcs-first model. In this architecture, planegcs is the primary and default solver for all live interactions (like dragging) and final settling. The fallback solver is no longer applied unconditionally; it is retained only as a failure recovery mechanism when planegcs fails to converge or returns a non-converged status.

    Key Concepts:

    • Primary Solver: planegcs handles all geometry shaping.
    • Fallback Solver: Used only for failure recovery.
    • Temporary Constraints: During drag interactions, the system uses constraints with temporary: true. These provide guidance (e.g., point-to-point or point-to-line) to the cursor or ghost references without causing permanent topology mutations.
    • Tangency: Tangent constraints are mapped into planegcs natively. For shared-endpoint tangency, the system uses the angle_via_point solver binding with an angle of 0 to ensure stability.
  8. Understand the Core Model for Void Derived Sketch Entities

    master

    In the Void system, derived sketch entities are designed to be deterministic, immutable projections of upstream geometry. They function similarly to how solids rebuild from sketches: the upstream geometry acts as the single source of truth, and derived entities are read-only projections that store metadata and source links to enable automatic rebuilding.

    Key Concepts

    • Source of Truth: Upstream geometry (e.g., solids, faces, or loops) drives the state.
    • Read-Only Projections: Derived entities cannot be directly manipulated (dragged, moved, or reshaped).
    • Deterministic Rebuilds: Entities are regenerated based on their source links and the target sketch plane whenever upstream geometry changes.
  9. Nibble-coded RLE4 Encoding (PW0/PWX/Modern Anycubic)

    master

    The PW0, PWX, and all modern Anycubic formats (v515+) use Nibble-coded RLE4 encoding. This is a variable-length format where each byte is split into a 4-bit code and a 4-bit repeat value.

    Encoding Rules:

    • Black (0x0): Extended format (2 bytes). Format: [0x0R] [RR]. Repeat is a 12-bit value: (R << 8) | RR (max 4095).
    • White (0xF): Extended format (2 bytes). Format: [0xFR] [RR]. Repeat is a 12-bit value: (R << 8) | RR (max 4095).
    • Grayscale (0x1-0xE): Single byte format. Color = (code << 4) | code. Repeat = 4-bit value (1-15).

    Example Encodings:

    • White (1000 pixels): F3 E8 (Code 0xF, Repeat (3 << 8) + 232 = 1000)
    • Black (500 pixels): 01 F4 (Code 0x0, Repeat (1 << 8) + 244 = 500)
    • Gray (0x77, 10 pixels): 7A (Code 0x7, Repeat 0xA = 10)
    • Gray (0xAA, 5 pixels): A5 (Code 0xA, Repeat 0x5 = 5)
    for (int i = 0; i < encodedRle.Length; i++)
    {
        byte b = encodedRle[i];
        int code = b >> 4;        // Upper nibble
        int repeat = b & 0xf;    // Lower nibble
        byte color;
    
        switch (code)
        {
            case 0x0:  // Black (extended)
                color = 0;
                i++;
                repeat = (repeat << 8) + encodedRle[i];
                break;
    
            case 0xf:  // White (extended)
                color = 255;
                i++;
                repeat = (repeat << 8) + encodedRle[i];
                break;
    
            default:   // Grayscale (single byte)
                color = (byte)((code << 4) | code);
                break;
        }
    
        // Fill repeat pixels with color
    }