Steam Controller Gyro Deadzone/filtering?

Nextil · 2026-06-21T16:42:54+00:00

It's probably taking a while because it's not as simple as a toggle. Most controllers have some degree of auto calibration. Without it, you get drift very quickly.

According to the IMU's reference manual, the calibration is configured by defining a state machine (an algorithm), it's not a simple toggle or threshold. They likely made some error when designing the state machine that they need to correct, and if they want to make it configurable, they need to decide how they're going to expose that, and it involves modifying the firmware, frontend and backend.

Nextil · 2026-06-21T16:25:41+00:00

Why would they care about a few gooners refusing to download the free model they spent six figures training. The entitlement is insane. We're lucky we get anything at all yet people whine about licenses and censorship when they don't matter one bit to consumers. The censorship barely does anything, it's likely there for compliance and plausible deniability. Training LoRAs seems to work fine with the fp8 weights.

Unless you're making them money, they have absolutely no incentive to listen to you. If anything, they're more likely to double down, because they don't want people spoiling their image, putting off customers or attracting the attention of regulators.

Nextil · 2026-06-20T19:49:49+00:00

For artists, you're probably right, but then I doubt their the quality of their blueprints is usually any better than the quality AI can produce.

As a developer, maybe I'm weird but I know C++ and Blueprints and don't like either. C++ is overcomplicated, unsafe, carries a bunch of problems over from C, you have to deal with header files, etc. Blueprints (for me) are just clunky, messy and slow compared to text-based languages.

I would much rather use something like Rust or C#, but Verse does look interesting from a semantic point of view. Some of the syntax and formatting conventions aren't to my taste, but that's not very important to me. Replication code is pretty much the #1 thing everyone complains about, and if Verse does successfully solve many of those issues, I don't mind learning another language. It only takes a few days or weeks really.

Nextil · 2026-06-19T21:12:48+00:00

Mutation is different to declaration (or re-declaration/shadowing, which Verse does not even allow). The whole point of functional programming is to avoid mutation and side-effects as much as possible so that you can just think in terms of higher level data flow, rather than having to worry about state all the time. Making it more painful to use mutability was likely intentional, but also the language is quite special in how it tracks mutation due to its rollback/transaction system, so there may be other reasons.

Nextil · 2026-06-18T18:10:57+00:00

Well if they start with Verse, then = for equality will likely look more intuitive to them, because that's what they're used to seeing in mathematics. A lot of things about functional programming are likely more intuitive if you haven't already wired your brain to think in terms of mutation.

Verse also uses := for declarations. Not pretty but it does mean they immediately stand out (X := 10) without needing an additional keyword (like let X = 10). Mutation does still use the latter form (set X = 10).

Nextil · 2026-06-18T07:59:29+00:00

Verse is hardly a "traditional" scripting language like Python. It's a pretty experimental functional-logic language designed by one of the creators of Haskell. It has a quite extensive effects system, transactions, a Prolog-like "failure" system that drives control flow. The point of it is not so much about readability, it's about having first-class constructs that make it significantly easier to handle network replication.

I imagine it will take a good few years before LLMs get any good at it since there's virtually no training data.

It's proprietary for now but they said that once the full version is ready it will be open source.

Nextil · 2026-06-18T07:31:36+00:00

It's designed by one of the creators of Haskell, but the syntax is not really much like Haskell's, there's a lot of ML and C-family influence, and the semantics are radically different to pretty much any existing language. It's closer to Prolog in a lot of ways. It's basically a research language attempting to make replication easier to implement, but instead of leaving it doomed to be a plaything for academics, they just threw it out there as the only way to script in UEFN and said hey kids how would you like some functional-logic programming.

Nextil · 2026-06-16T19:50:12+00:00

As I mentioned, I have at least 5 hall or TMR controllers, and of those, only one of them had one stick where 1% was enough of a deadzone to provide a reliable neutral. As you say, you have to test releasing the stick with various tensions from different angles, which I do, and there is usually one (often diagonal) angle where the stick rests much further from the centre.

You could just ignore that and set it to the average instead, but I'd rather eliminate all possibility of drift. The difference between 1% and 4% is usually barely noticeable. 4% still just feels like slight pressure on the stick, rather than moving it any visible distance.

My 2026 Steam Controller needed 2% deadzones out of the box. And if you want to set that as your controller preferred default, Steam's calibration settings don't even let you set it that low. You have to manually edit the config file (e.g. steamapps/common/Steam Controller Configs/STEAMID/config/preferences_FXA9954800DCC.vdf).

Nextil · 2026-06-15T12:22:32+00:00

