Sand Simulator's

Behind the Code: How We Built Sand Simulator's Unique Physics Engine

1. Introduction: The Art of Digital Granularity

Welcome to the technical side of Frolix! While many of our tools focus on visual aesthetics, our Sand Simulator is a deep dive into real-time particle physics rendered directly in your browser. As the core development team, we can attest that simulating granular materials—like sand—is far more complex than simulating liquids or simple rigid bodies. It requires a delicate balance between realism, computational efficiency, and a seamless user experience.

Our background in full-stack web development and a passion for HTML5 Canvas allowed us to custom-build this engine from scratch. This article serves as a technical breakdown, detailing the core challenges and unique solutions we implemented to make Frolix’s Sand Simulator one of the fastest and most stable web-based engines available. We aim to share our Expertise and the commitment to quality engineering that defines the Frolix platform.

2. The Challenge of Granular Dynamics in the Browser

When most people think of physics simulations, they often picture fluid dynamics—smooth, predictable movements of water or smoke. Sand, however, is a granular material. Its behavior is governed by highly localized, complex interactions between individual particles, known as granular dynamics. Unlike liquids, sand particles stop moving instantly when they find a stable resting angle, leading to piling, funneling, and specific angle-of-repose behaviors.

The main technical hurdle in a browser environment is the CPU load. We cannot simulate every single particle interacting with every other particle (an $O(N^2)$ problem) and maintain a smooth frame rate, especially when dealing with hundreds of thousands of particles. To keep performance near 60 frames per second (FPS), we had to completely ditch traditional physics engines. The solution was to create a highly optimized, cell-based algorithm that focuses only on a particle's immediate neighbors, prioritizing stability constraints and efficient neighbor detection over perfect, but slow, physical accuracy. This is the heart of our performance strategy.

3. Core Mechanics: The Optimized Grid System

To solve the $O(N^2)$ complexity problem, we implemented a sophisticated 2D Array Grid System. Every cell in this grid represents a fixed point on the Canvas. Instead of tracking the position of every particle individually across the entire screen, we only need to know which particle occupies which cell.

3.1. Spatial Hashing for Efficiency

The grid acts as a form of spatial partitioning (often called Spatial Hashing in simulation). When checking for movement or collision, a particle only checks the 8 cells immediately surrounding it. This drastically limits the number of calculations required per frame, reducing the complexity to a near $O(N)$ problem (linear time), which is crucial for web performance.

3.2. Data Structure and Material Lookup

Each cell in our 2D array stores a value indicating the material type (Sand, Water, Stone, Air). This allows for instant lookup and simplifies the logic for material interaction. For example, before a sand particle moves down, the code checks the cell directly below: if it contains 'Air,' the sand moves; if it contains 'Stone,' the sand stops.

3.3. Iteration Order for Stability

For visual stability, we iterate through the grid from bottom-up and randomly left-to-right/right-to-left. Iterating from the bottom ensures that particles that have already fallen in the current frame are properly settled before checking the particles above them, preventing visual jitter and unrealistic cascading failures.

4. Implementing Gravity, Settling, and Movement Rules

The movement of each particle is governed by a strict set of rules, processed sequentially in every frame. This is where the magic—and the realism—happens. A single sand particle prioritizes its movement attempts in the following order:

1. Check Down (Gravity): The particle always tries to move into the cell directly below it.

2. Check Diagonal-Down (Piling): If the cell directly below is occupied, the particle attempts to move diagonally (down-left or down-right). This attempt is randomized per frame to prevent grid bias and create natural-looking slopes and piles that maintain the required angle of repose.

3. Check Sideways (Liquids Only): For materials like Water, if the downward path is blocked, the particle then attempts to move sideways into any available cell, simulating flow and surface tension.

The moment a particle fails all its movement checks, it enters a "settled" state. This simple state machine logic is why the Sand Simulator feels responsive and stable.

5. Collision and Complex Material Interaction Logic

The interactions between different materials are handled by lookup tables and conditional logic. This is essential for preventing visual glitches and modeling complex behavior:

• Sand vs. Stone (Static): Stone is defined as an immovable object. Sand treats a Stone cell like the boundary of the grid—it simply stops and piles up on top of it.

• Sand vs. Water (Dynamic Swap): If a sand particle attempts to move into a cell occupied by water, the sand replaces the water, and the water particle attempts to move into the sand particle's old location. This simulates sand sinking to the bottom and water rising, modeling basic buoyancy.

• Solidification (Lava/Ice): For materials that change state (e.g., Lava), we implement a tick timer. Lava is programmed to check its neighboring cells. If it is surrounded by a sufficient number of 'Stone' or 'Cool Air' cells for a set number of frames, its material type automatically changes to 'Solid Stone,' simulating cooling and solidification.

This precise, programmatic approach to interaction ensures every combination of materials behaves predictably, increasing the overall quality and depth of the experience.

6. Optimizing for the Browser (UX and Performance)

Technical complexity is useless if the site runs slowly. Our development focus was heavily on User Experience (UX) and performance optimization:

• HTML5 Canvas Rendering: We rely exclusively on the HTML5 Canvas API. This is significantly faster than manipulating thousands of individual Document Object Model (DOM) elements, as it allows us to render the entire grid as a single image manipulation per frame.

• Dirty Rectangles: A major performance hack is using dirty rectangles (or localized redrawing). Instead of redrawing the entire canvas every frame (which is slow), the engine only identifies and redraws the small rectangular areas of the screen where movement or change has occurred. This minimizes GPU usage and maximizes FPS.

• Input Handling: The drawing input is decoupled from the physics loop. The input (user drawing) simply marks the cells in the 2D array, which the physics loop then processes, ensuring that user interaction never slows down the simulation itself.

7. Conclusion and Future Development

Building the Sand Simulator engine has been a rewarding challenge, blending creative concepts with rigorous technical execution. This project is a testament to what is possible using modern web technologies when prioritizing efficient code and smart algorithms.

The engine is constantly being refined. Future updates will focus on implementing full multi-threading (using Web Workers) to push particle count limits even higher, and introducing more complex material states like gas dynamics.

We invite you to experience the results of this engineering effort. Head over to the simulator now and start experimenting!