Smoothing, Clamping & Speed Limiting: Cleaning Up an Auto-Generated Funscript

A practical, tool-agnostic workflow for cleaning up AI-generated funscripts: smoothing with Savitzky-Golay, clamping to device limits, speed-limiting spikes, and spot-fixing. Plus how HaptiQ's built-in editor and quality score streamline the entire process.

Why Every Auto-Generated Funscript Needs a Cleanup Pass

AI-powered funscript generators have transformed how haptic content gets made. What once required hours of manual keyframing now happens in minutes. But the reality every creator learns quickly: machine-generated scripts are a starting point, not a finished product. Motion detection algorithms catch the action, yet they also inherit noise, produce physically impossible movements, and create speed spikes that devices cannot execute.

The gap between "generated" and "good" is where cleanup lives. This guide walks through a proven, tool-agnostic workflow for refining auto-generated scripts—smoothing motion curves, clamping to hardware limits, and capping dangerous speeds—then shows how HaptiQ's integrated editor collapses these steps into a single, efficient pipeline.

The Four-Stage Cleanup Workflow

Regardless of which generator you use, the cleanup process follows the same sequence. Each stage solves a specific class of problem that raw AI output introduces.

Stage 1: Smoothing Motion Curves

Raw motion detection produces jagged position data. Frame-to-frame variance creates audible mechanical noise, feels stuttery, and wastes device bandwidth on micro-corrections that do not improve sensation.

Savitzky-Golay filtering is the standard solution. Unlike simple moving averages that flatten peaks, Savitzky-Golay preserves the timing and amplitude of actual motion events while removing high-frequency noise. It fits low-degree polynomials to successive windows of data points, producing smoothed curves that maintain phase accuracy.

Parameters to tune:

Apply smoothing before any other transform. Once you clamp or speed-limit, you have destroyed the original curve geometry that smoothing algorithms expect.

Stage 2: Clamping to Device Range

Funscript position values range 0-100, but not all devices map equally. Some hardware bottoms out mechanically before 0 or tops out before 100. Others have firmware limits that reject extreme values.

Clamping constrains output to your specific device's usable range. Common patterns:

Clamp after smoothing. Pre-smoothing clamping creates artificial flat zones that smoothers then distort. Post-smoothing clamping simply truncates the already-clean curve at your chosen floor and ceiling.

Stage 3: Speed Limiting Spikes

This is where most auto-generated scripts fail hardest. Motion detection sees rapid on-screen movement and translates it to instantaneous position changes. Devices have physical inertia and motor torque limits. Attempting impossible speeds produces:

Speed limiting enforces maximum velocity between any two consecutive points. The calculation is straightforward: for each interval, compute (position_delta / time_delta) and cap it at your device's sustained capability.

Device-specific speed limits to consider:

Implementation matters. Naive speed limiting shifts timing—if point B is too fast, move it later. This desynchronizes from video. Better algorithms interpolate additional points to maintain speed while preserving the original timestamp grid, or redistribute velocity across a small window to absorb spikes without visible drift.

Apply speed limiting after clamping. Clamping can create artificial speed spikes at the boundaries (a smooth curve hitting 100 and flattening produces infinite instantaneous velocity at the corner). You want to catch those.

Stage 4: Spot-Fixing Remaining Issues

Automated transforms handle 90% of cleanup, but edge cases remain:

Spot-fixing requires manual timeline editing. Efficient workflows depend on keyboard-driven navigation, rubber-band selection for bulk operations, and non-destructive preview so you hear/feel changes immediately.

Tool-Implementation Options

The workflow above can be executed across several tool categories:

Standalone Script Processors

Command-line tools and dedicated apps apply transforms to existing .funscript files. These work with any generator's output but require export/import cycles and offer limited manual editing.

Player-Integrated Editors

Some VR players include basic funscript editing. Convenient for quick fixes, but typically lack advanced transforms (Savitzky-Golay, intelligent speed limiting) and multi-axis support.

Full Pipeline Integration

