Drimzi

Let's go from 10" monitor to 20" monitor. Both have 1920x1080 pixels. First assumption will be to match the distance it takes to move the cursor from one side to the other side, AKA move 1920 pixels. This is what the calculator does. Let's extrapolate this idea to a 1" screen and a 1000" screen. If the distance it takes to move the mouse results in the cursor moving 1" in one case, and 1000" in the other, will it feel the same? Personally it wouldn't to me.
Instead of matching the quantity of pixels displaced, you want to match the distance displaced. Figure out how big a pixel is.
(rounded for simplicity)
10" monitor:  Every pixel is 0.0045"
20" monitor:  Every pixel is 0.0090"
If it takes 1" of mouse movement to move 1920 pixels on the 20" monitor, then 1" of mouse movement correlates to 17.4". This is a ratio of 1 : 17.4, or a gain of 17.4. It doesn't matter what units you measure, whether it is mm, cm, inches, kilometers, it doesn't matter. 1 unit of mouse movement correlates to x unit of cursor movement. This is what you convert, not the pixels displaced. It will become inconvenient to move the cursor from the start menu to the system tray if the screen was 1000" wide, but that has nothing to do with the sensitivity of the mouse. For convenience, you can change the sensitivity to reduce that distance, but that is just preference.
 
Let's take it to 3D. In the above explanation you can see that pixels don't matter. The monitor is acting like a window. You are keeping real-world distances. The same applies to 3D.
Imagine you are playing a game like CS:GO. You crop the aspect ratio from 16:9 to 4:3. Does the perceived sensitivity change? Is it like some kind of optical illusion where replacing some of the rendered game world with blackness changes the perception of sensitivity? It personally isn't to me.
What if instead of blackness, you just change to a 4:3 monitor. You effectively reduced the horizontal angle of view from 106.26 degrees to 90 degrees, but the perceived sensitivity did not change. If it feels the same, why would you scale the sensitivity by the change in angles, ie. 90/106.26, which is what 'monitor distance match' is doing. So at the moment, the angle of view (or FOV) is changing, but the cm/360° is not and it feels good. So maybe it is because the vertical angle of view is still 73.74, so that's why the sensitivity didn't change? Wrong. Since CS:GO enforces a specific angle of view, let's just place black paper on the monitor to 'crop' it, let's reduce the effective vertical angle of view to a low number, will the sensitivity appear to change? If you answer no, then you can see that the angle of view has no bearing on the sensitivity. The focal length remained constant, the angle of view changed, so the answer is the focal length.
Here is 90° (4:3) at 20" and at 10", overlayed

You can see that they are both different. They have identical angle of view, but the focal length is completely different.
 
