Recreating Scroll-Driven Particle Effects to Evaluate AI Coding Models

1. Why Replicating Motion at the Pixel Level Is a Strong Test

When evaluating AI coding models, tasks such as “build a to-do list” or “implement a login form” rarely separate strong models from weaker ones. These requirements have abundant training data, and most models can produce structurally correct answers. The tasks that create meaningful separation are those with clear goals but unknown implementation paths.

Recreating a high-quality scroll-driven animation is a good fit:

• The result is binary. Visual similarity can be judged directly; there is little room for code that looks elegant but produces an unclear result.
• The process is opaque. The target page’s scripts are usually minified, split into bundles, and loaded on demand, so the model must choose its own analysis strategy.
• The details are enumerable. Particle count, interpolation coefficients, easing curves, and mouse interaction radius each accumulate into visible differences.
• Engineering constraints are hard. Frame rate, memory usage, time to interactive, and behavior across viewports cannot be hidden by “looks right.”

The task in this evaluation was a hero animation for a landing page: a vortex-like galaxy made of many tiny light points. As the page scrolls, the particles switch between forming a specific glyph or logo and dispersing into stardust. When the mouse moves across the effect, the particles receive a repulsion disturbance and spring back after the cursor leaves. Three coding models from different vendors were tested under identical requirements, with no reference implementation provided.

2. Requirements: Define What Is Needed, Not How to Build It

The prompt given to the models should constrain only the goal and acceptance criteria, leaving the implementation path to the model. The requirement structure used here is reusable:

1. Reference artifact: provide an accessible URL for the target page.
2. Behavior definition: the particles must aggregate and disperse with scrolling, the aggregated state must form a specific graphic, the dispersed state must appear as stardust, and mouse hover must trigger interaction.
3. Method authorization: the model may load the page in a browser to obtain scripts and assets, or use screenshots for visual analysis; the method is left to the model.
4. Deliverable: produce a standalone runnable demo page.

One notable result was that all three models chose the path of “use a browser to fetch resources.” None actively used system-level graphical interface automation. This choice is reasonable: once the page loads in a browser, scripts, styles, fonts, and images are already cached locally. Analyzing source code directly has a much higher signal-to-noise ratio than estimating from screenshots. This also suggests that, when capability boundaries are clear, models tend to choose the path with the highest information gain rather than the most visually impressive path described in the task.

3. Three Technical Approaches and Their Trade-offs

Recreating this kind of motion usually involves three practical approaches, each with a different cost:

Approach	Information completeness	Main risk
Directly reuse the original site’s scripts	Highest	Minification, obfuscation, bundled loading, and build artifacts often make the code unreadable and hard to run standalone
Rebuild from visual comparison	Medium	Depends on screenshot quality; dynamic processes are difficult to recover; may only replicate static frames
Infer motion parameters	Medium-high	Requires frame-by-frame measurement and a patient, methodical analysis process

In practice, the best result is often hybrid: use source-code analysis to determine the technical route (Canvas 2D, WebGL, or DOM transforms), use visual comparison to calibrate appearance, and use parameter inference to recover easing curves and thresholds. Relying on only one approach is risky. Looking only at source code may be misled by obfuscated code; looking only at screenshots may turn the animation into a frame-by-frame animation; adjusting only by feel can lead to endless tuning without convergence.

4. Breaking Down the Core Implementation

Regardless of the technology stack, this kind of effect can be divided into five largely orthogonal parts. Understanding this breakdown helps with implementation and also makes it easier to identify where a model’s output goes wrong.

4.1 Sampling the Target Shape

The aggregated state is a concrete shape, such as a glyph or logo. The first step is to turn it into a set of coordinate points: render the shape to an offscreen canvas, read the pixel data, scan the alpha channel at a fixed step, and record every pixel above the threshold.

function sampleShape(shapeCanvas, step = 3) {
  const { width, height } = shapeCanvas;
  const ctx = shapeCanvas.getContext('2d');
  const data = ctx.getImageData(0, 0, width, height).data;
  const points = [];
  for (let y = 0; y < height; y += step) {
    for (let x = 0; x < width; x += step) {
      const alpha = data[(y * width + x) * 4 + 3];
      if (alpha > 128) points.push({ x, y });
    }
  }
  return shuffle(points); // Shuffle the order to prevent a visible row-by-row scan effect
}

Two easily overlooked details matter here. The sampling step directly determines the total particle count and visual density. The sampling order must be shuffled; otherwise, the aggregation process looks like a row-by-row fill and immediately reads as machine-generated.

4.2 Mapping Scroll Progress

Do not bind the scroll position directly to particle coordinates. First normalize the page’s scroll range into a 0→1 progress value, then pass it through an easing function:

const raw = (scrollY - startY) / (endY - startY);
const progress = easeInOutCubic(clamp(raw, 0, 1));

The choice of easing curve determines whether the aggregation feels crisp or sluggish. A common mistake is to use a fully linear mapping, which makes the middle section feel flat and rhythmically weak.

