CASE STUDY WHIZBY

A whizby is the crack of a bullet passing the player. The stock implementation finds the closest point on the bullet's path to the listener, then decides which way the whoosh should sweep by comparing the firing vector's right vector against the path-to-listener perpendicular. Since this implementation is in world space, it only factors which side of the trajectory the listener stands on, but not which way the they are facing. Facing the shooter it reads correctly. Turn around and the sweep reads backwards. I confirmed it with a bool print across two networked clients: changing position flipped the result, changing facing never did.

I decided to ask the same question in listener space instead. To help me visualize this, I created a graph to show the listener's right vector rotation along the perpendicular of a bullet's travel path.

The function already caches the perpendicular from the bullet's pass point toward the listener, so I swapped the dot product against the camera's right vector (Listener Right) instead of the firing right vector:

bRightToLeft = (dot(ListenerRight, Perpendicular) < 0.0f)

When the listener rotates, the camera's right vector rotates with the listener, so the answer follows the listener's ears. The closest-point spawn, the stereo spread scaled by miss distance, and the distance-based onset delay all stay untouched.

After swapping the logic, bRightToLeft updates in every orientation, verified from both client perspectives: the bool flips when the firing vector passes the listener's right or left, and is reversed when the listener turns 180°. This is shown in the video above with listener audio (Client 1) from the firing viewpoint (Client 2).