- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 170
- Reaction score
- 7
Been messing around with a YOLO-based setup for League and hitting a wall with the prediction math. For anyone deep into CV aimbots: how are you handling the latency-to-prediction ratio without the cursor oscillating like crazy?
I am currently running YOLO for health bar detection, and the tracking is solid, but the predictive lead is killing my consistency. I tried a OneEuro filter for the initial smoothing, but when I try to extrapolate for that 300-600ms window, the phase lag from the filter combined with the noisy raw detections makes the lead distance swing wildly.
Current Stack:
The jitter is manageable at low speeds, but as soon as a champ starts dancing or blinking, the prediction error scales up and turns the aimlock into a flick-fest. I have tested EKF6 and Monte Carlo, but they are either too computationally heavy for a real-time loop or just introduce their own flavor of jitter.
Has anyone found a more stable way to handle sub-second trajectories in 2D space? Specifically looking for:
I am trying to keep the footprint external to avoid any weird hooks, but the current 50-100px misses are making this useless for anything other than basic skill shots. If anyone has a cleaner implementation for short-horizon prediction or a way to tighten up the velocity derivation without blowing up the lag, drop some knowledge.
Curious to hear how you guys are handling your lead vectors. Are you using a look-up table for common projectile speeds or just hard-coding the offsets per champ?
I am currently running YOLO for health bar detection, and the tracking is solid, but the predictive lead is killing my consistency. I tried a OneEuro filter for the initial smoothing, but when I try to extrapolate for that 300-600ms window, the phase lag from the filter combined with the noisy raw detections makes the lead distance swing wildly.
Current Stack:
- Detection: YOLO (custom weights on health bars)
- Smoothing: OneEuro Filter (current setup)
- Extrapolation: Velocity * Time (simple linear)
The jitter is manageable at low speeds, but as soon as a champ starts dancing or blinking, the prediction error scales up and turns the aimlock into a flick-fest. I have tested EKF6 and Monte Carlo, but they are either too computationally heavy for a real-time loop or just introduce their own flavor of jitter.
Has anyone found a more stable way to handle sub-second trajectories in 2D space? Specifically looking for:
- Kinematic Models: Are you guys sticking to constant velocity or implementing constant acceleration models?
- Noise Reduction: Is there a better filter than OneEuro for this specific task, or should I be looking at raw Kalman gain tuning?
- Time-Sync: How do you calculate the actual projectile travel time versus the internal reaction latency?
I am trying to keep the footprint external to avoid any weird hooks, but the current 50-100px misses are making this useless for anything other than basic skill shots. If anyone has a cleaner implementation for short-horizon prediction or a way to tighten up the velocity derivation without blowing up the lag, drop some knowledge.
Curious to hear how you guys are handling your lead vectors. Are you using a look-up table for common projectile speeds or just hard-coding the offsets per champ?