HaptiQ's approach embeds cleanup directly in the generation flow. The same pipeline that produces the initial script—frame extraction through OpenCV optical flow, region-of-interest analysis, and funscript generation—feeds into a post-processing stage with smoothing, clamping, and speed limiting applied before export.

The integrated timeline editor provides 20+ keyboard shortcuts, rubber-band selection for multi-point operations, and 14 transform plugins including the Savitzky-Golay and speed-limit operations described above. Multi-axis T-code support (L0-L2, R0-R2, V0, A0) means cleanup applies consistently across all channels.

Real-time WebSocket progress updates show per-stage status without browser refresh, so you know when processing completes and can immediately enter cleanup.

Quality Scoring: Knowing When You're Done

Cleanup termination is subjective without metrics. HaptiQ's quality score analyzes the processed script against device-specific capability models, flagging:

The score updates live as you edit, giving objective feedback on whether additional passes are needed. This replaces guesswork—"does this feel smooth enough?"—with measurable targets.

Export and Compatibility

Cleaned scripts export as standard .funscript files, compatible with third-party players including DeoVR, HereSphere, XBVR, and ScriptPlayer. The device connectivity layer (Web Bluetooth for 806+ Bluetooth LE devices, Buttplug.io v3, The Handy's HAMP/HDSP/HSSP protocols, JoyHub cloud relay) is separate from script format—your cleaned file works wherever .funscript is supported.

Common Pitfalls

Smoothing too aggressively: Over-large Savitzky-Golay windows erase intentional fast strokes, making content feel muted. Match window size to content pace.

Speed limiting without interpolation: Simply deleting or delaying points destroys sync. Ensure your tool inserts interpolated points or redistributes velocity.

Wrong clamp order: Clamping before smoothing creates artifacts at boundaries. Always smooth first.

Ignoring device variation: A script cleaned for The Handy may still violate OSR2+ servo limits. Maintain device profiles and re-process when switching hardware.

Try HaptiQ

HaptiQ runs the complete pipeline—from video to cleaned, quality-scored funscript—in a single web session at haptiq.app. The free tier includes full generation and basic editing; Pro unlocks the advanced transform plugins, multi-axis support, and batch processing. Founding members can lock in lifetime Pro access for a one-time $99 (normally $199.99), limited to the first 100 members, at the pricing page.

Frequently asked questions

What is Savitzky-Golay smoothing and why use it for funscripts?

Savitzky-Golay filtering fits low-degree polynomials to successive windows of data points, removing high-frequency noise while preserving the timing and amplitude of actual motion events. Unlike simple moving averages that flatten peaks, it maintains phase accuracy—critical for keeping haptic events aligned with on-screen action.

How do I know what speed limits to apply for my specific device?

Consult your device's documentation and community-tested values. The Handy sustains roughly 400 units/second with brief spikes to 600; OSR2+/SR6 varies by servo tuning, typically 300-500; Kiiroo Keon enforces firmware limits around 400. When uncertain, start conservative and test, as exceeding mechanical limits causes stuttering, overheating, or damage.

Can I use HaptiQ's editor on funscripts generated by other tools?

Yes. HaptiQ's timeline editor imports standard .funscript files regardless of origin. You can apply smoothing, clamping, speed limiting, and manual spot-fixing to any compatible script, then export for use with DeoVR, HereSphere, XBVR, ScriptPlayer, or other players.

Why does clamp order matter in the cleanup workflow?

Clamping before smoothing creates artificial flat zones at boundaries that smoothers then distort, producing unnatural curve shapes. Smoothing first preserves the original geometry, then clamping simply truncates the clean result at your device's usable range. Speed limiting always comes last to catch spikes introduced by clamping.

What does HaptiQ's quality score actually measure?

The quality score analyzes processed scripts against device-specific capability models, flagging speed violations above threshold, position values outside declared range, excessive acceleration (jerk) that stresses mechanics, and temporal gaps that risk sync loss. It provides objective metrics to determine when cleanup is complete rather than relying on subjective feel alone.

Create a free HaptiQ account to generate a funscript from your own video.

Open in HaptiQ