scope_zoom_factor

przez **Plaargath** w 08 Lip 2015, 12:42

scope_zoom_factor

przez Plaargath w 08 Lip 2015, 12:42

scope_zoom_factor - wiadomo, liczba, przez którą silnik jakoś przelicza, jak zmienić FOV na potrzeby zooma dla scope'ów i ironsight'ów. Człowiek zmienia sobie FOV'a w grze i może zapomnieć o zgodności opisu lunety z jej faktycznym działaniem. Problem.
Póki co nie spotkałem się z inną metodą dobierania scope_zoom_factor'a niż prób i błędów. Postanowiłem położyć kres tej partyzantce i znaleźć wzór. Oczywiście w pewnym momencie poległem, jednak coś zaświtało. Gdyby ktoś chciał dołączyć do poszukiwań, mogiem wespół w zespół zmóc.

Mam dane pochodzące od kolesia, który dobierał scope_zoom_factor eksperymentalnie i mierzył na ekranie linijką, żeby się z "powiększenie razy x" zgadzało. Wrzuciłem jego dane na wykres, wyszło mi ewidentnie, że to nie jest funkcja liniowa, tylko wymierna hiperbola. Założyłem więc, że scope_zoom_factor musi opisywać jakoś tę krzywoliniowość. Spróbowałem więc na chama wtłoczyć jakieś a i b do wzoru hiperboli, żeby te punkty mniej więcej przynajmniej się zgadzały. Co wyszło:

1. Dla FOV = 83
stałe (szukane metodą prób i błędów):
- a = 124
- b = FOV w radianach = 1,448623279

kolumny:
- kol1 = dana wartość "powiększenia razy x" - uzyskana z pomiarów linijką na ekranie (a więc na pewno jakaś wariancja jest)
- kol2 = wartość scope_zoom_factor - uzyskana z ltx'ów gościa, co tą linijką walczył (a więc zero wariancji)
- kol3 = wyniki testowanego wzoru na scope_zoom_factor: kol3 = a/kol1+b
- kol4 = wyniki testowanego wzoru na "powiększenie razy x": kol4 = a/(kol2-b)

obserwacja:
- manipulowanie stałą "a" sprawia, że kol3 i kol4 przybliżają się do danych w sposób odwrotny (im lepiej dopasuje się kol3 tym gorzej kol4 i odwrotnie) - co chyba ma sens zważywszy na a) ograniczoną precyzję metody linijkowej b) ograniczoną wydajność moich zwojów mózgowych

Kod: Zaznacz wszystko: kol1 kol2 kol3 kol4 1,5 81 84,11528995 1,558741094 1,6 74 78,94862328 1,675675676 2 64 63,44862328 1,985866431 2,7 48 47,37454921 2,676779463 3 44 42,78195661 2,95138777 3,9 34 33,24349507 3,958724482 4 33 32,44862328 4,126646484 5 27 26,24862328 5,381646511 6 22 22,11528995 6,937701976 8 17 16,94862328 10,67276875 10 13 13,84862328 20,45428969

2. Dla FOV = 55
stałe (tutaj też szukane na chama):
- a = 71
- b = FOV w radianach = 0,959931089

kolumny:
- jak wyżej

Kod: Zaznacz wszystko: kol1 kol2 kol3 kol4 1,6 49,03 45,33493109 1,477010572 2 38,1 36,45993109 1,911681967 2,6 26,5 28,2676234 2,779945514 2,7 28,5 27,25622738 2,578061813 4 18,3 18,70993109 4,094562736 5 15 15,15993109 5,056955236

obserwacja: manipulowanie stałą "a" wpływa na kol3 i kol4 tak samo jak wyżej

WNIOSKI:
1) Jakkolwiek prymitywnie i dyletancko to musi wyglądać dla kogoś, kto realnie zna matematykę, nie ulega wątpliwości, że na coś tu wpadłem. Taki sposób liczenia scope_zoom_factor jest dość zbliżony, by czasem przymknąć oko na brak elegancji metody, bo wyniki są całkiem niezłe. Byłoby to więc: szukany scope_zoom_factor dla FOV 55 lub 83 FOV = [odpowiedni wariant stałej "a"] / [wartość pożądanego "przybliżenia razy x"] + FOV w radianach. Z drugiej strony, oczywiście, strasznie to kanciaste.
2) Nie mam pojęcia dlaczego tak a nie inaczej, nie wiem czemu to działa tak jak działa, czemu akurat takie stałe i co one właściwie oznaczają. Ergo - nie mam pojęcia, jak napisać wzór dla innych FOV'ów.

Próbowałem też zajrzeć do silnika, przeszperałem trochę po plikach, ale nie udało mi się znaleźć miejsca, które by mi jasno pokazało, jak ten nieszczęsny scope_zoom_factor jest dokładnie używany. Oczywistym utrudnieniem jest to, że moja biegłość w C++ równa jest biegłości w Highland Games, czyli przyzerowa.

A zatem - jeśli ktoś tutaj zna matematykę, może jakieś inspiracje byłaby/byłby w stanie wytworzyć? A może ktoś zna C++ i mógłby nakierować mnie na fragment kodu silnika, gdzie ta zagadka mogłaby się rozwiązać?

Merkantylizm, srerkantylizm.