If you convert from the 20" to the 10", then the 10" needs to reduce the angle of view to maintain the same focal length. 20" has 90° (4:3), 10" has 53.13° (4:3).

 
Here is 10" converted to 20". 10" has 90° (4:3). 20" has 126.87° (4:3).

 
The first scenario, where the game enforces 90° (4:3), the game sensitivity value doesn't change. However, the CPI did change, by a factor of 2 if you keep the same 2D sensitivity. This is because the 20" is twice the size of 10". The focal length has also changed by the same factor. So the change in CPI results in the change in cm/360°, even though the FOV is the same. If you didn't want your cm/360° to change, you would have to use a lower angle of view on the smaller monitor (the 2nd picture).
You can quickly test this for yourself by creating a custom half resolution, like 960x540, and then playing a game in windowed or fullscreen (with no scaling and override enabled). Compare no change in sensitivity, and double game sensitivity (or whatever sensitivity value is equivalent to half the cm/360°). See which one feels better.
Scaling the game sensitivity by the change in focal length is exactly what 0% monitor match does. The change in monitor size is also the same factor as the change in focal length. This suggests that 0% is the only way to convert game sensitivity/cpi, as it results in no change in 'sensitivity'. The relationship between the device and the display element remains constant. Any deviation from this will be personal preference.
Many will have personal preference that will override 0%. Like if the screen was incredibly wide such as 32:9, making the distance from one end to the other double than that of a 16:9, then they may prefer to scale their sensitivity by a factor or 2 in order to make the hand distance the same when going from the start menu to the taskbar, or closing browser tabs, etc. They distance matched, which requires a change of device/mouse sensitivity (also applies to 3D). Many may also prefer to amplify their sensitivity for aim down sights/scopes, so they don't have to scale their input proportionately with the change in zoom and image curvature. 0% usually feels too slow in this case because you are directly comparing two different focal lengths without the distance between you and the reference point changing to cancel out the perceived zoom, whilst simultaneously using the same hand movement before and after the zoom. The target size, distance between the target and the crosshair, the target movement speed, etc., all scale proportionately with the focal length, which means you also need to scale your input with the focal length to land the flick or track the movement speed (and then there's the difference in eccentricity/curvature that results in that snappy/sluggish feeling and different diagonal trajectories).
Due to these preferences to scale sensitivity instead of input, other methods like 'monitor distance match' can be useful. I think Viewspeed v2 is also useful, the feeling is is kind of comparable to zooming in and having the camera dolly in the opposite direction of the zoom. If you zoom in from one end of the spectrum to the other, whilst simultaneously moving the mouse in circles, it looks like the sensitivity is matched perfectly. But when it comes to actually using Viewspeed v2, it results in worse aim performance (personally) at the expense of it feeling more consistent in that exact specific moment, due to the no sudden feeling of slowdown or speed up whilst using identical mouse movement before/after the zoom.
 
As for focal length, I believe it is found by doing the following:
(SquarePixels/2) / tan(SquareDegrees * pi/360) = focal length in pixels?
It's the same as this graphical fov calculator: https://teacher.desmos.com/activitybuilder/custom/5a61dd34fafbd40a25416e02#preview/d123ef39-8694-4760-af7d-c18c936ce79d
Scale pixels by the physical dimension of a pixel, and you will see that the above cases have identical focal lengths despite very different angle of views.
10" 90 (4:3) has 720 pixels focal length, 720 * 0.0045 = 3.24"
20" 126.87 (4:3) has 360 pixels focal length, 360 * 0.0090 = 3.24".

I think this should work: https://www.desmos.com/calculator/trk3nrmtkp
It calculates the amount of distortion there would be at the location of the cursor at a specific fov. This will become the cursor speed multiplier, simulating the distortion of 3D.
You would need to make a script that can continuously get the cursors xy position, calculate the distortion amount and then feed that into RawAccel somehow.
Before going through the effort I think the whole thing is quite pointless if the desktop itself isn't distorted. If it's flat then there is no context to the cursor speed change. The cursor and desktop panning is already behaving correct to the desktop's fov of 0. You aren't looking at your arbitrarily chosen fov so the cursor speed changes will feel random. If you were able to distort the desktop after it has rendered then the cursor would get distorted anyway.
 
Edit: I did a quick test to verify that the distortion calculation was correct as i wasnt sure. It says the distortion/speed multiplier will be 2 when moving the cursor to the top or bottom of the screen (y 0 or 1080) at 90 vertical fov. So in Aim Lab's creator studio I set the fov to 90 and placed a pillar that begins at the cursor and ends at the exact top of the screen. The sphere at the original crosshair position gets distorted vertically by a factor of 2 (from 34px to only half of the sphere being 34px).
I then changed to 150 vertical fov. The pillar was now 145 pixels tall instead of 540, which makes sense since 540 / tan(150/2 *pi/180) = 144.69. I looked up 145 pixels and the sphere again stretched vertically by a factor of 2 (from ~9px to ~18px). In the calculator if you set 150 fov and cursor y to 540 +- 145, you get 2, so it appears that my calculations were correct after all.

