Eureka! Więcej FPS?

[jaras]

Witam wszystkich..

Tak sobie ostatnio nad tym rozmyślałem, chociaż nie miałem czasu tego sprawdzić.  Po za tym ja i tak mam bardzo wolny sprzęt, więc u mnie zapewne wydajność podskoczy o 1, może 2 FPS :-).

Ale jest to propozycja dla ludzi o "mocnych" kompach.

Czytając sobie plik Scenery.doc z opisem wszelkich komend zawartych w pliku ze scenerią, na pierwszej stronie trafiłem na coś takiego (na co wcześniej nie zwróciłem uwagi):

1.1 Node

Definiuje obiekty widoczne (a ogólniej: obiekty które bierze pod uwagę funkcja Render).

Parametry podstawowe:

[*]MaxDistance - maksymalna odległość z jakiej obiekt będzie widoczny[*]MinDistance - minimalna odległość z jakiej obiekt będzie widoczny[*]Name - nazwa obiektu, jeśli nie potrzebujemy należy wpisać none[*]Type - rodzaj obiektu[/list]

Jak zauważyłem w plikach ze sceneriami, wszędzie, jako wartości parametru MaxDistance używa się -1, co oznacza nieskończoność. Wydaje się to bezsensem, aby symulator do narysowania scenerii miał obliczać również elementy z drugiego jej końca, a nawet z odległości kilku kilometrów, które i tak już nie są przecież widoczne.

Jeśli zatem w pliku scenerii (i wszystkich plikach, które są dołączane komendą include) poprawić wpisy:

Kod: [Zaznacz]

node -1 0 ...
endnodena

Kod: [Zaznacz]

node 500 0 ...
endnodegdzie liczba 500 jest widocznością wyrażoną w metrach i można by ją ustalić eksperymentalnie, to wówczas symulator miałby być może mniej do rysowania, a przez to chodziłby szybciej.

Krajobraz będzie wówczas trochę okrojony, bo widać będzie tylko te obiekty, które są w zasięgu (w powyższym przykładzie: 500 m). Zatem trzeba tu użyć kompromisu: albo dalekie, piękne widoki, albo szybsza symulacja.

Sama zmiana wpisów nie jest trudna. Można to zrobić w Notatniku:

a najlepiej w Wordzie (polecam do szczególnie dużych plików - Notatnik wówczas działa bardzo ślamazarnie):

W Wordzie trzeba zaznaczyć w okienku opcję "Użyj symboli wieloznacznych" - wtedy można użyć znaku gwiazdki ("*") dla dowolnego ciągu znaków (nie wszystkie wpisy node mają wartość MaxDistance równą -1).

Oczywiście, moje przypuszczenia, to tylko hipoteza - nie twierdzę, że cokolwiek to przyśpieszy, ale może. Z pewnością zauważalne przyśpieszenie będzie widoczne na szybszym sprzęcie.

Polecam wszystkim spróbować mojego pomysłu. Pozdrawiam Was serdecznie.

[Siano]

Pomysł dobry ale wole tego nie testować. Poczekam na decyzje innych :)

[Kolejarz]

pomysł jest ok. Ale powiedz w której części pliku scn znajduje sie ten wpis co trzeba go zmienić. zrobiłem już kopie zapasową maszyny tylko nie moge znaleźć tego wpisu co czeba go zmienić

[Mutopompka]

Więc Jareku, słuchaj. Zrobiłem zgodnie z Twoim opisem. Odpaliłem Quark-reaktywację. I oto moje spostrzeżenia:

1 - pozmnieniałem wartośći NODE -1 na NODE 500
2 - uruchomiłem symulator
3 - podczas ładowania wywalało mi, że brakuje kilkunastu eventów - to było spowodowane "nadgorliwością" zastępowania wyrażenia "node -1" na "node 500" (ponieważ robiłem to hurtowo.....) i w pliku *.SCM zastąpiło mi automatycznie około 200 wpisów.
4 - werszcie po "kilku ładnych chwilach" załadowała się trasa. I muszę przyznać, że coś w tym jest.... U mnie niewiele, bo także mam słaby komp (Athlon TB 750MHz, 384MB ram, Gf2MX 32DDR ram) więc miałem w Wielkim Kacu 5-8 klatek....  A w standardzie mam (3-5) więc przyrost jest.

