Tadeusz Hajto

W multi to by się musiało wiązać z koniecznością wprowadzenia "trybu pasażera" lub manewrów, żeby nie blokować niepotrzebnie toru na stacji końcowej. W pierwszym przypadku nie dałoby się wrócić do pociągu (bo bot by przejął i tak), ale można by było pozwiedzać peron, a już całkiem bajka - wsiąść do kogoś w powrotny jako pasażer. W drugim - można by było zakończyć służbę, ale kwestia co i kiedy by się działo z takim składem już odstawionym. Jestem jednak za i mam nadzieję, że kiedyś zobaczymy obie te funkcjonalności.

Zauważyłem pewną zależność w rwaniu niektórych dźwięków, co może sugerować, że podejrzenia @FluffyAdmiral mogą być właściwe. Korzystam z 5.1 i gdy w EU07 przy ruszaniu ze stacji luzuję skład (odgrywany jest dźwięk syczącego powietrza) i jednocześnie zadaję kolejne pozycje na nastawniku - dźwięk syku zupełnie urywa się w momencie odgrywania dźwięku przestawienia nastawnika jazdy, po czym znów powraca, gdy tamten dźwięk się skończy, zamiast nałożyć się jeden na drugi. Wydaje mi się, że dźwięki nakładające się na siebie z tego samego kierunku wzajemnie się blokują, ponieważ jeden dźwięk nie blokuje wszystkich innych, a tylko niektóre, ale jest to tylko moja teoria nie potwierdzona żadnymi dokładniejszymi testami.

O ile sam kierunek można odczytać z numeru, jak wyjaśnił to @Barcikowy, przydałaby się informacja przy wybieraniu pociągu w multi, pomiędzy jakimi stacjami aktualnie znajduje się bot od którego przejmiemy skład (lub zupełne minimum, czyli następna stacja). Myślę że ta informacja + to co jest teraz, czyli numer i przewidywany czas pozostały do końca danego scenariusza byłyby w 100% wystarczające i nie trzeba byłoby korzystać z zewnętrznej mapy, żeby podjąć decyzję co chcemy wybrać.

@milek Rozumiem, że to nie jest hop-siup, możliwe że grafika ta tyczy się to konkretnego silnika np. Unreal, ale biorąc pod uwagę fakt, że użytkownicy kart Radeon i GTX to nadal spore grono, a nie mają obecnie w Simrail satysfakcjonującego rozwiązania w kwestii AA, czy to grono może oczekiwać, że prace nad implementacją tego rozwiązania zostaną podjęte? Ewentualnie, skoro rozdzielczość renderowania jest oddzielona od rozdzielczości wyświetlania, czy byłaby możliwość udostępnienia użytkownikom możliwości wyboru wyższej rozdzielczości renderowania niż rozdzielczość wyświetlania, w celu poprawy działania TAA (poprzedzone testami sprawdzającymi, czy TAA będzie wyglądać lepiej przy wyższej rozdzielczości renderowania względem wyświetlanej)? Jeśli brakuje czasu i/lub zasobów ludzkich do przetestowania takiego rozwiązania (zrozumiałe szczególnie w początkach Early Access), zgłaszam się na ochotnika, tylko potrzebuję możliwości ustawienia osobno rozdzielczości renderowania, choćby z poziomu settings.conf

@milek Czy to oznacza, że w SimRail zastosowany jest tylko starszy FSR w wersji 1.0? Z artykułów na internecie porównujących wersje DLSS i FSR wynika, że wersja 2.X (zarówno FSR jak DLSS) lepiej radzi sobie z migotaniem, ale patrząc na poniższy graf przedstawiający potencjalne nakłady pracy potrzebne do zaimplementowania FSR w wersji 2.0 wychodzi na to, że wymagane jest najpierw zaimplementowanie wsparcia dla oddzielenia rozdzielczości renderowania i wyświetlania.

@TheShotte I just tried that, and it seems like VSR is not working for me. It is enabled in AMD Control Panel: And no resolution beyond my display native is available neither in windows nor SimRail: Is there something I've missed?

