Add something about the sensitivity conversion way of MDH(MDV)

[Weix]

I want to add something about the sensitivity conversion way of MDH(MDV).The monitor distance and the corresponding mouse movement distance are involved in MDH (MDV),but there is one more parameter that is ignored,that's the speed at which a point on the display moves.

Analogous to speed, time, and displacement, the moving distance of the mouse is time,the distance of the monitor is displacement,The speed at which a point is moving is the velocity.First, the calculation formula for the distance of the display can be obtained,then the expression for the instantaneous velocity of movement at this point is the derivative of the displacement.In addition to the monitor distance, there is another kind of displacement expression,which is the sum of the arc length corresponding to a certain point moving a certain distance(denoted as l(arc)).Here is an explanation of why it is a certain point on the display, not the center point,because the center point is always at the center, of course this is nonsense, but because it is always at the center,when the sensitivity is determined, the speed of the center point remains unchanged.What we are going to discuss is the speed of each point on the display. Therefore,we cannot only take the center point (or front sight) as the analysis object.Another important point is that in the process of aiming, we should pay more attention to the target,rather than the front sight at the center point, so the target point is more valuable for discussion.Another point is that my analysis here is based on HFOV. Of course, there is no problem with VFOV, but when it is applied to a specific game, it is necessary to distinguish between HFOV and VFOV. I have made this mistake before.If it is not calculated in a specific game, there is no need to divide HFOV and VFOV, there is no difference between the two,and it can be considered as just two FOVs of different sizes.

X means that the front sight rotates a certain angle, and the mouse moves the distance.

C means the distance that the mouse moves when the front sight rotates for one circle.

 

In this way, the MDH used by the website is obtained under the condition that the display distance is equal and the corresponding mouse movement distance is equal.There are two other cases. The first case is the ratio of sensitivity obtained when the display distance is equal and the corresponding target point moving speed is equal.The second case is obtained when the moving speed of the target point is equal and the corresponding mouse moving distance is equal. Sensitivity Ratio.According to my own calculations, the calculated results in the second case will make the sensitivity ratio too large,and the monitor distance cannot be taken from 0% to 100%, so use the method currently used by the website and the first method.In addition, the idea of MDD is very good, so I will borrow the method of TheNoobPolice,add the idea of dynamic monitor distance.In fact, a in the formula will change with the value of zoomfov.The final formula is in the following website, and I only learned about it because of TheNoobPolice, I am really grateful to him.

https://www.desmos.com/calculator/tkzyfeh3cd?

Because I am Chinese, my English is not good, so I can only use a translator, so please forgive me if I have trouble reading, thank you.

[DPI Wizard]

Interesting idea. If I understand it correctly, you can almost achieve the same result by adjusting the MDD variables?

[Weix]

18 hours ago, DPI Wizard said:

Interesting idea. If I understand it correctly, you can almost achieve the same result by adjusting the MDD variables?

The purpose of this conversion method is that the instantaneous movement speed of the same monitor distance in HIPFOV and ZOOMFOV is the same, which means that in HIPFOV and ZOOMFOV, at the same point on the display, at the moment when the mouse starts to move,the point on the monitor moves at the same speed in HIPFOV and ZOOMFOV.

Another point is that in MDD (v(l)) and MDD (v(arc)), when the value of the display distance is 0, the calculation formula is the same as that of MDH 0%, as mentioned in the previous post In that way, I want to unify, more precisely, systematize.

Another point, how to determine their own sensitivity conversion value (in fact, to determine the value of limit and Power), I have a small suggestion, is to try to determine their own sensitivity conversion value in the larger ZOOMFOV and the sensitivity conversion value in the smaller ZOOMFOV, so that you can get two equations, solve for limit and Power.Below I attach a general reference.

https://www.desmos.com/calculator/1rsicsvgza?

[TheNoobPolice]

As DPI Wizard said, because the point along the radius (i.e the monitor distance) of a circle and the arc length (and therefore also the velocity at said point on the radius) have a consistent relationship with one another, this is more of a convention change as defining whether we interpret those quantities as velocity or arc length instead, because you can always create the same functional output regardless of which quantities you work with as long as you adjust the variables to compensate.

I would argue that monitor distance is a better barometer in our gaming use case, because I believe more gamers have a better grasp on this concept than they would do the others.

I'm glad that my suggestion got you to look at things more though and I'm actually more interested in your second point, which is finding a formula to calculate one-size fits all values for the limit or power variables.