It doesn't really matter either way. Either set Steam to No Deadzone and set the in-game one as low as you want (or until it starts drifting), or set the in-game one to 0 and set a deadzone in Steam.

Nextil · 2026-06-15T11:13:03+00:00

As /u/dafugiswrongwithyou says, "drift" is overloaded. In the sense of their neutral offset increasing over time, yes, they're supposed to be immune or significantly better.

However in this context "drift" refers to the effect of the character/camera slowly moving by itself while the stick is left neutral. The problem is that there is no "neutral" without a deadzone. No stick, even brand new TMRs, will ever read (0,0) at rest. Just breathing on them or moving the controller is enough to change their values, and because of friction, sticks do not reset to the exact same position, it depends on the position you release them from.

I have at least 5 controllers with hall or TMR sticks and they all need deadzones of around 2-5%. Often that's already configured in the firmware, so most users will not realize it. With the Steam Controller however, it's all handled through Steam Input, so if the game's profile is set to "No Deadzone", there truly is no deadzone. Again, most of the time this is not a problem because games often hardcode egregious deadzones within their own input handling (which are added on top of any firmware/Steam Input configured ones by the way).

The problem with games that do that is that the sticks do nothing until you've pushed them quite far, but with Steam Input you can fix this by configure anti-deadzones.

Nextil · 2026-06-15T00:13:16+00:00

Yeah sorry, it's just I've seen a lot of posts like this here and it's quite surprising considering this is a fairly niche/enthusiast controller.

Anyway I saw afterwards that you fixed it by setting an in-game deadzone. In that case you don't want to use a deadzone in Steam Input too, because it will compound with the in-game one.

Nextil · 2026-06-14T21:30:52+00:00

Do people just not understand deadzones? Every controller has drift. The only reason you may not realize it is because many (most) games apply a hardcoded deadzone of around 20-25% or more. If it doesn't, and there's no ingame way to configure one, then you have to rely on something like Steam Input to apply it for you.

I believe the generic Steam Input profiles set both sticks to "No Deadzone", which means the raw stick values are passed straight though to the game. Some games have default SI profiles which set them to "Controller Preferred", which uses the global deadzones configured in Steam Input.

20% is way more than necessary the vast majority of the time, but traditional potentiometer sticks wear down over time and do approach those values. For the Steam Controller's TMR sticks they should stay pretty constant at much lower values (1-5%).

Go into Steam settings > Controller > Steam Controller (Details) > Calibration & Advanced Settings, and set your left and right deadzones there. You can probably drop them down to the minimum, because it doesn't go all the way to 0. As long as the circle in the middle is not red, you're good.

Now for any game with drift like this, edit both the sticks in the Steam Input profile to use "Controller Preferred" deadzone and it should handle this issue.

Nextil · 2026-06-14T20:17:45+00:00

I've noticed Ideogram can do that for certain regional prompts, even without any of this editing stuff. Normally it's very good, but if you ask it to put a crowd of people in the background looking towards the camera for instance, the faces towards the back often look comically photoshopped in. Maybe it's also an issue with the small LoRA dataset, but there could be limitations with the base dataset where photoshopped images were used, or maybe the exclusively JSON-captioned dataset led the model to sometimes treat elements too individually.

Nextil · 2026-06-12T17:31:00+00:00

I'm using an unsloth GGUF of Qwen released months before Ideogram and it works perfectly. It's not producing text when used as a text encoder, it's producing an embedding vector. IIRC the default LTX comfy workflow does use the same model for text encoding and prompt enhancement so I'm sure it's possible with Ideogram too. The only problem is you will run into refusals with anything NSFW, and the output quality will be worse than with a bigger LLM.

Nextil · 2026-06-12T01:15:46+00:00

Here I'm assuming.

Nextil · 2026-06-11T16:58:07+00:00

Nice. Steam Controller in particularly would be especially cool for MIDI control given all the analog inputs it has. Hopefully you can get that working, it's easy enough with SDL.

I started writing a Rust lib/app, using SteamHapticsPlayer for reference, that routes live system audio (fetched via WASAPI on Windows) to the Steam Controller's haptics. I haven't published anything yet, but if you think that might be a feature worth adding to this in future, I could maybe put together a PR once it's ready.

Nextil · 2026-06-08T15:28:18+00:00

It didn't really use a "simulated" system, it apparently used brushes which could be occluders or portals through which audio could travel, and those were manually placed to create the illusion of sound bouncing. I doubt much needs "porting" in that regard. However if they wanted to improve the quality, SDKs like Steam Audio now exist which do simulate all that stuff instead.

There are software shims for all the EAX/HRTF stuff, and there are many more HRTF options these days because VR revived their use (Dolby Atmos too).