Ale do rzeczy... wartość 500 jest za mała dlatego, że wszystko ładnie widać, tylko łopatologicznie: O obrębie tych 500..... ;) Pomojam fakt, że semafory było widać, słupy trakcyjne także - więc jak się można domyśleć, będzie to wina nie dokładnego "zastąpienia" wartościami z -1 na 500. Będziesz także widział skłąd w takiej odległości (czyli 500 od Cieb ie)

Podsumowując. Pomysł dobry, jednak trzebaby było zwiększyć parametr z 500 na 2000 (ponieważ nie opłaca się wzrost (u mnie bynajmniej) 3 klatek za cenę jaką widzę przy zastosowaniu wartości 500. Jeszcze dodam, że mój sprzęt to już zabytek, ale jak ktoś może to niech sprawdzi u siebie na procu o zegarku większym niż 1.4 GHz. A czy to się będzie opałcać (czy naprawdę jest wzrost liczby FPS-ów)? To już zostawiam potencjalnym "szperaczon" w ustawieniach i kodzie tras.....

[hejnal]

Od dawna się tłucze do głowy modelarzom że mają w modelach ustawić MaxDistance więc jeśli to zrobili to zmiana wpisu w scenerii nie wiele pomoże. Jednak każdy traso-pisarz powinien sprawdzić odległości dla modeli jakie wstawia do scenerji i sam ustawić sobie node x. Zakładając że ta opcja wogule działa.

[pROSiAczek]

ja tak robilem gdy pisalem w excelu (o zgorzo traske) i efekt jest kapitalny... naprawde obniza wymagania kompa wystarczy zrobic nie 500 a 2000-3000 i juz jest efekt jesli brac pod uwage cala scenerie

[Kakish]

Od dawna się tłucze do głowy modelarzom że mają w modelach ustawić MaxDistance więc jeśli to zrobili to zmiana wpisu w scenerii nie wiele pomoże

Pamietaj ze maxdistance w modelu sluzy do jego optymalizacji czyli ukrywania szczegolow, nikt nie robi maxdistance dla domow ktore maja po kilkadziesiat polysow tylko raczej dla bardziej skomplikowanych modeli ktore maja ich po kilkatysiecy, ale na calej trasie tych domow moze byc tak wiele ze rzeczywiscie obciazaja one strasznie przetwarzania.
z drugiej strony w scenerii jest mnostwo elementow z wieloma polygonami takich jak trakcja, tory, teren i maxdistance na tym z pewnoscia pomoze

[dj_awj]

Co mam zrobić z plikami w folderze scenery, np w pliku SBL3-pierwszy    Autor pliku  SBL3-pierwszy napisał

// blokada SBL 3-stawna - pierwszy semafor na szlaku (poprzedni niesamoczynny)
// (p1) - nazwa, (p2)(p3)(p4) - lokacja, (p5) rotacja, (p6) symbol (p7) sterowanie semaforem wyjazdowym (jego nazwa)
// uwaga - do toru za semaforem musi byc przypiane zdarzenie NAZWASEMAFORA_s1
// a do toru przy semaforze oczywiscie zdarzenie NAZWASEMAFORA_sem_info

origin (p2) (p3) (p4)
rotate 0 (p5) 0
//model semafora 3komorowego blokady liniowej:
node -1 0 (p1) model 0 0 0 0 PKP/head3-gry.t3d (p6) Lights 1 0 0 endmodel                  //glowica
node -1 0 none model 0 0 0 0 PKP/post-straight.t3d PKP/pkplight_sblpost.tga endmodel       //slup
node -1 0 none model 0 0 0 0 PKP/post-ladder-h34.t3d PKP/#pkplight_board.tga endmodel      //drabinka
 
node 800 150 none lines 110 110 110  100.0                                      //linia zeby byl maszt widoczny z daleka
0.0 0.0 0.0   0.0 4.0 0.0
endline
rotate 0 0 0
endorigin

node -1 0 (p1)_sem_mem memcell (p2) (p3) (p4) SetVelocity -1 -1  none endmemcell

[jaras]

Co mam zrobić z plikami w folderze scenery, np w pliku SBL3-pierwszy (...)

Witaj @ dj_awj.

Oczywiście, można tak również postąpić ze wszystkimi plikami w całym drzewie katalogów symulatora. Przecież semafory, wskaźniki, zwrotnice, sieć trakcyjna i wszelkie inne pierdoły ;-) przytorowe i "natorowe" także używają wpisów "node". Tych obiektów zwykle ich jest najwięcej, a każdy z nich składa się z wielu polygonów.