Właśnie wg mnie to jest pozytywna informacja, która świadczy o tym, że temat nie jest olewany i zamiatany pod dywan, a devi starają się jakoś do niego odnieść. Zakładam, że to tylko jedna z prób, a nie ostateczny fix i już nigdy do tego nie wracamy. Tak przy okazji, właśnie sobie uświadomiłem, że w poprzednim poście właściwie opisałem, co by dało wprowadzenie MSAA do SimRail (lub High Definition Render Pipeline czy jak to jeszcze inaczej zwą w Unity). Na pewno są jeszcze inne triki, które pomogłyby "oszukać" gracza, np.: Jak zostało wcześniej już zauważone - migotanie TAA jest najbardziej uciążliwe i zauważalne przy statycznym obrazie - może więc jakiś trik, gdzie TAA jest nakładane warunkowo od tego czy obraz jest w ruchu np. czy poprzednia klatka na bazie której wyliczany jest TAA różni się od obecnej, bądź na innym poziomie - aktywowany tylko gdy zostanie wykryta zmiana współrzędnych położenia kamery względem sceny (ruch kamery), bądź obiektu do którego jest ta kamera przytwierdzona (ruch modelu gracza).

Może dodam jeszcze słowo w kwestii technicznej: Jaka jest przyczyna migotania? Migotają obiekty znajdujące się w oddali lub takie o cienkich krawędziach - można więc zakładać, że TAA ma problem z wygenerowaniem gładkiego przejścia pomiędzy kolorem cienkiego obiektu (cienkiego w pikselach wyrenderowanego obrazu - np. 1 piksel), a tłem. W związku z tym na zmianę serwuje nam kolor obiektu i kolor tła (bądź mieszankę ich obu - nie chcę się zagłębiać też za mocno w samą zasadę działania AA), bo uznaje że tak jest fair. Jednak my odbieramy to okiem jako nieprzyjemne migotanie w wysokiej częstotliwości (prawdopodobnie co 2 wyrenderowana klatka). Jak więc można temu przeciwdziałać? Można sprawić, żeby AA wyliczał gdzie i jak robić przejścia na obrazie wygenerowanym w większej rozdzielczości niż ta prezentowana na ekranie. Dzięki temu więcej obiektów w obrazie, na którym jest wyliczany AA, będzie grubszych niż 1 piksel, a to powinno sprawić, że przejścia między kolorami obiektów i tła powinny być gładsze i dokładniejsze. Jakie są tego koszty? Nic nie przychodzi za darmo - plusy są oczywiste, ale trzeba mieć na uwadze, że wiąże się to jednak nieuchronnie z większym obciążeniem GPU - mimo że mamy na ekranie obraz w jakiejś konkretnej rozdzielczości - GPU będzie renderować ten obraz w rozdzielczości wyższej, więc wymagać będzie większych zasobów i to chyba nie jest do przeskoczenia w żaden sposób. Na pewno jednak na oddaniu takiej możliwości wyboru rozdzielczości renderowania użytkownikom skorzystałyby osoby, które mają stosunkowo mocną kartę graficzną względem monitora (tzn taką zdolną pracować w rozdzielczości 1440 lub 4K), ale nie dysponują monitorem o takiej rozdzielczości. Na koniec dodam tylko, że nie jestem grafikiem. Pracuję w devie, ale nigdy nie miałem doczynienia z grafiką w żadnej formie, więc moje dywagacje są jedynie wynikiem moich obserwacji w innych grach i ogólną znajomością tematu.

Ja wolę myśleć pozytywnie i nie zakładać z góry najczarniejszego scenariusza, nawet takie tytuły jak GTA5 miało z tym tematem problemy i jednak z czasem się z nimi uporali. Gra jest we wczesnym dostępie, więc zainteresowanie i dyskusja w tym temacie jest, uważam, jak najbardziej wskazana. Jednak rozumiem, że jak każdy produkt we wczesnym dostępie - problemów do rozwiązania jest dużo i każdy uważa, że ten jeden jest najważniejszy, ale nie o to chodzi. Temat flickeringu jest też dość popularny na anglojęzycznej części forum, więc myślę, że prędzej czy później deweloperzy zaadresują też i to. Na tą chwilę, najlepsze co możemy zrobić to podrzucać nowe pomysły, inne przykłady i dzielić się wiedzą zdobytą w innych grach (co próbuję tu zrobić), a wspólnymi siłami może wpadniemy na jakiś trop i satysfakcjonujące rozwiązanie.