I think this should work: https://www.desmos.com/calculator/trk3nrmtkp
It calculates the amount of distortion there would be at the location of the cursor at a specific fov. This will become the cursor speed multiplier, simulating the distortion of 3D.
You would need to make a script that can continuously get the cursors xy position, calculate the distortion amount and then feed that into RawAccel somehow.
Before going through the effort I think the whole thing is quite pointless if the desktop itself isn't distorted. If it's flat then there is no context to the cursor speed change. The cursor and desktop panning is already behaving correct to the desktop's fov of 0. You aren't looking at your arbitrarily chosen fov so the cursor speed changes will feel random. If you were able to distort the desktop after it has rendered then the cursor would get distorted anyway.
 
Edit: I did a quick test to verify that the distortion calculation was correct as i wasnt sure. It says the distortion/speed multiplier will be 2 when moving the cursor to the top or bottom of the screen (y 0 or 1080) at 90 vertical fov. So in Aim Lab's creator studio I set the fov to 90 and placed a pillar that begins at the cursor and ends at the exact top of the screen. The sphere at the original crosshair position gets distorted vertically by a factor of 2 (from 34px to only half of the sphere being 34px).
I then changed to 150 vertical fov. The pillar was now 145 pixels tall instead of 540, which makes sense since 540 / tan(150/2 *pi/180) = 144.69. I looked up 145 pixels and the sphere again stretched vertically by a factor of 2 (from ~9px to ~18px). In the calculator if you set 150 fov and cursor y to 540 +- 145, you get 2, so it appears that my calculations were correct after all.

For 2D sensitivity, your cursor moves slower on the 27", at 0.8x the speed.
For 3D sensitivity, your sensitivity will feel faster on the 27", 1.125x the speed.
This is because you have the same field of view on the new screen, even though it is a larger size.  You need to have a higher fov on the larger screen, maintaining the original 110 fov within the 24" portion of your new 27" screen.  Using 110 on the new 27" is the same as using ~103.5 on the old 24".  If you want to have identical sensitivity, you need to increase the field of view on the 27" to ~116.2. If you don't adjust the fov, you would have to reduce your sensitivity by 0.888x instead (cm/360 will increase by 1.125x), which will be identical to converting from 110 fov to 103.5 fov using monitor distance 0%.
 
tldr: You need to use 110 fov on the 24" and 116.2 fov on the 27".
 

There is less degrees on the screen (lower degree/pixel), so if you continue to rotate the same degree/count then you will rotate more pixels. You have to reduce the degree/count to rotate the same degree/pixels, and end up with a longer distance to rotate 360 degrees.
 
Degree/pixels only uses the middle pixels. If you know there is a total of 103 degrees horizontally (Overwatch), which is across 1920 pixels, then you can scale that down to find how many there is in 1 pixel.
2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi = ~0.075032  
If you drop to 30 degrees vertically (Overwatch Widowmaker), then you end up with less degree/pixel.
2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi = ~0.02843  
Since the game rotates a fixed amount of degrees/count for each unit of sensitivity, you will want to reduce the sensitivity when you scope in (by ~0.028/0.075) to keep the same pixel ratio. When scoped, you will have to rotate ~38% of the original amount to preserve the sensitivity of the mouse, but you will end up with the inconvenience of a larger distance to turn 360 degrees.
(2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi) / (2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi) = ~0.378909  

There is less degrees on the screen (lower degree/pixel), so if you continue to rotate the same degree/count then you will rotate more pixels. You have to reduce the degree/count to rotate the same degree/pixels, and end up with a longer distance to rotate 360 degrees.
 
Degree/pixels only uses the middle pixels. If you know there is a total of 103 degrees horizontally (Overwatch), which is across 1920 pixels, then you can scale that down to find how many there is in 1 pixel.
2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi = ~0.075032  
If you drop to 30 degrees vertically (Overwatch Widowmaker), then you end up with less degree/pixel.
2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi = ~0.02843  
Since the game rotates a fixed amount of degrees/count for each unit of sensitivity, you will want to reduce the sensitivity when you scope in (by ~0.028/0.075) to keep the same pixel ratio. When scoped, you will have to rotate ~38% of the original amount to preserve the sensitivity of the mouse, but you will end up with the inconvenience of a larger distance to turn 360 degrees.
(2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi) / (2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi) = ~0.378909  