4.3 Frame Loop and Interpolation

On each frame, particles should move toward their target positions with damping rather than being assigned directly. This is a major source of the “premium” feel:

function tick() {
  const k = 0.08;                       // Damping factor; smaller values feel “stickier”
  for (const p of particles) {
    const tx = lerp(p.scatterX, p.targetX, progress);
    const ty = lerp(p.scatterY, p.targetY, progress);
    p.x += (tx - p.x) * k;
    p.y += (ty - p.y) * k;
  }
  render();
  requestAnimationFrame(tick);
}

The initial positions in the dispersed state also need design. A purely random distribution looks messy. To obtain the appearance of a rotating galaxy, particles can be distributed in polar coordinates around a rotation center, with each particle given a small orbital angular velocity.

4.4 Mouse Interaction Field

Interaction should not be simple collision detection. It should be a field with falloff: use the cursor as the center, apply repulsion inversely related to distance within a given radius, and retain an “original position” for each particle so it can return after the cursor leaves. If the radius is too large, the entire particle field is pushed away; if it is too small, the interaction is almost imperceptible. Tuning usually requires repeated trials on real screens.

4.5 Performance and Degradation

• Limit the maximum device pixel ratio, for example to no more than 2. Otherwise, pixel fill cost rises sharply on high-density screens.
• Calculate particle count dynamically based on viewport area, and degrade proactively on mobile.
• Pause the frame loop when the page is not visible. When scrolling is idle and particles have converged, the system can enter a low-power mode.
• Provide prefers-reduced-motion support and show a static aggregated state for users sensitive to motion.

5. The Gap Between “Looks Like” and “Feels Like”

The first round of output usually captures the general direction, but direct comparison with the original often reveals clear differences. These differences tend to cluster into a few categories:

• Inaccurate shape: the glyph outline is sampled too coarsely, intersections blur together, or the overall proportions are stretched.
• Missing motion quality: without damping and easing, aggregation and dispersion feel like teleporting rather than flowing.
• Incorrect rhythm: the mapping between scroll progress and visual change is not tuned; one full screen of scrolling may still leave the effect only half-aggregated.
• Broken interaction: the mouse effect behaves incorrectly on touch devices, or event listeners are not throttled.
• Robustness issues: sampled coordinates become invalid after window resizing, particles fly off canvas without being recycled, or memory grows during long sessions.

Fixing these gaps with vague instructions such as “optimize it a bit more” is usually ineffective. A more effective follow-up is to locate issues one by one:

Compare the reference implementation with your output, and check and fix the following in order:
1. Are the strokes of the aggregated shape continuous and proportional to the original?
2. Does position updating use damped interpolation instead of direct assignment?
3. Is scroll progress mapped through an easing function?
4. Are target points resampled after a window resize?
5. Is the device pixel ratio limited, and does rendering pause when the page is not visible?
For each fix, explain the parameter values and the rationale behind them.

6. Scoring Framework for This Kind of Task

If the goal is to turn “feel” into reusable conclusions, a five-dimension scoring framework works well. Each item is scored from 0 to 2, for a maximum of 10 points:

1. Shape fidelity: whether the aggregated graphic is recognizable and whether its proportions match the original.
2. Motion fidelity: whether damping, easing, and the rhythm of aggregation/dispersion match the original.
3. Interaction completeness: whether hover repulsion and rebound feel natural and whether touch devices are supported.
4. Engineering robustness: whether resizing, orientation changes, low-end devices, and long-running sessions remain stable.
5. Deliverability: whether the result truly runs standalone, without redundant dependencies or hard-coded assumptions.

Using this framework to compare multiple models produces more reliable conclusions than statements such as “I think A is better.” It also helps identify specific weaknesses: some models reproduce the visuals well but have weak performance awareness, while others have clear architecture but are insensitive to motion details.

7. Reusable Practices

• Specify acceptance criteria in the requirement, not a list of implementation methods. The more open the methods are, the better it is to observe how the model chooses its own path.
• Ask the model to analyze before it implements. Requiring it to explain technology choices and key parameters can significantly reduce later rework.
• Use screenshot comparisons instead of text-only descriptions for iterative feedback. For visual tasks, communication cost drops significantly.
• Write engineering constraints into the requirement: target frame rate, minimum supported viewport, and whether a degradation path is needed. These are the parts models most often ignore by default.
• Keep a manual acceptance checklist. Automated tests are unlikely to cover “feel,” and this part still requires human judgment.

Summary

A scroll-driven particle aggregation and dispersion effect is a strong evaluation sample because it converts aesthetic judgment into a decomposable, quantifiable, and reproducible engineering problem. The differences between models often lie not in whether they can write code, but in whether they understand how invisible parameters such as damping, easing, and sampling density jointly determine the final feel. For developers, breaking the task down to this level is both a reliable way to evaluate models and the most practical approach when implementing this kind of animation themselves.