I did not attempt this in my suggestion. If someone said to me "what limit or power should I use?" my answer would have been "how the hell should I know?" The idea was to allow customisation and put this in the hands of the user instead - I used a simple power curve for the coefficient because it allows a great deal of flexibility and is very simple mathematically, but this is fundamentally just defining a curve that goes from 1-0 on an x-axis of "zoom ratio", and you could replace this curve with anything. For example, one of my favourite shapes for a natural rate of change (such as when using acceleration) is the "sigmoid function on log-log plot" I have used in Raw Accel. We could use that in the same way like this - shown with the current coefficient curve method for comparison (I removed the cap because we omitted it from the site implementation anyway as wasn't useful.)

https://www.desmos.com/calculator/xtn91ohke1

Would this feel more natural? One could make all sorts of arguments about the natural logarithm and human perception of change being more logarithmic than linear or exponential, and apply those arguments (probably incorrectly) to this, but ultimately I feel like it's all down to individual perception and prior experience anyway.

But would be interested to see if you find other approaches that might arrive at sensible values more automatically for the existing method.
 

[DPI Wizard]

1 minute ago, TheNoobPolice said:

I did not attempt this in my suggestion. If someone said to me "what limit or power should I use?" my answer would have been "how the hell should I know?" 

MDD is actually quite useful in the next feature I'm working on, which is to reverse-engineer the best method and percent/power/scale values based on existing sensitivity settings. So if you have settings that are a bit out of whack, MDD can sometimes be massaged to fit it better than other methods.

[TheNoobPolice]

1 minute ago, DPI Wizard said:

MDD is actually quite useful in the next feature I'm working on, which is to reverse-engineer the best method and percent/power/scale values based on existing sensitivity settings. So if you have settings that are a bit out of whack, MDD can sometimes be massaged to fit it better than other methods.

That's excellent, it didn't occur for me to have that part of the process embedded in the site also but it makes total sense - that is how I originally found my preference from all the BF4/1 scopes I had set. I just plotted points and adjusted the variables to dissect them all

[DPI Wizard]

1 minute ago, TheNoobPolice said:

That's excellent, it didn't occur for me to have that part of the process embedded in the site also but it makes total sense - that is how I originally found my preference from all the BF4/1 scopes I had set. I just plotted points and adjusted the variables to dissect them all

Yeah, the challenge is that it's not possible to do mathematically, it has to be done programmatically. So it basically has to iterate through tens of thousands of percent/power/scale combinations to find the best ones across all aims. I will make it so it tests both ADS alone, scope alone, and both combined.

This is the work in progress, when it's done it will be in a nicer layout for the result, and have the ability to click the conversion you want to use

[TheNoobPolice]

1 minute ago, DPI Wizard said:

Yeah, the challenge is that it's not possible to do mathematically, it has to be done programmatically. So it basically has to iterate through tens of thousands of percent/power/scale combinations to find the best ones across all aims. I will make it so it tests both ADS alone, scope alone, and both combined.

That's going to be one hell of a for-loop lol
 

3 minutes ago, DPI Wizard said:

when it's done it will be in a nicer layout for the result, and have the ability to click the conversion you want to use

Yeah it's a really innovative feature idea, will be a great time-saver also.

[Weix]

13 hours ago, TheNoobPolice said:

As DPI Wizard said, because the point along the radius (i.e the monitor distance) of a circle and the arc length (and therefore also the velocity at said point on the radius) have a consistent relationship with one another, this is more of a convention change as defining whether we interpret those quantities as velocity or arc length instead, because you can always create the same functional output regardless of which quantities you work with as long as you adjust the variables to compensate.

I would argue that monitor distance is a better barometer in our gaming use case, because I believe more gamers have a better grasp on this concept than they would do the others.

The calculation formula for instantaneous speed created by myself is really not very easy to understand, so I take it as another angle to determine the Zoom sensitivity Multiplier.,just use it as a supplement. Most people understand monitor distance on it.

 

 

13 hours ago, TheNoobPolice said:

I did not attempt this in my suggestion. If someone said to me "what limit or power should I use?" my answer would have been "how the hell should I know?" The idea was to allow customisation and put this in the hands of the user instead - I used a simple power curve for the coefficient because it allows a great deal of flexibility and is very simple mathematically, but this is fundamentally just defining a curve that goes from 1-0 on an x-axis of "zoom ratio", and you could replace this curve with anything. For example, one of my favourite shapes for a natural rate of change (such as when using acceleration) is the "sigmoid function on log-log plot" I have used in Raw Accel. We could use that in the same way like this - shown with the current coefficient curve method for comparison (I removed the cap because we omitted it from the site implementation anyway as wasn't useful.)

https://www.desmos.com/calculator/xtn91ohke1

Would this feel more natural? One could make all sorts of arguments about the natural logarithm and human perception of change being more logarithmic than linear or exponential, and apply those arguments (probably incorrectly) to this, but ultimately I feel like it's all down to individual perception and prior experience anyway.

But would be interested to see if you find other approaches that might arrive at sensible values more automatically for the existing method.

I'm sorry, I don't have a better way. I still lack knowledge in this area. If I have time, I will add relevant knowledge. After all, I also want to find more and better solutions. However, I think your solution is already perfect, and I think the others are just starting from other angles, and there may not be much qualitative improvement. Then, I am looking forward to the work of DPI Wizard.

 

Another point, in fact, I think the sensitivity conversion formula is more of a prediction for all zoomsensitivity multipliers. You can determine several zoomsensitivity multipliers first, and then use these determined values to determine the final sensitivity conversion formula. Just like determining the limit and Power in MDD, in my opinion, the sensitivity conversion formula is an auxiliary, it helps you predict and determine the zoomsensitivity multiplier that you have not practiced, and can get closer to the ideal zoomsensitivity multiplier faster.

Edited June 9, 2023 by Weix
Replenish

[Weix]

11 hours ago, DPI Wizard said:

Yeah, the challenge is that it's not possible to do mathematically, it has to be done programmatically. So it basically has to iterate through tens of thousands of percent/power/scale combinations to find the best ones across all aims. I will make it so it tests both ADS alone, scope alone, and both combined.

This is the work in progress, when it's done it will be in a nicer layout for the result, and have the ability to click the conversion you want to use

Is this working to show the results of the various sensitivity conversion ways? For example, if I use MDH to get a result, what result will it be expressed in other sensitivity conversion methods? Is this the case?If so, it is indeed a big project, I am looking forward to it, because I can see more parameters, so it is more clear.

[Weix]

18 hours ago, TheNoobPolice said:

As DPI Wizard said, because the point along the radius (i.e the monitor distance) of a circle and the arc length (and therefore also the velocity at said point on the radius) have a consistent relationship with one another, this is more of a convention change as defining whether we interpret those quantities as velocity or arc length instead, because you can always create the same functional output regardless of which quantities you work with as long as you adjust the variables to compensate.

I would argue that monitor distance is a better barometer in our gaming use case, because I believe more gamers have a better grasp on this concept than they would do the others.

I'm glad that my suggestion got you to look at things more though and I'm actually more interested in your second point, which is finding a formula to calculate one-size fits all values for the limit or power variables.

I did not attempt this in my suggestion. If someone said to me "what limit or power should I use?" my answer would have been "how the hell should I know?" The idea was to allow customisation and put this in the hands of the user instead - I used a simple power curve for the coefficient because it allows a great deal of flexibility and is very simple mathematically, but this is fundamentally just defining a curve that goes from 1-0 on an x-axis of "zoom ratio", and you could replace this curve with anything. For example, one of my favourite shapes for a natural rate of change (such as when using acceleration) is the "sigmoid function on log-log plot" I have used in Raw Accel. We could use that in the same way like this - shown with the current coefficient curve method for comparison (I removed the cap because we omitted it from the site implementation anyway as wasn't useful.)

https://www.desmos.com/calculator/xtn91ohke1

Would this feel more natural? One could make all sorts of arguments about the natural logarithm and human perception of change being more logarithmic than linear or exponential, and apply those arguments (probably incorrectly) to this, but ultimately I feel like it's all down to individual perception and prior experience anyway.

But would be interested to see if you find other approaches that might arrive at sensible values more automatically for the existing method.
 

I have a general understanding of the sigmoid function. The logistic function can be applied in many places. Now I want to apply it to MDD. The values of L, k, and x0 need to be determined. To make them meaningful, just Things like monitor distance, limit, and power must have purpose and practical significance. I haven’t figured out the content of this aspect yet, and I still need to learn. Your calculation formula is a reference for me, thank you.

Edited June 9, 2023 by Weix

[Mssadg]