Viewspeed v2

[DNAMTE]

4 hours ago, KandiVan said:

The current formula doesnt make sense to me. Because as you increase your DPI the resultant cm/360 you get from the formula increases. Thats the opposite of what should happen.

? Please clarify. Increasing your DPI and nothing else will obviously increase your sensitivity, thus, reducing your relative mouse movement per full rotation.

Viewspeed certainly does not do the opposite...

[KandiVan]

8 hours ago, DNAMTE said:

? Please clarify. Increasing your DPI and nothing else will obviously increase your sensitivity, thus, reducing your relative mouse movement per full rotation.

Viewspeed certainly does not do the opposite...

Proofread it like 4 times and stil managed to mess it up. Resultant cm/360 increases with increasing dpi with the equation that was on the first page. It has been rectified. IE: sensitivity gets lower as you increase DPI, opposite of what should happen. Its been rectified, anyone reading this dont worry about it LUL

Edited July 6, 2017 by KandiVan

[Drimzi]

Edited January 28, 2018 by Drimzi

[KandiVan]

14 minutes ago, Drimzi said:

New formula. Scales like 0% match, but you can modify the speed. Kind of like using monitor distance match % except it scales with the zoom amount too.

 

Oh boy, let the "which multiplier value should I use" argument begin. What should I use Drimzi LUL

Edited July 7, 2017 by KandiVan

[Drimzi]

Edited January 28, 2018 by Drimzi

[Drimzi]

Edited January 28, 2018 by Drimzi

[KandiVan]

1 hour ago, Drimzi said:

Never mind that formula, it has the same problems with any other formula. It's either too fast or too slow at the extreme FOVs. 0% is great scaling towards 180 degrees but absolutely sucks when scaling down to 0 degrees, 100% is vice versa. I have made a formula that scales directly either way, but now I have added a multiplier for both directions, allowing me to control the match as it scales down and up.

 

(360 (x/θ + z) r sin((π θ)/180))/θ

x = low fov scaler

z = high fov scaler

They both affect each other though, so a perfect balance needs to be found. I found that x = 45 and z = 2 was an okay balance but it's still not perfect all the way. Had to use radius instead to give the multipliers some headroom. If anyone wants to find the perfect balance between x and z, feel free to do so. Don't worry about the overall sensitivity if you got everything matched, that can be scaled afterwards by scaling the desktop length.

 

 

If we eliminate extreme FOV's, have you come up with a "best" match? I'm doing all of the calculations for all of them, and im scaling my inches/360 anywhere from 22 inches -> 30 inches, which is quite a large difference imo. @ 4/11 400 DPI 67 vFOV (99.28 actual hFOV), i find my flicks are most accurate at around 25 inches, but I dont know if thats just muscle memory or an internal consistency with the viewspeed calculation.

Edited July 7, 2017 by KandiVan

[Drimzi]

Edited January 28, 2018 by Drimzi

[Kilroy]

That's why we need a way to quantify that feeling of speed. Now, I realize that that doesn't really make any sense at all, after all speed is a measurement of distance over time, and we can't exactly measure the distance the crosshair moves, or the distance the environment moves. In the first place, the virtual environment in the game just isn't the same as reality, obviously. Maybe I'm missing something, because I can't completely understand what was being explained to me when the whole viewspeed idea was conceived.

But what I know for sure, is that we can't just rely on our human, fallible senses to figure these things out. There's the placebo effect, there's the fact that the projection of the 3d virtual reality on our 2d monitors is distorted no matter what, ( http://shaunlebron.github.io/visualizing-projections/ ) and many other factors. Maybe you'll wake up on the wrong side of bed, and the current viewspeed formula feels wrong again.

We need to also consider the possibility that it isn't possible to unify the feeling of speed across fovs, because that could be entirely true as well.

[Drimzi]

Edited January 28, 2018 by Drimzi

[Kilroy]

Wait, doesn't higher fov mean higher sensitivity? Why does the aug ( 57.82 hfov) have a slightly lower sensitivity than the 1x awp/scout/autos (51.77 hfov).

Unless those fov numbers are wrong... (I'm pretty sure they're 45 then 40 ingame).

 

Edit: Nope nevermind, they're not calculated in the same way, ingame.

Edited July 8, 2017 by Kilroy

[CaptaPraelium]

Quite a few serious battlefield players are eyeballing this thread, if there's any way we can test or help with number crunching please let us know

[Drimzi]

Edited January 28, 2018 by Drimzi

[Kilroy]

Hello,

