Perceived sensitivity

[MuntyYy]

37 minutes ago, Drimzi said:

As for this 'gear ratio', anything can be a gear ratio. 100% is the 'gear ratio' for the horizontal angle. 56.25% is the 'gear ratio' for the vertical angle. 0% is the 'gear ratio' for the focal length.

Thank you, good to know.

37 minutes ago, Drimzi said:

unless it is purely horizontal

I don't quite understand this. What does "purely horizontal" imply ? the exact center of the projection ?

37 minutes ago, Drimzi said:

If you matched 10cm to 100%, then looked straight up and then tried to do a 10cm movement to reach a target at the horizontal edge of the screen, it's not going to work (although I haven't checked if 10cm with a specific trajectory would work).

If you look straight up and the target is at your left of your screen ( assuming its enemy and not some sort of practice entity )  its not possible to see it, as you need to go diagonally to do so. Or are you trying to say that as you go up or down on the y axis the projection bends creating eclipses and circles therefore monitor match is unusable? 

Edited July 27, 2018 by MuntyYy

[CaptaPraelium]

On 7/26/2018 at 6:59 PM, potato psoas said:

I don't even think we need to worry about distortion anyway. If we practice enough, we will eventually develop muscle memory for every FOV that we use. It's the price we pay for wanting to zoom in.

Also, I already tried to find the "most optimal method", but I abandoned that idea, because if you aren't maintaining the same match point then you are no longer abiding by the gear ratio principle - the entire concept behind how we sync sensitivity.

 

I'm all for changing monitor match to angle match too. That's what I've been talking about in my forum post with regard to getting screen distance and sitting distance added to the calculator, since they definitely affect perceived sensitivity.

I made some diagrams, demonstrating that if you match the physical monitor distance to the same visual angle, then you can use exactly the same sensitivity.

Or another way to look at it is if different in-game FOVs were matched with their real life visual angle then we wouldn't need to convert sensitivity either. Only problem is that we can't move the monitor backwards and forwards. Not that we'd want to though - we are zooming in for a reason.

Sitting distance affects perceived size and it's the very reason why we have to convert sensitivity in the first place.

Well if we don't worry about distortion then the correct answer is simply using the ratio of the FOV angles, aka 100% vertical aka 56.25% Monitor Match.
If we account for distortion then we can't maintain a constant ratio and the gear ratio concept (including 0% MM) can't work.

Quote

Sitting distance affects perceived size and it's the very reason why we have to convert sensitivity in the first place.

I'm re-quoting this because it's CRITICAL that people understand this and it's generally entirely overlooked. The perceived size resulting from our perceived visual angle is the entire basis for our sensation of space and the change in these angles and sizes resulting from changes in FOV are the entire reason why we feel a need for a change in sensitivity. You're completely right and all the science I have been able to find completely concurs with this.

In my geogebra demo linked above, I considered the actual viewing FOV (based on viewing distance) and confirmed that the end result is the same. You can click on the white circles along the left edge to show those graphs, I hid them once I confirmed what skwuruhl said earlier.... HOWEVER, I'm unsure if the same will apply when we are dividing the integrals and differentials of that equation which would be used to find the average or mean (not sure which is most correct yet, haven't gotten that far!) sensitivity dividers based on screen space (or beyond). I honestly have no idea, and this may turn out to be significant, or it may just turn out to be what we have so far where it cancels out like 'fova/factual/fovb/factual == fova/fovb'

On 7/26/2018 at 7:07 PM, cincinnatus said:

Sorry, I'm very confused. You say indefinite integral but then say it has limits - is that just a typo? The inverse of which function? Do you need to find the inverse of f(x) and then integrate with those limits or are you trying to find the indefinite integral and then find the inverse of that function? Or are you just trying to find the definite integral, and then do 1/result? 

This seems to contradict what you were saying in the first quote.

Are you just trying to integrate  ((tan(c) tan^(-1)(x tan(C)))/(x^2 tan^2(c) + 1) - (tan(C) tan^(-1)(x tan(c)))/(x^2 tan^2(C) + 1))/tan^(-1)(x tan(C))^2 ? 

Is that result from the mean value theory? Doesn't make sense to me, you still have x in the result. Also doesn't make sense if that's not from MVT and it's from taking the derivative directly - for one, doesn't look like the correct derivative, and secondly, in that case integrating wouldn't accomplish anything - it would just return the original function and you seem to want to integrate the result. 