Można by zrobić nawet taki eksperyment. Przy użyciu jakiegoś (nie wiem jeszcze jakiego - mam na myśli takie coś jak odpowiednik "grep" z systemów *nixowych) programu, który potrafi w wielu plikach na raz zamieniać ciągi znaków, zamienić wszystkie wpisy:

Kod: [Zaznacz]

node -1 0 ...
endnodena

Kod: [Zaznacz]

node N 0 ...
endnodegdzie N - to wybrana odległość MaxDistance, o której dyskutujemy w tym wątku. Nie wydaje mi się, żeby groziło to jakimiś kłopotami, ale być może się mylę.

Jeszcze raz powtarzam: przecież jakiekolwiek widoczne obiekty (definiowane właśnie wpisem node) nie muszą być przez symulator renderowane z odległości klikunastu kilometrów, skoro i tak ich nie będzie widać. Czy @ pROSiAczek jednak nie przesadza ustawiając tą odległość na 2000...3000 m? Wszak przepisy WTB-E10 (Rozdział 2, §9, pkt. 2.) mówią tak:

Widoczność sygnałów (W) w metrach przy największcj dozwolonej prędkości (V) zbliżania się pociągu do sygnalizatora w km/h powinna wynosić:

1) dla semaforów wjazdowych:
a) na liniach magistralnych i pierwszorzędnych - co najmniej 400m przy prędkościach do 120 km/h i co najmniej (10*V)/3 [m] przy prędkościach większych od 120 km/h,
b) na liniach drugorzędnych - co najmniej 300m,
c) na liniach znaczenia miejscowego - co najmniej 100m.

2) dla semaforów wyjazdowych (wyjazdowych grupowych) i drogowskazowych przy torach głównych zasadniczych i głównych dodatkowych. po których odbywają się przebiegi bez zatrzymania oraz dla semaforów odstępowych obsługiwanych i samoczynnych (10*V)/4 [m], jednak nie mniej niż 200m,

3) dla semaforów wyjazdowych przy torach, po których nie odbywają się przebiegi bez zatrzymania, dla semaforów zaporowych oraz dla wszystkich semaforów na liniach znaczenia miejscowego - nie mniej niż 50m.

4) dla tarcz ostrzegawczych (10*V)/4 [m], jednak nie mniej niż 200m,

5) dla pasów świetlnych wskaźników wyświetlanych zainstalowanych na semaforach (10*V)/5 [m], jednak nie mniej niż 200m

6) dla tarczy manewrowej - nie mniej niż 50m.

7) wskazania tarczy rozrządowej powinny być widoczne wzdłuż całej drogi spychania składu, poprzez zastosowanie odpowiedniej ilości tarcz rozrządowych.

Zatem już nawet ze 1000 m powinno wystarczyć. Objęłaby bowiem ta odległość nawet największą odległość W określającą widoczność sygnałów.

Pozostaje tylko pytanie: czego nie zmieniać, by nie psuć widoku? Ano, np. wielkich gór, bardzo wysokich budowli - jednym słowem, wszelkich obiektów, które mogą być widoczne z daleka. Zwykle góry, to tylko kilka, kilkanaście polygonów (czy mam rację?), a budynki - kilkadziesiąt; mało tego, często nie ma takich obiektów (np. bardzo wysokich budowli) zbyt dużo - nie powinno więc to zmierzalnie wpłynąć na wydajność symulatora.

A co sądzą o tym inni?

Pozdrawiam Ciebie i pozostałych uczestników forum.

[Kakish]

Czolem !

E ten sposob latwo zasymulowac ostra mgle... dac widocznosc np. 50 metrow na wszystko :D