11 ms·

My favorite use of a PID controller in Unity was to act as a camera operator for a VR football game. We used cameras for the screen-display (we could either sh

My favorite use of a PID controller in Unity was to act as a camera operator for a VR football game. We used cameras for the screen-display (we could either show you the VR player's perspective, or one of several cameras), and for the jumbotron in the stadium. This ended up being really cool for downfield throws. When you bombed the ball 45 yards to a receiver, it could be a little hard to see the action. It was really natural to be able to glance up at the jumbotron in the stadium to get a closer view of what's happening downfield. A small custom little PID controller worked really well for tracking the ball in flight, and giving a more natural "human operated" camera feel than perfectly tracking the ball. We'd also randomly vary the terms within a set range for different virtual camera operators, so you'd get a little bit of variance in the tracking between different cameras and different play sessions. Also a lot of pretty fun "bugs" from badly tuned PIDs.

onetimeuse92304 3y ago
Wouldn't it be better to model imperfections separately rather than rely on PID oscillations? I can see how this can easily fail and cause some dramatic and unnatural camera movements.
- GabeIsko 3y ago
  Well, yes and no. PID is very simple to integrate in a state loop, so it is simple to implement, and gives the illusion of imperfect tracking very quickly. So I imagine this implementation worked rather well. Because the imperfectness isn't random noise, but it is a model of someone trying to aim something, and they do it imperfectly. Generally though, It would be pretty trivial to add noise for this stuff. You would probably want some noise on the orientation if you wanted to model more of a camera shake. Perlin noise is my go to if I want to introduce randomness to positions really quickly.
- ncallaway 3y ago
  Maybe? It was, like, 15 minutes of work to find a range of acceptable PID values, then generate a random variable from a normal distribution with a mean at the expected value (we just hard-trimmed the random value at 1 std deviation, because we didn't want a 99th percentile result to cause craziness). Other than the hilarity that ensued while I was playing around with PID values to find the acceptable ranges, I can't recall ever seeing a bug that was problematic from this, so I didn't really give it much thought. Honestly, there were much bigger things to work on. The nice thing about this system though, is it created "personality" for the camera. If a virtual camera operator had a lower D-value, they'd overshoot just a little bit, semi-consistently. Another one might have a slightly lower I-value, and end up just a little bit further back in the tracking. It was a super quick way to give a little bit of organic variance to the camera operation, so it didn't feel "samey" every time.

onetimeuse92304 3y ago

Wouldn't it be better to model imperfections separately rather than rely on PID oscillations? I can see how this can easily fail and cause some dramatic and unnatural camera movements.

GabeIsko 3y ago
Well, yes and no. PID is very simple to integrate in a state loop, so it is simple to implement, and gives the illusion of imperfect tracking very quickly. So I imagine this implementation worked rather well. Because the imperfectness isn't random noise, but it is a model of someone trying to aim something, and they do it imperfectly. Generally though, It would be pretty trivial to add noise for this stuff. You would probably want some noise on the orientation if you wanted to model more of a camera shake. Perlin noise is my go to if I want to introduce randomness to positions really quickly.
ncallaway 3y ago
Maybe? It was, like, 15 minutes of work to find a range of acceptable PID values, then generate a random variable from a normal distribution with a mean at the expected value (we just hard-trimmed the random value at 1 std deviation, because we didn't want a 99th percentile result to cause craziness). Other than the hilarity that ensued while I was playing around with PID values to find the acceptable ranges, I can't recall ever seeing a bug that was problematic from this, so I didn't really give it much thought. Honestly, there were much bigger things to work on. The nice thing about this system though, is it created "personality" for the camera. If a virtual camera operator had a lower D-value, they'd overshoot just a little bit, semi-consistently. Another one might have a slightly lower I-value, and end up just a little bit further back in the tracking. It was a super quick way to give a little bit of organic variance to the camera operation, so it didn't feel "samey" every time.