I'm still futilely trying to figure out how to test for viewspeed, but in the meantime, I thought up a way to expand and better our current method of "does this formula feel right". What I think we should do is try this guy's mods on quake or minecraft which allow for various different projections of the 3d environment. Doing so will not only make it easier to figure out what's going on at high fovs, but it will also allow for us to try to use it at any fov, and by that I mean even up to 360 degrees. Of course there's almost no reason as to why we need a formula that works for such a range, but maybe the formula that works for <180 fov also works for 0 to 360. If not, still useful to see what's going on at the 179 to 130 range so we can test for our goal. Keep in mind that it is still distorted, only now it would be in different ways. Also these mods/ demo are probably pretty laggy, which introduces input lag if you run games on a potato like me.

Here's a video by a guy called Econael to show it off.

This is the link to the quake demo in which we can try it out for free. I don't have quake 1 or minecraft so this is what I'll do, maybe borrow an mc account from a friend. 

https://github.com/shaunlebron/blinky/blob/master/README.md

Here, you can mod the entirety of quake 1 if you have that game.

https://github.com/shaunlebron/blinky/wiki/Using-with-full-version-of-Quake

Finally this is a mod for minecraft. I don't right now if you can get in trouble, anti-cheat wise for using this in a multiplayer server, and you might also have to download this thing called optifine?

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/2738385-render-360-unlimited-fov

[Drimzi]

Edited January 28, 2018 by Drimzi

[iBerggman]

nvm

Edited August 16, 2017 by iBerggman

[Skwuruhl]

5 hours ago, Drimzi said:

I'm not working on this anymore, I ran out of theoretical ideas and ended up just plugging random stuff in trying to make it match at a higher % at lower fovs and lower % at higher fovs.

I know for me that going from 106.26 fov (90) to 63.74 fov (50), 100% monitor match feels a lot better than viewspeed and at 170 fov 0% felt best, but I don't know how to make a formula that scales like this.

Hm, maybe instead you like to match a degree instead of distance? So for 63.74° you use 100% match distance but for 170° you'd use 5.4% match distance. Your "base" degree would be personal preference and there's no magic number. But just as you approach 180° the match distance approaches 0, as you approach 0° the match distance will approach infinity. If you want to play around with it this will output what % of your hipfire sensitivity should be of your zoom sensitivity. So with what's already there, if your hipfire is 106.26 and zoom is 40 with a "match degree" of 63.74 then your zoom sensitivity would be 0.48 times hipfire. I expect this will feel far too high especially at lower FOVs due to the match distance thing but I could be wrong.

Edited July 19, 2017 by Skwuruhl

[Kilroy]

Eh, I'm just gonna (360/fov)(edge to edge) now, until I can figure something out. If it doesn't matter what formula to use, for some reason I'd rather it be that, because I've gotten used to it.

Edited July 19, 2017 by Kilroy

[Drimzi]

Edited January 28, 2018 by Drimzi

[Drimzi]

Edited January 28, 2018 by Drimzi

[Drimzi]

Edited January 28, 2018 by Drimzi

[DNAMTE]

The reason you cant seem to find a one fits all is because of distortion.

Using lower FOV 's, the distortion is minimal, as you increase your FOV, when rotating your view space, from edge to centre displays a vastly different velocity. Peripheral vision is absolutely a primary tool when lining up your shots, your brain needs a reference of velocity and time to predict the next headshot. Having such a large variance makes it harder to land shots consistently, there's a reason 'black bars' are so popular, they remove much of the distortion, allowing you and your brain to focus on fewer variables.

All the above would be 'Virtual FOV'. We do however have a constant 'physical FOV'. More on this later, I've discovered a relationship that may help put a logical formula to ALL FOV.

[CaptaPraelium]

On 10/07/2017 at 8:41 PM, Drimzi said:

Well the aim is to have a sensitivity that feels the same at all FOVs. The correct formula should accomplish this, and it will only be correct IMO if it works all the way from 1 FOV to 179 FOV.

In order to do this, it can't be a static coefficient where all FOVs meet up at the same point on the monitor. 0% monitor match, where the sensitivity scales directly with the zoom amount is also not a solution as it feels far too slow as the FOV decreases.

I reckon the correct formula will scale between 0% and 100% depending on the FOV, but could probably exceed 100%. I think 100% as the FOV is extremely low and 0% as the FOV is extremely high.

If you want to help test, you can manually find the sensitivity that feels correct at various FOV settings, where they match your base sensitivity and then post your results. See what the monitor match percentage is for each FOV when they scale from your base FOV & sensitivity. This will help define the requirements for the formula.

If you want to help with formula, here are some various things:

 

Circle Formulas