If they are the same aspect ratio, then the 32in monitor will have 105.96 fov inside the 24.5" region of the screen.

Monitor distance 0% is also for 2d to 3d. The distance to move the cursor 1 pixel is the same distance to turn 1 pixel. If you measure the fov in the 4 adjacent middle pixels, you will turn half that.

There is less degrees on the screen (lower degree/pixel), so if you continue to rotate the same degree/count then you will rotate more pixels. You have to reduce the degree/count to rotate the same degree/pixels, and end up with a longer distance to rotate 360 degrees.
 
Degree/pixels only uses the middle pixels. If you know there is a total of 103 degrees horizontally (Overwatch), which is across 1920 pixels, then you can scale that down to find how many there is in 1 pixel.
2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi = ~0.075032  
If you drop to 30 degrees vertically (Overwatch Widowmaker), then you end up with less degree/pixel.
2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi = ~0.02843  
Since the game rotates a fixed amount of degrees/count for each unit of sensitivity, you will want to reduce the sensitivity when you scope in (by ~0.028/0.075) to keep the same pixel ratio. When scoped, you will have to rotate ~38% of the original amount to preserve the sensitivity of the mouse, but you will end up with the inconvenience of a larger distance to turn 360 degrees.
(2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi) / (2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi) = ~0.378909  

There is less degrees on the screen (lower degree/pixel), so if you continue to rotate the same degree/count then you will rotate more pixels. You have to reduce the degree/count to rotate the same degree/pixels, and end up with a longer distance to rotate 360 degrees.
 
Degree/pixels only uses the middle pixels. If you know there is a total of 103 degrees horizontally (Overwatch), which is across 1920 pixels, then you can scale that down to find how many there is in 1 pixel.
2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi = ~0.075032  
If you drop to 30 degrees vertically (Overwatch Widowmaker), then you end up with less degree/pixel.
2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi = ~0.02843  
Since the game rotates a fixed amount of degrees/count for each unit of sensitivity, you will want to reduce the sensitivity when you scope in (by ~0.028/0.075) to keep the same pixel ratio. When scoped, you will have to rotate ~38% of the original amount to preserve the sensitivity of the mouse, but you will end up with the inconvenience of a larger distance to turn 360 degrees.
(2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi) / (2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi) = ~0.378909  

MDV 177.78% with 90% scale.

It's not that complicated. It's all about the physical scale of the image you see. If the scale changes, then sensitivity changes as well and you need to adjust the cm/360 to fix it. Treat the monitor as a window that you look through.
 
Think of the resolution, fov, and monitor as an image resizer. If any of these change the physical size of the image, then you need to change your cm/360 by the same amount (monitor distance 0%).
You will need to change the cm/360 in these cases because they will change physical size of the game:
Different fov on the same monitor Same fov on different sized monitors Reducing resolution without upscaling Changing aspect ratio in a horizontal fov game  
 
Start with 103 fov at 1080p

 
If you reduce the resolution to 720p without upscaling it, then you have shrank the physical size of the image by 66.67% of the original size.
You will want to reduce your cm/360 to 66.66% of the original value as well.

 
This is identical to zooming out 1.5x to ~124 fov. (2 * atan(3/2 * tan(103/2 * pi/180)) * 180/pi = ~124).
This shows that the resolution can be used as an FOV slider if you want, you just don't get to see the extra fov since its black.

 
 
Here we change the fov to 162 fov. It is a 5x zoom difference. It practically shrank the image to 20% of the original, so your cm/360 needs to shrink to 20% of the original value as well.

 
 
Here is 103 fov resized to 20%, overlayed on the 162 fov. If this monitor was 5x larger than the above, then there would be no need to change the cm/360. The physical size of the 103 fov area in yellow would be identical to the monitor above. Since the monitor is basically a window that you are looking through, the 5x bigger window provides the extra fov.

 
 