Wouldn't you just set the MVT result equal to the derivative of f(x), and solve for x? In which case, what and why are you integrating? Is the final goal to get f(c) once you get c? As in, just plug c in for x in h(x) from the geogebra page?

Would like to try to help with the calculations and I've put most of your equations into mathcad, but I'm totally lost as to what you're trying to do.

Don't be sorry, it's my bad and yes that's a typo, well, I said the wrong thing. Definite integral is the thing we're after here.... I think? Please forgive my mathematical errors, I learned this stuff over 20 years ago and haven't used it since and have basically forgotten it all and am re-learning as I go. While I'm making apologies, I should say sorry for taking so long to reply, I've been unable to use my arm for a while....

I'm under the impression that in order to find f`(c) we need to integrate f(x) ?? (Quite possibly completely wrong!) By using that, we can find f`(c) and we would need to find the value of c in order to find f(c).

You're right that MVT is what I'm trying to do here, but naturally I mean to do it without manual interaction, just by punching in values for the two fovs, the two extents of the screen (limits?) and spitting out a sensitivity divider as a result. You appear to know more about it than I do so by all means feel free to laugh at my math noobiness and show us how it's done I appreciate how gentle you've been so far hahaha

Basically, it appears you've understood it completely, and I am certainly really really bad at this and even worse at explaining it.
 

[Drimzi]

On 7/27/2018 at 7:48 PM, MuntyYy said:

Thank you, good to know.

I don't quite understand this. What does "purely horizontal" imply ? the exact center of the projection ?

If you look straight up and the target is at your left of your screen ( assuming its enemy and not some sort of practice entity )  its not possible to see it, as you need to go diagonally to do so. Or are you trying to say that as you go up or down on the y axis the projection bends creating eclipses and circles therefore monitor match is unusable? 

Monitor match is always usable, I'm just saying that it is a bit misleading. It scales the sensitivity using the angle ratio, the angle used being a specific percentage of the horizontal angle. The amount you rotate per count obeys this, it works as intended. I'm just highlighting the fact that the monitor distance match rule, the main marketing point for this method (remember that people pay actual money for this conversion), is not always true. It's always true using a script to send counts vertically, but horizontally is only true when the pitch is somewhat neutral. Anywhere else on the screen and it's not really going to be a match. The main thing to take away from this is it may show that we don't perceive sensitivity using a distance on the screen.

Edited August 2, 2018 by Drimzi

[MuntyYy]

2 hours ago, Drimzi said:

Anywhere else on the screen and it's not really going to be a match

Thank you for the response. I will take a look into this.

[CaptaPraelium]

6 hours ago, Drimzi said:

The main thing to take away from this is it may show that we don't perceive sensitivity using a distance on the screen.

We absolutely don't. https://en.wikipedia.org/wiki/Perceived_visual_angle

[sidtai817]

I have recently discovered and understood the math behind viewspeed v2, which is the sine ratio, and I find it very comfortable. IMO sine ratio really captures the perceived sensitivity on screen.

 

In addition, from what I have read, for viewspeed v2, the radius of the arc crosses the VFOV points, i.e. the top and the bottom of the monitor. It might work for some people who sit at a certain distance at the monitor, but I believe the calculator would be more complete if a percentage monitor distance variable is added for where the arc crosses, just like monitor distance for the tangent ratio. It could be based on HFOV, so 100% represents the arc crossing the monitor on the left and right edge, which is consistent with the percentage of the monitor distance in the tangent ratio. The result is that people can customize it based on how far they sit from the monitor.

 

Another interesting fact of the sensitivity curve for sine is that it tracks really similarly to that of the tangent ratio, just with a different monitor match distance. I have plotted graphs on Desmos to verify that. For example,  the curve of 56.25% distance sine ratio, which is 100% of VFOV, almost overlaps with that of 70.3125% distance tangent ratio, which is 125% of VFOV. I can use 70.3125% monitor match to obtain sensitivities for 100% VFOV sine ratio matching with very little deviation.

 

Personally I am using 129% VFOV matching, which corresponds to 103% VFOV sine ratio matching.

Edited August 10, 2018 by sidtai817