Radius = R = half of desktop length (resolution width / mouse dpi for inch, * 2.54 for cm)

Diameter = 2R

Circumference = 2R π

Chord length = 2R sin((π θ)/360)

Arc length = R π (θ/180)

Arc height / Sagitta = 2R sin^2((π θ)/720) or R(1-cos(θ°/2))

Length from opposite end of circle to chord  = R(1+cos(θ°/2))

Apothem = R cos((π θ)/360)

 

 

Notable FOV Ratio values

FOV Ratio = 1/tan((π θ)/360)  or  cot((π θ)/360)

cot((π 45)/360) = 2.4142

csc((π 45)/180) = 1.4142

tan((π 45)/360) = 0.4142

 

 

Formulas:

Current Viewspeed, based on 100% = ((360/θ) (2R)) ((2R sin((π θ)/360)) / (R π (θ/180)))

100% Monitor Match = (360/θ) (2R)

0% Monitor Match = ((360/θ) (R π (θ/180)) ((tan((π θ)/360))))  or  ((2R π) cot((π θ)/360))

Viewspeed, based on 0% = (1/360 π^2 2R θ cot((π θ)/360) csc((π θ)/360))

 

Thanks man But what I really wonder is, how do we get a sensitivity into the game?
Obviously we can work out our base (hipfire) sens as a cm/360 and punch it into the calculator, but what about other zoom levels? If I know my cm/360 or counts/degree or whatever the rate of turn might be, for a certain FOV, how do I convert that number, into a multiplier value for a specific zoom level?

For example: As an experiment, I wanted to see how it feels if I ignore distortion altogether. So my hipfire is 42cm/360 at 79degrees FOV and I can use the calculator to find that is a base sensitivity of 0.004500. No problem there. Now, my 1x zoom is 55degrees and by simple division that gives me a 54.84cm/360 turn rate.... but how do I get that as a multiplier value for GstInput.SoldierZoomSensitivity1x00 in the config file?

[Drimzi]

Edited January 28, 2018 by Drimzi

[CaptaPraelium]

I think I figured it out, what I have to do is use the calculator to 'convert' from distance with my hipfire, to 360 distance for the same game with the desired zoom level, and manually enter the hipfire sensitivity from the 'from' game, into the 'to' game's Sensitivity 1 field.

I'm doing this because I don't really care to match sensitivity to monitor space, and I think that there's an excessive focus to do so. I want my hand movement to control my soldier movement, regardless of how it may be (mis)represented on screen, so I am ignoring any kind of 2D/3D/distortion/pincushion/etc effects. I don't feel that my mind needs to consider all this distortion, I 'feel' the number of degrees I want to turn and just want to have my mouse move that many degrees (as opposed to moving that many *pixels*). It's all about counts per degree, for me at least.

I feel that the 'answer' to finding a solution that works for me, is related to horizontal vs vertical FOV. For example:
My hipfire is 79 VFOV aka 111.38 HFOV. 42cm 360.
1x scope is 55 VFOV aka 85.57 HFOV.
4x scope is 14.8 VFOV aka 26 HFOV.

Obviously, if my cm/360 is the same at all zoom levels, then when I zoom in at 4x, my mouse will feel overly sensitive, so I need to reduce sensitivity according to zoom. So I should just simply divide my hip FOV by zoom FOV and multiply that by my base sensitivity. So, I do this for HFOV (because I usually think in terms of horizontal FOV) and it works out like so:
1x:
111.38/85.7*42 = 54.66cm/360
4x
111.38/26*42 = 179.92cm/360

Great.
But now I do it for VFOV and:
1x:
79/55*42 = 60.32cm/360
4x:
79/14.8*42 = 224.18cm/360

That's a BIG difference. I haven't had time to think it through beyond this, but I'm sure that I'll find a formula that works for me in such a fashion. I just need to settle the discrepancy between HFOV and VFOV.

Had a couple minutes to consider this and the issue is kinda obvious. What 'makes sense' is that, if I am zoomed in twice as much, I need half the sensitivity. but because the relationship between VFOV and HFOV is nonlinear, the definition of 2*zoom is not as simple as 2*VFOV or 2*HFOV. Of course this is why we see pincushion distortion, but it's not just a matter of an individual's perception, they literally aren't the same.

So I guess the question I need to ask, is: How does one define "2x zoom"?
It's not something we can measure by '2*angle' because of this nonlinear relationship (2* WHICH angle?), and if we use the screen area, then we have a nonlinear ratio of counts per degree which feels unnatural as zoom levels change.

Edited July 23, 2017 by CaptaPraelium
More thoughts