Here is the 162 fov image resized 500%. You can see that it's identical to 103 fov.

 

If you reduce the resolution width to go from 16:9 to 4:3, and it only crops off the sides, then there is no change to the physical size of the image and no change to the sensitivity.

 
If the game uses horizontal fov though, and it tries to keep the 103 on 1440px instead of 1920px, then there is a 75% scale difference (1440/1920). So your cm/360 needs to be 75% of the original value as well.

 
This 75% reduction results in an equivalent fov of ~118 (2 * atan(1920/1440 * tan(103/2 * pi/180)) * 180/pi).

It's not that complicated. It's all about the physical scale of the image you see. If the scale changes, then sensitivity changes as well and you need to adjust the cm/360 to fix it. Treat the monitor as a window that you look through.
 
Think of the resolution, fov, and monitor as an image resizer. If any of these change the physical size of the image, then you need to change your cm/360 by the same amount (monitor distance 0%).
You will need to change the cm/360 in these cases because they will change physical size of the game:
Different fov on the same monitor Same fov on different sized monitors Reducing resolution without upscaling Changing aspect ratio in a horizontal fov game  
 
Start with 103 fov at 1080p

 
If you reduce the resolution to 720p without upscaling it, then you have shrank the physical size of the image by 66.67% of the original size.
You will want to reduce your cm/360 to 66.66% of the original value as well.

 
This is identical to zooming out 1.5x to ~124 fov. (2 * atan(3/2 * tan(103/2 * pi/180)) * 180/pi = ~124).
This shows that the resolution can be used as an FOV slider if you want, you just don't get to see the extra fov since its black.

 
 
Here we change the fov to 162 fov. It is a 5x zoom difference. It practically shrank the image to 20% of the original, so your cm/360 needs to shrink to 20% of the original value as well.

 
 
Here is 103 fov resized to 20%, overlayed on the 162 fov. If this monitor was 5x larger than the above, then there would be no need to change the cm/360. The physical size of the 103 fov area in yellow would be identical to the monitor above. Since the monitor is basically a window that you are looking through, the 5x bigger window provides the extra fov.

 
 
Here is the 162 fov image resized 500%. You can see that it's identical to 103 fov.

 

If you reduce the resolution width to go from 16:9 to 4:3, and it only crops off the sides, then there is no change to the physical size of the image and no change to the sensitivity.

 
If the game uses horizontal fov though, and it tries to keep the 103 on 1440px instead of 1920px, then there is a 75% scale difference (1440/1920). So your cm/360 needs to be 75% of the original value as well.

 
This 75% reduction results in an equivalent fov of ~118 (2 * atan(1920/1440 * tan(103/2 * pi/180)) * 180/pi).

2304x1440 was stretched horizontally by 1.111x, so you need to use 3456x1600.
2304 is 90% of 2560. 90% of 3840 is 3456. 3840 / 3456 = 10/9.

MDV 177.78% with 90% scale.

Ignore the ingame fov slider. Your actual horizontal 4:3 fov is 70 * cl_fovscale.
 
This converts cl_fovScale to ingame fov slider, no idea why its like this but it shows you can just ignore the ingame slider value as it is nonsense:
(cl_fovScale * 70)/0.9625 - 70/0.9625 + 70

Converting sensitivity is all about making the camera respond in a way that you expect. If you are expecting a very specific wrist flick to always make a 90 degree turn, then you would want to use the 360 distance conversion. If you expect it to always rotate somewhere close to the edge of the screen, then you use a specific monitor distance %. I personally don't think this way, and I want the turn amount to scale by the actual change in the image that I see when I go from hipfire to ADS. If I see the image change by a factor of 2 when I rightclick, then I'm expecting the turn amount to scale by a factor of 2 as well. 0% is going to give me the sensitivity that I am expecting.
The other matches only help preserve a very specific characteristic. So I don't bother with them. People probably use a specific distance % at first for the sole intention of matching a distance, but then it later becomes a matter of picking a % that gives a certain speed that they like. After all, the distance % only works between 2 points, no where before or after, and only purely vertical in 100% of cases, and horizontal in a niche case. Diagonal doesn't work because the pitch of the camera affects the yaw, and at a high fov, diagonal movement within your view, is creating a much larger deviation in pitch compared to a low fov.

