Smartgloves finger data is noisy as hell — anyone found a sane cleanup workflow?

423 views 10 replies

Been integrating Rokoko Smartgloves finger data into my pipeline and the results are... mixed. Broad hand poses read fine, but individual finger curl data has this constant low-frequency vibration noise that makes digits look like they're trembling even when the hand is completely still. Subtle in isolation, very obvious once it's on a character.

Things I've tried so far:

  • Running the Blender keyframe strip script from AuroraPulse's thread to thin curve density — helps with bloat, doesn't actually fix the underlying noise
  • Second pass in MotionBuilder with the per-bone smoothing filter on finger bones, usually around 35–45% — gets it closer but also flattens intentional curl detail on the same pass
  • Manual graph editor cleanup on the worst digits — fine for a hero shot, completely unsustainable for a full session's worth of takes

At this point I'm thinking about just throwing a Butterworth low-pass filter at the raw curve values in Python. Something like scipy.signal.butter + filtfilt with the cutoff tuned per take. Haven't tried it yet but it feels more principled than whatever MotionBuilder's smoothing slider is actually doing under the hood.

I'm also reconsidering whether the right move is to just use the Smartgloves data as a rough pose guide and hand-key the actual finger performance on top. That feels like it defeats the purpose of buying the hardware, but maybe that's just the reality of the price tier.

Has anyone built a filtering step into their glove data pipeline they're actually happy with? And has anyone tried constraining finger bone range with driven keys to limit noise that way — like capping per-digit deviation based on wrist pose? Sounds reasonable in theory but I haven't seen anyone do it in practice.

Replying to NeonPike: The hold still and measure R approach is solid, but finger sensors have pose-dep...

Pose-dependent variance is actually fixable if you're willing to do a short calibration pass. Capture noise samples per finger at three reference poses: full extension, mid-curl, and fully curled. Store three separate R matrices and interpolate between them at runtime based on the current curl estimate coming out of the filter.

More setup upfront, but the filter stops being overconfident at extremes, which is exactly where it matters most. Full extension and tight grip both tend to be high-noise states for most sensors, and a single flat R just can't handle both ends. The trickiest part is getting consistent reference poses across different hand sizes, but even rough three-point interpolation is way better than a flat R.

Replying to CobaltFox: The stationary noise assumption is what kills EMA for wrist twist data too. Rapi...

The wrist twist example gets at something: the real tuning knob in a 1D Kalman filter isn't the measurement noise covariance (R), it's the process noise covariance (Q). R is roughly fixed by your sensor spec. Q is where your assumptions about joint motion dynamics actually live.

For signals with high-variance bursts like pronation or fast finger extension, a fixed Q is exactly the wrong model. A simple adaptive variant works much better: track your recent innovation residuals (predicted vs. actual measurement), and when they spike, temporarily increase Q. The filter widens its uncertainty estimate so the update step can chase the movement. When residuals settle back down, Q drops and smoothing resumes. It's maybe 20 extra lines and it handles the "sudden movement should track, idle drift should smooth" requirement in a principled way rather than just picking a compromise fixed value and hoping.

Replying to NimbusVale: haven't used Smartgloves specifically but dealt with similar noise from a DIY fl...

EMA with a small alpha is usually my first pass too, but for finger curl specifically I've had better results with a simple one-dimensional Kalman filter. The EMA assumes noise is stationary, but finger tracking noise tends to vary with glove pressure and hand orientation. Kalman adapts its gain dynamically, tightening when the signal is stable and loosening during real movement. It's not much more code and the feel at slow controlled movements is noticeably better. EMA over-smooths exactly the subtle finger positions where precision actually matters.

Replying to VoidHaze: Pose-dependent variance is actually fixable if you're willing to do a short cali...

the three-pose calibration is solid but don't assume symmetry between fingers. my index and pinky had noticeably different noise profiles at the same pose. the pinky was about 40% higher variance at full curl, probably just sensor placement variation inside the glove. sample each finger independently rather than averaging across the hand or you'll end up under-filtering the noisy ones.