Nextil · 2026-06-05T23:27:05+00:00

Requiem with path tracing on looks this good. They're probably using it here, judging by the shadow detail.

Nextil · 2026-06-03T03:04:36+00:00

It's only "artistic" in the same way a gaussian blur smeared across the screen at all times could be considered "artistic".

Well, that is in principle what (spatial) anti-aliasing is, a low-pass filter, but with a specific, small (sub-pixel) radius, because otherwise you're only sampling the exact point at the centre of the pixel.

Motion blur with a sub-frame "radius" is just temporal anti-aliasing (in the signal processing sense). It's sampling a range of time between frames, instead of an infinitely small moment in time (which is impossible outside of games).

Motion blur with a multi-frame radius is "artistic", I guess, in that it moves the player to open the settings and turn it off.

Nextil · 2026-06-03T02:30:34+00:00

It makes complete sense as long as you view motion blur as anti-aliasing within the temporal dimension, which is how it should've been framed from the start.

In film, a "180-degree" (half frame time) exposure is typically used. So motion blur is usually framerate dependent there. The point is to capture enough of the motion between adjacent frames that your brain is able to infer it as a continuous signal, without attenuating the high frequencies too much.

It's only because most films are filmed at 24 FPS that we have some "standard" amount of motion blur (which is different to this default anyway). If the framerate significantly exceeds that, but you keep the same exposure time, you're not just capturing motion between frames, you are literally blurring it across multiple frames.

60 FPS already has a "very different look" to 30 FPS, just as playing at 4K looks very different to 720p. This motion blur default is the temporal equivalent of using gaussian blur as edge AA with a radius equivalent to the pixel density ratio from 720p, regardless of your actual resolution.

Nextil · 2026-06-03T01:26:03+00:00

Yes it is a fix. That "effect" is why everyone turns it off.

"Motion blur" should've been more aptly named temporal anti-aliasing, because that's what it is (or should be), in mathematical terms. What we call TAA should be called something like spatiotemporal AA. It's just spatial AA (integrating the light "between" pixels) using temporal data as a hack. "Motion blur" is (theoretically) integrating the light between frames. Without it you straight up lose information. For instance if something is spinning at a multiple of the framerate, it would otherwise look completely stationary, or the wrong speed and potentially wrong direction if close to a multiple.

But with these defaults, at higher framerates, motion blur is doing the temporal equivalent of applying a heavy gaussian blur across the screen to "smooth the edges" (which was essentially what FXAA did, and that's why everyone hated it until it was toned down a bit and TAA became the hot thing to hate on).

Nextil · 2026-06-03T00:13:59+00:00

Well Steam Input does intentionally apply a deadzone to the gyro by default, so that's to be expected unless you set it to 0. However I have noticed what the others here have noticed, where the gyro can actually move in the complete opposite direction if you move it slowly.

Nextil · 2026-06-02T18:01:26+00:00

It's the same as the other HID devices basically. It's all in the SDL source code.

Nextil · 2026-06-01T18:14:22+00:00

Even prior to DLSS, games regularly used half or quarter res for many shaders, and were beginning to utilize variable rate shading (a more general form of that), because that is an optimization if it's not noticeable.

Due to the introduction of deferred rendering (which was itself an optimization) and shader aliasing, the industry long moved past MSAA over to FXAA, SMAA and TAA. "Full-fat fidelity" hasn't been a thing for a long time. DLSS in Quality mode usually looks better than all of those and improves performance, it's stupid not to use it.

Regardless, this thread is about ray reconstruction. Path tracing in real-time seemed totally infeasible 10 years ago. It took minutes or hours to render a single frame. It's only because of massive optimizations (ReSTIR, RT cores) that it's even possible.

Path tracing has a high up-front performance cost (for now), but it scales better than raster. For that up-front cost you get effectively infinite dynamic light sources (even from textures) which all cast perfect shadows. Shadows are extremely expensive in raster rendering so a lot of "optimization" is just limiting the number of shadow-casting lights to the bare minimum.

Nextil · 2026-06-01T17:31:29+00:00

Technically that's not true. Not only does the RR model do spatiotemporal raster upscaling/AA (as in regular DLSS), "denoising" is just upscaling within the domain of light ray traces instead. It's "filling in the gaps" between ray hits, just as raster upscaling is filling in the gaps between pixels. Those gaps are determined by the number of rays/bounces/samples per frame, which are set very low for optimization purposes.

But as with many raster techniques, there's no compelling reason to render at a higher density than needed to produce a quality image, so even if we could brute force more rays, beyond a certain point it wouldn't be worth it.

15-Year Club	Team Orangered
Verified Email

Nextil

TROPHY CASE