The apex legends fov slider doesnt show any decimals. You can slide it to multiple steps and it will still say 104, so you won't end up with exactly 104 (1.4675 cl_fovScale). You have to look at your config to get your true fov. Your value of 1.471401 is ~104.2836. So what you want to do is set up apex legends first, then open its config file and then transfer those values (because these are your true values) to aim lab to train your aim, or mouse-sensitivity to convert to other games.
 
Here I set game units to config file, put in your values, and then flipped it back to in-game units. You can see the fov is not exactly 104, and its matching mouse-sensitivity's 360 distance on the scope, which scales from fov. If the fov was wrong it would scale to the ADS incorrectly.

 
You can also use this calculator to see how buggy apex is https://jscalc.io/embed/Q1gf45VCY4tmm2dq

If you change the profile in Aim Lab it will set the fov to the default fov of that game. Aim Lab's default fov is 70 (102.45 horizontal), thats why you are getting 102 after you change profiles. Why are you changing profiles anyway? Just set the profile to Apex Legends and put in the values. The Angle of View values will only show 2 decimals and the cm/360 will only show 3 decimals, but other than that it is the same.

 

I think you're going about it wrong. You're trying to make the cursor behave weird instead of just panning the screen or making the desktop 3D. The distances are affected in 3D because there is distortion and curvature, so it makes no sense for the cursor to behave weird when the 2D desktop has neither. It's already behaving how it is supposed to. If you decrease the FOV, which decreases the distortion and curvature, you will see that the mouse characteristics already start to resemble 2D more and more as you approach 0 FOV. At 1 FOV any conversion method in the calculator (Jedi's Trick has to be set to 1:1 resolution) will approximately match the speed and distance of the cursor.
If you want to simulate 3D aiming then you have to move the screen instead of the cursor (e.g. panning in a photo viewer, or playing mcOsu's original fps mod, not fposu). If you want the speed of the desktop, with the distances reflecting the distortion on the screen, then you just convert using 0%. It doesn't matter what FOV you convert to/from, the cursor will increment 1 pixel for each count, and the camera will rotate 1 center pixel's worth of degrees. The circumference of the 3D projection (the red sphere in your diagram) divided by the distance to travel the projection's circumference (the cm/360, and the orange sphere in your diagram), will be identical to the distance the cursor travels divided by the distance the hand/mouse travels.

Just note that this isn't true. It will only match perfectly for the pure horizontal or vertical points. The reason is because the aim will curve with the pitch as soon as you deviate away from the equator. Any movement that isn't pure yaw/horizontal, is a change in pitch. Even pure yaw movement is circumstantial. As an extreme case, look straight up or down, your aim will be so curved you will be a spinning ballerina, yaw movement will not reach the point on the ring. Diagonal movement will not perfectly match a point on the ring either. The only movement that will reach a point on the ring would be vertical movement.
2D is flat, so the cursor always moves in a predictable way. 3D isn't, only pure vertical movement is always moving the shortest path and will match the point on the ring. Horizontal is circumstantial, requires a pretty neutral pitch. Diagonal will not match any point. This is a reason why I think monitor 'distance matching' isn't helpful in any meaningful way. The result is just an arbitrary change in sensitivity that may happen to be close to preference.

I wouldn't bother going through the effort of converting your old sensitivity. You have already gotten used to your new sensitivity, and the change would have been small. Something like this for example:
24.5" to 27", still 90 4:3 fov, and still 1920x1080. Only variable that changed was the monitor size.
On the 27" that 90 fov would be equivalent to 84 fov on the 24.5", which isnt what you played at.
90 fov on the 24.5" is equivalent to 96 fov on the 27", which also isnt what you are playing at.
If you want to keep the same cm/360, you have to use 96 fov on the 27". Since you are still using 90 fov, you have to scale the cm/360 using focal lengths. You can find the change in focal length by simply comparing monitor size since thats the only variable that changed. 24.5/27 is the change in focal length. 10%. If it was fov instead, you would just compare fovs, using TAN(BeforeFOV/2 * PI/180) / TAN(AfterFOV/2 * PI/180), in this case you would do 84 and 90, or 90 and 96, both would also give 10%.


 
 
This calculator is nice for visualising the focal length.
It's showing the measurement in pixels though, for the physical measurement you need monitor size and resolution to figure out how large a pixel is.
Screen size is diagonal, so you need diagonal resolution to get pixel size.
Assuming a standard 240hz 1920x1080 24.5" monitor, playing Overwatch at 103 FOV 16:9 with 5 sensitivity and 800 Mouse DPI.
DiagonalResolution (pixels)
= SQRT(HorizontalResolution^2 + VerticalResolution^2)
= SQRT(1920^2 + 1080^2)
= 2202.9071700822983
PixelSize (cm)
= (ScreenSize * 2.54) / DiagonalResolution
= (24.5 * 2.54) / SQRT(1920^2 + 1080^2)
= 0.02824903420586495
VerticalFOV (degrees)
= (360 * ATAN(TAN(103/2 * PI/180) / (16/9))) / PI
= 70.53280043291679
FocalLength (pixels)
= (VerticalResolution/2) / TAN(VerticalFOV/2 * PI/180)
= (1080/2) / TAN(((360 * ATAN(TAN(103/2 * PI/180) / (16/9))) / PI)/2 * pi/180)
= 763.6184800011152
ProjectionRadius (cm)
= FocalLength * PixelSize
= ((1080/2) / TAN(((360 * ATAN(TAN(103/2 * PI/180) / (16/9))) / PI)/2 * pi/180)) * ((24.5 * 2.54) / SQRT(1920^2 + 1080^2))
= 21.571484561782103
ProjectionCircumference (cm)
= ProjectionRadius * 2 * PI
= (((1080/2) / TAN(((360 * ATAN(TAN(103/2 * PI/180) / (16/9))) / PI)/2 * pi/180)) * ((24.5 * 2.54) / SQRT(1920^2 + 1080^2))) * 2 * PI
= 135.5376348526406
SensitivityCircumference (cm)
= 360 / (Sensitivity * Yaw * MouseDPI/2.54)
= 360 / (5 * 0.0066 * 800/2.54)
= 34.63636363636364
RealSensitivity (visuomotor ratio)
= ProjectionCircumference / SensitivityCircumference
= 135.5376348526406 / 34.63636363636364
= 3.9131600613623263
Or
SensitivityCircumference (cm)
= ProjectionCircumference / RealSensitivity
= 135.5376348526406 / 3.9131600613623263
= 34.63636363636364

The best thing about focal length is that you can use it to calculate your true, universal sensitivity value, taking all variables into account. Maybe it will become the standard measurement to share how fast your sensitivity is with someone in the future, who knows. At the moment people share cm/360 values, but that is only slightly better than sharing eDPI values. It still doesn't tell anyone how sensitive the mouse is as you don't know their monitor size, fov, and how much of the monitor that fov is occupying. All it really tells you is how tedious it is to turn corners and change directions.
Basically the focal length is the radius of the projection, and the length of the radius will vary depending on the fov and how large a pixel is (resolution and monitor size). You use the radius to calculate the circumference. The size of the circumference becomes your cm/360 (which is also a circumference). You then divide that cm/360 by a number. That number is your universal sensitivity value, which I call visuomotor since it's a ratio between visual and motor. If you have a sensitivity of 4, then your projection's circumference is always 4x larger than your sensitivity's circumference (cm/360).
It is similar to getting your real 2D sensitivity, which is how fast/far the cursor travels relative to your mouse. If you have a sensitivity of 4, then your cursor moves 4x faster/further than your mouse. If you convert 0% mm from windows to a game, then your universal sensitivity value becomes the same as your real 2D sensitivity. Your camera moves at the same speed as the cursor. The distances to reach things on the screen is all different though but that doesn't matter, that's the pitfall of monitor distance.

But yeah, if you are just scaling sensitivity between fovs, without changing anything else, then you can safely use 0% mm. It will calculate the change thats happening to the focal length / radius, and change your cm/360 by the same factor. Both of those spheres in the picture will scale by the same rate, and 0% will keep that ratio the same.

If you match at 0%, you will judge the necessary mouse distances properly, since the distances scale proportionately with the fov, whereas any other method is going to be counter intuitive for this, despite the whole concept being to match a a perceived speed or match a screen distance.
Instead, these alternative methods give the illusion of better, more consistent aim because they maintain the area on your mouse pad that you use to aim within your field of view. This lets you become very proficient in a single aiming style/method (such as wrist aiming) with specific swiping distances as you don't have to scale your input with the fov.
It also lets you get away with low sensitivity at high fovs (people reduce sensitivity for instant results instead of just improving their mechanical skill) due to the same reason, not having to scale your input.
Since 0% does not match a distance, it instead matches the velocity, and since other methods are not 0%, they have to result in different speeds in order to accomplish what they were made to do. Matching the velocity has to result in different perceived speeds and different required mouse movement as every fov is unique. The amount of information and distortion scales with the fov. The very essence of increasing the fov is increasing the number of degrees that you can see. So naturally, if you pan the camera, there is going to be a lot more activity on your screen and it is going to look faster than a lower, flatter, more zoomed in fov. So it makes sense that the correct conversion is going to be something where the distance and view speed is not matched. If you do match the view speed instead, then you are slowing the velocity of the camera down for high fovs and increasing the velocity for low fovs in order to make them look the same. The biggest issue with this is that low fovs will feel too sensitive as the required mouse distances are far shorter than assumed. Only 0% will have the correct distance scaling.
The reason why you can judge distances properly with 0% is because the distance scales with the zoom. If you zoom in 2x, the target will be 2x further away on your screen, and will require 2x more mouse movement to flick to compared to before the zoom. If you make this a fair comparison and scale the distance between you and the target to counteract the zoom, then the mouse distances will be the same. This will also benefit tracking, since the perceived movement speed, size, and distance of the movement will scale with the zoom, and so will the sensitivity. So if the distance between you and the target scales with the zoom also, then a target will move the same speed across your screen, and require the exact same mouse movement.
As for the question about 'match at' percentages and matching a distance in general, the best distance match IMO is the inverse of your aspect ratio, multiplied by 100. E.g. 9/16 * 100 = 56.25. It will match the distance to the radius of the 1:1 aspect ratio. Higher percentages, like 75% are close to matching viewspeed, which suffers from the sensitive low FOV issue. Besides, all distance match methods are arbitrary, and you will get drastically different results depending on what fov measurement you use. 0% is the only method that has the same result regardless of the measurement used.
Matching the view speed, screen distance, or 360 distance, is only going to be detrimental to aim performance in the long run. You will have to compromise and develop unique muscle memory for a wide range of fov and hope that your brain can fill in the blanks for fovs in between. These methods will only improve comfort and may give better results, but only in the short term (due to being only proficient in one aiming style, or having a low sensitivity for a high fov, or not having enough mouse pad space in general). They only seem correct because when you zoom in/out, the distance between you and the reference point is remaining static, you don't teleport forward/back to counteract the zoom.
For long term, you need to get used to 0%. Ignore the deceptive issues with view speed and the variance in mouse movement. You won't really have to develop muscle memory for every fov, as you will figure out the distances automatically as they scale with the zoom, but the different distances will require you to master your aim with all the styles, such as micro, finger, wrist, and arm (from elbow and shoulder) movement, and you will probably have to use a higher sensitivity in general.
 
And yes, for anyone wondering, I have switched over to 0%.

You only need to change to 116 fov, everything else can be the same. It will be the same as using your 24", except the extra 3" is providing extra fov.