also: the interpolation method between reference poses matters more than the number of poses. linear interp between three points still had visible jumps at the transitions. cubic spline over the same three samples was a lot smoother.

Replying to FrostHawk: The wrist twist example gets at something: the real tuning knob in a 1D Kalman f...

The Q/R split is where most Kalman filter tutorials lose people — they present both as noise parameters when in practice they're tuning completely different things. R is relatively straightforward to estimate from captured idle frames. Q is a modeling assumption about how much the true underlying motion can change between timesteps, which is much harder to pin down without just experimenting.

Something that helped me: running the filter offline over a few representative takes with different Q values and plotting output against the raw signal. Makes the lag/noise tradeoff far more visible than trying to tune it by feel during a live session. If you have archived takes lying around it's worth doing before you touch the production pipeline.

Replying to CipherLynx: The Q/R split is where most Kalman filter tutorials lose people — they present b...

The Q vs R distinction is also where the physical intuition breaks down, because R is at least empirically measurable: hold your sensors still, record the variance, done. Q is asking "how much can the true state change between samples," which requires you to reason about the physics of the system you're tracking, not just the data.

For finger curl the awkward thing is that a single Q has to model both slow deliberate curls and fast snaps, and those have very different expected velocities. A Q loose enough to track a fast trigger pull is more permissive than you want for held poses, and a Q tight enough for held poses systematically lags on fast transients. There's no single value that works for both. That's usually where people end up looking at adaptive Q, or just accepting that fast movements will lag a bit.

Replying to CobaltDusk: EMA with a small alpha is usually my first pass too, but for finger curl specifi...

The stationary noise assumption is what kills EMA for wrist twist data too. Rapid pronation/supination has way higher variance than idle drift, and a fixed alpha just can't adapt to that. The 1D Kalman approach is worth the extra setup time.

One thing I'd add: tune your process noise (Q) and measurement noise (R) separately per finger segment rather than using uniform values across the whole hand. Proximal joints move more aggressively and need a higher Q; distal tips tend to be noisier and benefit from a higher R. I treated them as uniform for way too long and got mediocre results everywhere instead of good results anywhere.

Replying to ShadowRay: The Q vs R distinction is also where the physical intuition breaks down, because...

The hold still and measure R approach is solid, but finger sensors have pose-dependent noise. Variance at full extension isn't the same as when the finger is curled, and metacarpal joints behave differently from the proximal ones. Measuring in a neutral position and treating it as universal is a workable approximation, but for Smartgloves data I ended up measuring R in three representative poses (rest, open, fist) and averaging them. Still fully empirical, still beats guessing, just more representative of what you'll actually see during capture.

One thing worth checking before going deep on software filtering: are you streaming at the Smartgloves' full data rate or letting Rokoko Studio downsample before it hits your pipeline? I was seeing similar noise on finger curls and it turned out my consumer was reading at 60fps while the gloves were sending at 100, so I was getting interpolation artifacts that looked like sensor noise but were actually structural. No filter was going to fix them. Locking stream rate to something my consumer could reliably handle fixed most of it before I touched a single smoothing parameter.

haven't used Smartgloves specifically but dealt with similar noise from a DIY flex sensor rig. two things that helped a lot: exponential moving average on the raw values (even a small alpha like 0.05–0.1 kills most high-frequency jitter without introducing noticeable lag), and deadband filtering, where you ignore changes below some epsilon threshold. finger curl tends to be bimodal anyway so a little hysteresis doesn't cost much expressiveness.

also worth checking: Rokoko Studio has smoothing options in its recording settings. i'd still prefer handling it in post rather than baking it into the raw capture, but it's a quick sanity check to at least isolate whether the noise is software- or hardware-level before going further.

Moonjump
Forum Search Shader Sandbox
Sign In Register