Nie do końca o taki test mi chodziło. U kolegi masz nadal rozdzielczość renderowania w grze taką samą jak rozdzielczość ekranu - w SimRail jest ustawione 3840x2160 i w takiej jest wyświetlane. To co ja chciałbym osiągnąć to renderowanie w wyższej rozdzielczości, niż wyświetlanie. W samym SimRail renderowanie w wyższej rozdzielczości musiałoby się odbywać przed nakładaniem maski AA, tak żeby filtr AA pracował z obrazem dokładniejszym, w wyższej rozdzielczości, niż ten jaki trafi na monitor, a dopiero obraz post-processowany byłby przeskalowany na rozdzielczość ekranu, dzięki czemu efekt AA byłby lepszy ze względu na zasadę działania AA. Do tego w SimRail potrzebne by były wtedy dwa ustawienia rozdzielczości - jedno renderowania i drugie wyświetlania. W Microsoft Flight Simulator jest takie rozwiązanie, chociaż nie jest dostępne jawnie z poziomu opcji graficznych, a tylko z plików konfiguracyjnych (i co ważne - pomaga właśnie na ten konkretny rodzaj migotania), więc zastanawiałem się czy coś takiego jest też może dostępne, ale ukryte w SimRail, czy może w ogóle nie ma takiego podziału na rozdzielczość obrazu przed filtrami i po filtrach. W dużym uproszczeniu - docelowo efekt właśnie byłby podobny do tego na yt, z tym że to wszystko, czyli wytworzenie obrazu w wyższej rozdzielczości, nałożenie na niego filtru AA i dopiero wtedy wysłanie na ekran, tym razem już w niższej (natywnej) rozdzielczości nie odbywało się na YT a w pamięci karty graficznej i komputera ogólnie.

@TheShotte Do you know how to force super resolution in SimRail? My card is RX5700 XT, screen native resolution is 1920x1080, and I would like to try SimRail to run in 1440p and then downscale to 1080 to check if I get better AA results and how much it hits the performance.

U mnie wygląda to dokładnie tak samo, jak na filmikach zamieszczonych przez @en57. Wygląda to trochę jak efekt gorącego powietrza dla elementów w oddali, ale pojawia się też dla krawędzi bliskich i jest męczące dla oczu. Specjalnie zrobiłem pełną instalację sterownika karty graficznej z całym oprogramowaniem Adrenalin (a nie jak dotychczas Driver Only) i próbowałem pobawić się tam różnymi ustawieniami, ale nie znalazłem nic, co by naprawiło to migotanie. Czy ktoś zna sposób na podbicie rozdzielczości renderowania w SimRail względem natywnej rozdzielczości ekranu (chodzi mi o wyjście ponad maksymalną rozdzielczość - w opcjach SimRail max do wyboru mam 1920x1080, czyli tyle ile mam na monitorze, a chciałbym sprawdzić czy renderowanie w 1440p i późniejsze przeskalowanie do rozdzielczości ekranu nie dałoby poprawy)?

Ja mam to migotanie i kartę RX 5700 XT. Podobne migotanie miałem też w Microsoft Flight Simulator z obiektami takimi jak słupy, barierki itp. Rozwiązaniem było pogrzebanie w pliku konfiguracyjnym i tam znalazłem takie wartości jak PrimaryScaling i SecondaryScaling, obie ustawione na wartości 1.000000. Doszedłem metodą prób, że primary scaling to stosunek rozdzielczości ustawionej w grze do rozdzielczości ekranu (u mnie 1920x1080). Ciekawa była wartość SecondaryScaling: Pu ustawieniu jej na 1.333333 w grze miałem nadal rozdzielczość 1920x1080, ale w opcjach widniała jako 2560x1440. Zakładam więc, że to jest rozdzielczość w jakiej renderuje się sama grafika, a później jest procesowana tak żeby była wyświetlana w rozdzielczości monitora (tzw. upscaling). Zastosowanie tej metody sprawiło, że cienkie obiekty przestały migać (podejrzewam, że ze względu na to, że AntiAliasing pracował z obrazem renderowanym lepszej jakości, więc miał więcej informacji jak poprawnie aproksymować wygładzanie). W pliku config SimRail nie znalazłem niestety jednak niczego podobnego. Teraz więc pytanie, czy podobny efekt upscalingu dałoby się zaimplementować w SimRail? Myślę, że mógłby rozwiązać wiele problemów z miganiem przy TAA/FSR, które teraz występują.

A jeszcze lepiej dać do wyboru w ustawieniach graficznych poziom szczegółowości pojazdów innych niż użytkownika.

Dziś przejechałem tą trasę drugi raz, sytuacja się powtórzyła, ale postanowiłem przeczekać do planowej godziny odjazdu, i semafor zmienił się na S2. Przydałaby się jednak jakaś informacja od dyżurnego po wciśnięciu ZEW, że będzie postój, bo z Włoszczowej do Idzikowic można łatwo nadrobić 10 minut względem rozkładu przestrzegając przepisów. Podsumowując: scenariusz da się ukończyć, ale tamta sytuacja, gdzie trzeba czekać 10 minut pod semaforem może zdezorientować.