Symulator EU07 (i nie tylko) > Na warsztacie
Planowane zmiany w exe
firleju:
Zrobiłem funkcję rzutującą pozycję komórki na tor. Narazie w wersji wstępnej niezoptymalizowanej wygląda to jak:
1. Weź punkt1 toru.
2. Policz odległość od eventu.
3. Policz punkt na bezierze w odległości +0.1 od poprzedniego
3. Policz odległość od eventu
4. Jeśli mniejsza wróć do punktu 3. Jeśli koniec toru przejdź na następny.
Algorytm łopatologiczny, nieoptymalny, dający odległość w rozdzielczości obecnie ok. 10m ale eventów jest na tyle mało, że nie powinien specjalnie rzutować na wydajność a na ruch też nie. W następnej wersji zwiększę rozdzielczość sprawdzania dla znalezionej pary punktów pomiędzy którymi jest event do mniej więcej 1m.
Ponadto zmieniłem deque dla wskaźników na std::list ze względu na to, że potrafię sobie wyobrazić przypisanie wskaźników w odwrotnej kolejności i w dziwnych miejscach. Obecnie przerabiam funkcję TableUpdate. Przy okazji pytanie czy nie lepiej konwertować czas przyjazdu i odjazdu w rozkładzie na czas, nie trzymać jak obecnie. Jak do tej pory po zmianie poprzednich funkcji schodzę o mniej więcej 2 do 3 "wcięć" w kodzie. Szczególnie, że teraz rozbijam sprawdzanie pozycji osobno na tabelę tylko z torami i tylko ze wskaźnikami.
Aktualizacja wpisów w tabelce teraz polega tylko na sprawdzeniu stanów, a aktualizacja dystansu jest osobno za pomocą odległości przejechanej przez pierwszy pojazd. Czyli po bożemu. Do zrobienia jest zaktulizowanie przeliczania długości toru podczas jego inicjalizacji na propozycję @HTD co powinno polepszyć przemieszczanie taboru po torach i aktualizację tabelki, aczkolwiek obecna metoda jest wystarczająco dokładna to raczej nieoptymalna.
Co do fizyki, to z podziałem TMover to jak najbardziej. Tu się troszkę nie zrozumieliśmy. Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:
--- Kod: ---pociąg -> pojazd -> wagon
-> wagon
-> pojazd -> wagon
-> pojazd -> wagon
-> pojazd -> wagon
-> pojazd -> wagon
-> pojazd -> wagon
-> pojazd -> wagon
-> pojazd -> wagon
--- Koniec kodu ---
i tak 40 razy. Czym to się różni w architekturze od obecnego:
--- Kod: ---Train -> DynamicObject
-> TCab
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
--- Koniec kodu ---
itd.
tmj:
--- Cytat: firleju w 09 Lutego 2017, 07:45:18 ---Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:
(..)
Czym to się różni w architekturze od obecnego:
(..)[/code]
itd.
--- Koniec cytatu ---
Akurat ta sytuacja nie rozni sie wiele, przynajmniej w tym ujeciu. Roznice wystepuja, gdy masz aranzacje np
--- Kod: ---Train->
dynamic, en57a
dynamic, en57s
dynamic, en57b
dynamic, en57a
dynamic, en57s
dynamic, en57b
--- Koniec kodu ---
bo taki uklad widziany jest wtedy jako
--- Kod: ---pociag->
zespol->
pojazd, en57a
pojazd, en57s
pojazd, en57b
zespol->
pojazd, en57a
pojazd, en57s
pojazd, en57b
--- Koniec kodu ---
Nie sa to byc moze sytuacje czeste, niemniej wystepuja, podobnie jak lokomotywy uokrotnione itp, wiec mysle ze warto miec taki uklad, ktory pozwala na ich obsluge bez wymuszania na pociagu babrania sie z indywidualnymi elementami, i sprawdzania czy sa one pojedyncze, czy w jakis sposob laczone.
Alternatywa byloby, teoretycznie, wyprowadzenie zespolu z pojazdu, jako taki wariant ktory wewnetrznie trzyma swoje wlasne pojazdy, ale to akurat imo wprowadza wiecej komplikacji niz usuwa, bo oznacza to ze zamiast miec w zespole jednynie obsluge ogolnych instrukcji od kontrolera i przekazywanie/tlumaczenie tego na bardziej konkretne instrukcje dla elementow, i tylko te dane ktore tego dotycza, mamy przynajmniej w zespole rowniez te funkcje i dane, ktore posiada indywidualny pojazd. To chyba niepotrzebny balagan.
Krzysiek626:
Trudno, nie znam się na programowaniu, ale z pewnych względów napiszę. Jakiś czas temu i to nie raz, wybucha dyskusja co w exe poprawić. Jednym z wielu takich propozycji bardzo lobbowanych przez ze mnie jest oświetlenie scenerii. Oświetlenie, gdzie strumień światła ze źródła oświetla obiekty bez ustawienia badziewnych tekstur i strumień ten, jest w stanie być przysłonięty przez obiekty, a więc także chodzi o cienie. Ze źródeł świateł w symulatorze wymienię słońce, latarnie, reflektory lokomotyw i samochodów, okna wagonów i lokomotyw, oraz okna budynków. Z wymienionych źródeł w tej chwili najlepiej sprawuje się oświetlenie słoneczne. W związku budową exe C++, pytam, jak wygląda w tej materii poprawa grafiki symulatora, jaka jest możliwość rozbudowy silnika o takie oświetlenie. Być może takie pytanie nie jest odpowiednie w tym wątku, ale proszę o odpowiedź. Przy czym zaznaczam, że nie mam zamiaru namawiać i dyskutować zbędnie o tej kwestii, zależy mi na odpowiedzi bez zbędnego spamu, czy takie coś jest nam potrzebne i bez zbędnego trolowania kto ma rację.
tmj:
--- Cytat: Krzysiek626 w 09 Lutego 2017, 11:51:19 ---W związku budową exe C++, pytam, jak wygląda w tej materii poprawa grafiki symulatora, jaka jest możliwość rozbudowy silnika o takie oświetlenie.
--- Koniec cytatu ---
Nie wnikajac w szczegoly i niczego tutaj nie obiecujac, przygladam sie :) Nawiasem mowiac, bardziej zdecydowane rozdzielenie czesci symulacyjnej od wizualizacji, zaproponowane na wstepie, ma miedzy innymi na celu stworzenie na dluzsza mete mozliwosci polaczenia z jakims innym silnikiem graficznym, a bardziej zaawansowanych mozliwosciach.
Na krotka mete, na ile biezacy renderer mozna przebudowac i/lub ulepszyc, okaze sie.
Stele:
Z rzeczy w tym aspekcie, które zdaje się Q jakoś zrobił, tylko ostatecznie kodu mi nie dał, było wyprowadzenie emisyjności materiału obiektu 3d. Tak by dynamic mógł sterować świeceniem swoich obiektów.
W planach miałem też próbę wyprowadzenia obiektu do nowej fazy renderowania z blendem w takim trybie, jak obecna smuga pojazdu. By bez shaderów zrobić trochę lepsze oświetlenie statyczne. Koncepcyjnie skisło na ustaleniu uzależnienia i jak by to miało się sortować z całą resztą.
Nawigacja
[#] Następna strona
Idź do wersji pełnej