- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Symulator => Wątek zaczęty przez: Ra w 03 Listopada 2008, 01:09:06
-
Tak mi się kołacze pomysł na plik z opisem profilu pionowego trasy. Byłby to oddzielny od plików scenerii plik, ale powiązany z nimi. W zasadzie to zawierałby wszystkie te informacje, co na tym rysunku:
http://img.wklej.org/images/24086profil-przyklad.jpg (http://img.wklej.org/images/24086profil-przyklad.jpg)
plus dodatkowo informacje o torach (node track) należących do danej trasy.
Plik miałby strukturę rekordów o stałej długości. Można by wykorzystać format DBF z zapisem binarnym, a do edycji ręcznej konwertować na CSV.
Było by kilka typów rekordów:
-co 100m, określające położenie słupków hektometrowych,
-informacje o prostych, łukach i krzywych przejściowych,
-informacje o wiaduktach, mostach i przejazdach,
-informacje o torach (node track) przyklejonych,
-informacje o semaforach,
-informacje o słupach trakcji elektrycznej.
Rekordy powinny zawierać:
-typ rekordu,
-współrzędne XYZ punktu,
-współczynniki kierunkowe stycznej,
-odległość obiektu do osi lub kąt nachylenia,
-wysokości torów (dwie wystarczą?),
-głębokości rowów,
-odległości rowu od osi,
-wysokość terenu,
-kąty nachylenia skarp,
-pochylenie wzdłużne i boczne toru,
-ewentualnie eventy,
-tekstury dla torów,
-opis słowny.
W zasadzie edytorem scenerii zmieniało by się ten plik, a z niego było by generowane najbliższe otoczenie toru. Zawierałby on całą definicję toru. Po zaznaczeniu punktu początkowego można by też wygenerować taki plik z istniejącej scenerii (np. do poprawienia łuków). Dla potrzeb symulacji zawierałby on zbyt dużo danych, bo zarówno dane wizualne jak i ruchowe. Zaletą takiego pliku była by możliwość wielokontekstowej edycji. Można by go edytować zarówno w podglądzie 3D, wprowadzając dane z oryginalnej dokumentacji, jak również np. weryfikować z danymi SRTM i UMP.
Piszę o tym, żeby zapytać, co jeszcze powinno być w takim pliku, zanim zabiorę się za realizację.
-
Chciałbym dobrze zrozumieć co planujesz. Chciałbyś stworzyć binarny format pliku dla potrzeb edytora tras, zupełnie niezależnym od obecnego formatu pliku scenerii.
Jeśli tak to:
1. Tor - najlepiej by było zapisywać tylko punkty znaczące takie jak początki i końce łuków, zmiany tekstury.
2. Teren - sprawa trudniejsza, gdyż w zasadzie trzeba by zapisywać siatkę trójkątów.
3. Rowy - tak jak tory. Przy czym jeśli dane o rowach chcesz trzymać przy torach to trzeba pamiętać o spadkach podłużnych oraz zgodności ze współrzędnymi terenu. Czyli sprawa się komplikuje. ja bym optował jednak za pozostaniem przy osobnym typie z automatycznym generowaniem podczas tworzenia toru w edytorze, tak aby można było indywidualnie dopasować.
4. Pochylenie wzdłużne powinno móc się wyliczać z danych współrzędnych podanych w pkt 1. Chyba, że chcesz liniowo dokładać wysokość do poprzedników. Wtedy potrzebujesz pola id i zapisywania id sąsiadów. Pochylenie poprzeczne do podawania na końcach toru tak jak obecnie. Chyba, że masz jakiś inny pomysł.
5. Dla eventów przydałby się własny format z konwersją na format maszyny.
Jesli myślimy o zrobieniu uniwersalnego edytora, z którego możnaby w przyszłości eksportować dane do nowszych wersji maszyny ze zmienionym opisem scenerii taka opcja byłaby przydatna. Edytor eventów jako schemat blokowy z zaznaczaniem elementów na schemacie GIS. Opcja do rozważenia.
-
Szerokość rowu, tudzież innego poprzecznego/podłużnego zagłębienia terenu, co pozwoli przyszłościowo generować skarpy ziemne w okolicach cieków wodnych.
-
Pisałem przedtem o formacie binarnym na potrzeby symulacji. Oddzielną rzeczą jest sceneria zapisana ze współrzędnymi krzywoliniowymi na potrzeby edytora przekrojów i zależności - jest to jakby format redundantny, bo zawierać będzie zarówno współrzędne XYZ do łatwiejszego wyszukiwania, jak i THV (długość od początku i odchylenia prostopadłe do chwilowej stycznej) dla łatwiejszego znajdywania zależności pomiędzy obiektami przy torze.
Obecny format zapisu scenerii bardzo komplikuje edycję, ponieważ wszystko można umieścić w dowolnym miejscu, co w 99.99% przypadków nie ma sensu. Przywiązanie wszystkiego do linii toru ogranicza dowolność i ułatwia ogarnięcie zależności.
Polecam uruchomienie edytora scenerii do LokSim 3D i przeanalizowanie, w jak prosty i logiczny sposób jest tam zapisana sceneria. Gdyby był edytor do MaSzyny funkcjonujący w taki sposób, mielibyśmy do tej pory masę tras. Edycja z kartezjańskiego punktu widzenia 3ds Max jest pomyłką dla obiektów liniowych, jak tory, czy drogi. Jeśli robisz trasę fikcyjną i to od zera, to jeszcze idzie to jakoś poskładać.
Piszę to na podstawie mojej praktyki. Usiłuję doprowadzić do stanu sensownego tory PMPPW i o ile edycja 2D na tle ortofotomap Geoportalu jest rozwiązaniem prawie dobrym (zaburza się ciągłość, prostoliniowość i równoległość torów), to ustawianie profili pionowych zgodnie z planami jest po prostu nierealne przy takim podejściu.
Eventy w postaci takiej jak obecnie uważam za przeżytek... Może poza automatycznym zapalaniem S1 po przejechaniu za semafor... Ale to automatycznie, a nie tak jak teraz, że trzeba to tam wdusić.
-
Czyli rozumiem, że chcesz zbudować niezależny edytor tras dla maszyny z plikiem przechowującym o wiele większą ilość danych niż jest potrzebna dla symulatora tylko i wyłącznie dla wygody edycji.
Jak rozumiem przywiązanie obiektów do linii toru ma zadanie przesuwać otoczenie toru wraz z jego przesunięciem. W tym przypadku wszystkie obiekty powinny dostosowywać się do wysokości narzuconego z góry terenu, ewentualnie na wysokości toru jeśli otoczenia jeszcze nie ma. Myślę, że takie podejście rozwiązałoby problemy z rowami, semaforami itd. (oczywiście musiałyby być z góry określone wyjątki (semafory, rowy w wykopach). Może automatycznie rysowany nasyp o zadanych parametrach rysowania zbocza.
Biorąc pod uwagę powyższe do odpowiedniech opcji dodałbym:
- szerokość skarpy / nasypu
- nierównomierność generacji (nasypy nigdy nie są idelanie równe, skarpy tym bardziej)
- szerokość rowu odwodnienia
- określenie czy słup jest prawy lewy czy bramka, ewentualnie inne opcje (takie określenie mogłoby ułatwić ręczne rysowanie trakcji, która mogłaby się automatycznie zygzakować podczas rysowania)
- wysokość zawieszenia trakcji (opcja?)
- dla eventów zastosowałbym własny język opisu, aby było łatwiej generować jeśli język używany przez symulator się zmieni (SPT?) przy czym wstawienie semafora do scenerii powinno generować automatycznie przy eksporcie zdarzenia dotyczące S1, obsługi SBL, SHP (to w odległości 200m w kierunku tarczy semafora).
- skierowanie semafora (w stosunku do osi toru, ewentualnie odchyłka)
- teren (?)
Co ma oznaczać wysokości torów?
-
przy czym wstawienie semafora do scenerii powinno generować automatycznie przy eksporcie zdarzenia dotyczące S1, obsługi SBL, SHP (to w odległości 200m w kierunku tarczy semafora).
Hola, hola... SHP nie jest przy każdym semaforze. Powiem więcej - brak SHP przed semaforem to nie jest rzadki widok. Także automatyczne generowanie elektromagnesu mija się z celem.
-
Tak mniej więcej. Forma edytora będzie podobna do tej tabelki w pierwszym poście, dodatkowo będzie można ustawić tory równoległe (np. od 23456.789m zaczyna się zwrotnica prawa i prowadzi do równoległego toru, oddalonego o 4.8m, tor ten kończy się zwrotnicą na 23765.432m).
Poniżej będzie układ torowy zrzutowany na linię toru, w oddzielnym okienku to samo, narysowane krzywoliniowo na tle zdjęć lotniczych. Będzie jeszcze okienko przekroju poprzecznego, na którym ustawi się kąt pochylenia skarp i szerokość podtorza.
Głowna idea jest taka, że tworząc komórkę scenerii realistycznej może nie być pełnych danych o profilu pionowym - może o być utworzony prowizorycznie. Ktoś potem może dotrzeć do odpowiednich materiałów i podnieść realizm profilu kilkoma ruchami myszy, a wszystkie podłączone obiekty (sieć trakcyjna, słupki, drzewa na skarpach, mosty) się odpowiednio dostosują.
-
przy czym wstawienie semafora do scenerii powinno generować automatycznie przy eksporcie zdarzenia dotyczące S1, obsługi SBL, SHP (to w odległości 200m w kierunku tarczy semafora).
Hola, hola... SHP nie jest przy każdym semaforze. Powiem więcej - brak SHP przed semaforem to nie jest rzadki widok. Także automatyczne generowanie elektromagnesu mija się z celem.
Myślę, że to nie problem, można przecież zrobić w opcjach semafora pole typu boolean, czy wstawić takie a takie eventy przy generacji trasy.
Ra: czy myślałeś o tworzeniu terenu, czy tylko o układaniu toru. I czy tor będzie się kłaść także w profilu poziomym (na schemacie)? Co prawda profil pionowy ma zapisane także dane o przebiegu w poziomie, ale o zwrotnicach to już nie za bardzo.
-
Najpierw się będzie wczytywać ogólny przebieg toru z danych UMP, albo zaznaczając punkty na trasie. Następnie taką łamaną będzie się układać precyzyjniej, na tle ortofotomapy, zamieniając niektóre odcinki proste na łuki. Po ułożeniu całej długości szlaku w planie, będzie się generować z tego obiekt ciągły. W przypadku szlaku wielotorowego, powinno to być ułożone po jednym z torów.
Edycja w długości będzie umożliwiała wstawianie torów równoległych, zwrotnic oraz torów przejściowych (pomiędzy zwrotnicami oraz równoległymi oraz pomiędzy równoległymi oddalonymi o różną odległość). Również torów prostych, odchodzących pod pewnym kątem.
W przekroju można edytować całe podtorze i najbliższe otoczenie. Również wstawiać "ściany lasu" i budynki.
Dalszy teren da się wygenerować z SRTM.
-
Najpierw się będzie wczytywać ogólny przebieg toru z danych UMP, albo zaznaczając punkty na trasie. Następnie taką łamaną będzie się układać precyzyjniej, na tle ortofotomapy, zamieniając niektóre odcinki proste na łuki. Po ułożeniu całej długości szlaku w planie, będzie się generować z tego obiekt ciągły.
A co z trasami fikcyjnymi?
W przypadku szlaku wielotorowego, powinno to być ułożone po jednym z torów.
Nie za bardzo rozumiem. Każdy tor oddzielnie, czy zaznaczasz w opcjach, że ten tor ma równoległy np. po lewej.
Edycja w długości będzie umożliwiała wstawianie torów równoległych, zwrotnic oraz torów przejściowych (pomiędzy zwrotnicami oraz równoległymi oraz pomiędzy równoległymi oddalonymi o różną odległość). Również torów prostych, odchodzących pod pewnym kątem.
Hmmm... Może opcja wstawiania toru przejściowego na jednym z opcją automatycznej generacji na powiązanym równoległym? Ewentualnie na najbliższym w kierunku?
W przekroju można edytować całe podtorze i najbliższe otoczenie. Również wstawiać "ściany lasu" i budynki.
Przekrój domyślnie powinno się ustalać w każdym punkcie znaczącym, oraz w dowolnym punkcie wybranym przez usera. Szerokość przekroju do 50 [m] od skrajnych torów. Chyba tyle wystarczy.
Dalszy teren da się wygenerować z SRTM.
A co z fikcyjnymi?
-
A co z fikcyjnymi?
Nastawiamy się pod przyszłościowe SPT, czyli globalna sceneria - Polska, podzielona na komórki.
-
Nie można nastawiać się na stworzenie edytora dla tylko i wyłącznie realnych tras. To w pewnej mierze błędny tok myślenia.
A to, że powstały takie trasy jak Epkowo, Moczniki itd nie wynika z tego, że takie tworzy się fikcyjne trasy. One byłyby zupełnie inne, gdyby narzędzia do ich tworzenia byłyby zupełnie inne. Prawda jest taka, że aby w 3ds'ie zrobić porządną trasę, trzeba włożyć w nią lata pracy. Dlaczego? Bo 3ds to nie narzędzie do tworzenia tras dla symka. Nie został do tego celu wymyślony i nigdy nie będzie spełniał podstawowych funkcji, które w normalnym edytorze wyłącznie do symulatora będą podstawowymi narzędziami. O to się rozchodzi.
-
Nie można nastawiać się na stworzenie edytora dla tylko i wyłącznie realnych tras. To w pewnej mierze błędny tok myślenia.
Wolisz jeździć za X lat po Epkowie w SPT czy jechać na P65200?
-
Zastanów się czemu część tekstu jest pogrubioną czcionką... Mówię NIE dla edytora, który będzie tylko i wyłącznie dla tras realistycznych. Być może źle interpretujesz to, co napisałem. Nie neguję koncepcji edytora mającego możliwość tworzenia tras realistycznych. Neguję koncepcję edytora, który będzie mieć tylko taką możliwość.
-
Żeby zrobić dobrą fikcyjną sieć kolejową, potrzebna jest wiedza z zakresu geografii (z naciskiem na formy erozji terenu), geodezji, inżynierii lądowej i budownictwa nie tylko kolejowego (bo przecież budynki i osiedla też są potrzebne, a nawet porty). Przydatna będzie kilkunastoletnia praktyka w biurach projektowych. Jednocześnie trzeba być wystarczająco bogatym, żeby utrzymać zespół ludzi, którzy zaprojektują i wykonają scenerię obejmującą przynajmniej paręnaście tysięcy kilometrów kwadratowych, żeby kilka osób miało po czym jeździć.
Ja robię edytor, który ma pomóc ustawić profile i wygenerować teren na scenerii PMPPW. Chcę móc wykorzystać w prosty sposób wszelkie dostępne dane (zdjęcia, UMP, SRTM, mapy górnicze, dokumentację techniczną szlaków). Nie podejmuję się tworzenia tak wielkiego dzieła, jak edytor alternatywnej rzeczywistości, który miałby umożliwić tworzenie sieci kolejowej absolutnie z niczego.
Najpierw będzie się wyznaczać główną linię torowiska. Wzdłuż jednego z torów będzie prościej, niż symetrycznie pomiędzy torami. Potem dokłada się drugi tor, podając współrzędną wzdłużną i odległość od głównej linii (dodatnią albo ujemną). Ewentualnie wtedy można będzie przesunąć główną linię na środek.
Przez tor przejściowy rozumiem taką sytuację, gdy tor równoległy jest oddalony o 5m, a w pewnym miejscu staje się oddalony o 6m. Musi być na nim wygenerowana "eska" o odpowiedniej długości.
-
Nie, wcale nie trzeba być wielce inteligentnym inżynierem, który pozjadał rozumy innych ludzi - specjalistów w zakresie geografii (z naciskiem na formy erozji terenu), geodezji, inżynierii lądowej i budownictwa nie tylko kolejowego, aby zrobić naprawdę fajną trasę, która nie będzie pustym polem, ani też nie będzie kosmosem. Fikcja ma to do siebie, że nie trzeba trzymać się po nitce w/w wiedzy. Ale też trasa fikcyjna nie ma być znanym większości torem z trakcją i polem dookoła. Każdy użytkownik mógłby tworzyć teren wg własnych obserwacji z realnego świata nie wiedząc czemu tak jest i nie przejmując się tym. (to odnośnie terenu)
Ja myślę, że znalazłyby się osoby, które zrobiłyby fajne trasy. Znalazłyby się też tacy, którzy to nie mają wyobraźni lub mają ją aż za dużą, co widać by było w ich 'trasach'... Jednakże tutaj wszelkie wydziwienia znacznie odbiegające od realnego świata, byłyby wyłapywane przez betatesterów i w takiej formie niedopuszczane do downloadu, a nawet do działów ogólnych forum. Po prostu. Coś, co miałoby się na forum pojawić, musi naprawdę na to zasługiwać. Nigdy odwrotnie.
Również elementy związane z SRK powinny być przez betatesterów wyłapywane. Jeśli ktoś nie zna się na tym, co jest nieodzowną częścią kolejowych tras, nie powinien się za to zabierać ;]
Jeśli sądzisz, że wszystkie trasy, które już powstały lub nadal powstają 'z głowy' są beznadziejne, to się mylisz. Jednak zgodzę się, że zdecydowana większość jest 'dziwna'.
Reasumując:
Edytor tych fikcyjnych tras miałby znacznie ułatwić ich tworzenie i o wiele skrócić czas ich tworzenia.
Takie jest moje zdanie. I myślę, że nie jestem odosobnionym przypadkiem ;] Jeśli nie chcesz robić też edytora dla fikcyjnych tras, nie zmuszam Cię do tego.
-
Edytor tras realistycznych powinien umożliwiać wykorzystanie wszelkich dostępnych materiałów w celu ich budowy. W przypadku tras fikcyjnych takie materiały nie istnieją, więc edytor musi mieć zupełnie inną koncepcję.
-
Widze, że wywołałem małą burzę.
Patrząc na to co pisze Ra i Ziomal powiem tak: w tym wątku nie chodzi o to co będzie konkretnie robił edytor Ra, ale o to by stworzyć format pliku dla edytora, który umożliwi stworzenie takowego na bazie już istniejącego lub nie, ale bez potrzeby konwersji danych między oboma edytorami. Narzędzia do konwersji na plik scenerii też mogą być wspólne (np plik dll).
Lecz żeby tak było trzeba wypracować jakąś bazę.
-
Ja staję murem za koncepcją @Ra. Dlaczego trzymam się tylko edytora tras realistycznych? - Bo wiem co potrafi soft Ra już teraz. Ilu z Was położy w ciągu 15 minut 1000km trasy z dokładnością do 30cm? Nie ma takich osób. To co powiedział Ra jest słuszne. @Ziomal nie wiem czemu chcesz przerabiać coś nastawionego na stworzenie tras realistycznych na edytor scenerii nierealistycznych?
-
@pol102: Może niektórzy mają wyobraźnię i chcą tworzyć scenerie fikcyjne ;]. Można zrobić dwa osobne edytory, albo jeden tylko przy starcie i wyborze 'nowa sceneria' wybierałoby się fikcyjną albo realną. Przy wyborze fikcyjnej generowanie terenu z danych z SRTM itp. byłoby niedostępne a przy realnej byłoby dostępne. ;]
Pzdr
-
Tu nie chodzi o to, że coś będzie niedostępne. Tylko dla fikcyjnej nie ma SRTM, nie ma UMP, nie ma profili pionowych tras, nie ma zdjęć lotniczych, nie ma filmów z przejazdu trasą, nie ma zdjęć okolicy. To z czego taką trasę budować? Potrzebne są jakieś zestawy gotowych elementów, katalogi budowli, generatory wirtualnego terenu, wyglądającego jak realny itd. Ja się nie podejmuję tworzenia takich narzędzi, bo nie mam koncepcji na to.
-
[OT]
To nie o to chodzi, aby dwa edytory nastawiać antagonistycznie. Jasne, że na pytanie czy chcesz być: bogaty, inteligentny, przystojny i długo żyć, każdy raczej odpowie, iż wszystko na raz. Tylko, że w życiu raczej tego wszystkiego się nie ma na raz i trzeba zakładać jakieś priorytety.
Teraz jest tak: Ra robi swój edytor real, a ktoś inny edytor fikcji.
Teraz pytanie, skoro było parcie swego czasu na trasy real, szczególnie w kontekście skoku jakościowego jakim ma być SPT, czy nie lepiej zamiast "każdy sobie", zebrać do kupy paru zdolniachów i aby wspólnie pracowali nad czymś, co jest priorytetowe.
Jasne, iż każdy może mieć inne te priorytety. Dla mnie priorytetem byłoby stworzenie realnej kolejowej mapy Polski, w max. stopniu dopracowanej. To byłoby chyba coś niespotykanego.
Jak mi się wydaje, zrobienie edytora tras realnych i danie nam mapy kolejwej Polski, to dla jednego człowieka dużo za dużo (choć może się mylę).
Teraz paru maniaków maszynowych jeździ po fikcyjnych trasach, a wyobraża sobie, iż jeżdżą po realnych trasach. Swego czasu, pomimo, iż stary koń jestem, Linię546 huntera, przerobiłem sobie tekstury nazw stacji i zapowiedzi tak, aby pasowały do reala, z jakim łączą mnie jakieś sentymenty.
Gdy już bedzie gotowy i zadawalający edytor tras realnych, można ponownie zebrać siły i robić coś do fikcji (zresztą w pewnym momencie pewne funkcje realnego i fikcyjnego edytora będą się nakładały i w miarę rozbudwy realnego edytora, coraz więcej rzeczy uzyskamy niejako za darmo do fikcji- to taka moja wizja :)).
[/OT]
-
Dowiaduję się z tego wątku jak ma wyglądać SPT- bardzo ciekawe...
Jestem zdecydowanie przeciwny wiązaniu symulatora tylko ze sceneriami realistycznymi - tworzymy dowolne scenerie, realistyczne to tylko podzbiór - nalezy tylko udostępnić tooling który umożliwi korzystanie z istniejących danych - pisaliśmy to już w Devs z @Adammo i @robalem, powtórzę to i tutaj. Proponuję żebyście się skupili na zbieraniu koncepcji odnośnie tworzenia scenerii realistycznych, ale nie forsowali swojego podejścia - scenerie fikcyjne były, są i będą.
-
Dowiaduję się z tego wątku jak ma wyglądać SPT- bardzo ciekawe...
Taka się wywiązała dyskusja, czy coś w tym złego?
Ponadto nie jak ma wyglądać SPT, tylko po czym w pierwszej kolejności w SPT będziemy jeździli.
ale nie forsowali swojego podejścia - scenerie fikcyjne były, są i będą.
Niczego nikt nie forsuje, tylko wyraża opinię, która i tak nie jest wiążąca, bo każdy robi tak jak jemu się widzi.
Były- owszem, są - owszem, ale czy mają być, to już indywidualne podejście.
Może koncepcja słuszna, iż jednen robi real, a drugi w tym samym czasie fikcje. Dla mnie słuszniejsza byłaby: robimy coś jednego wspólnie, jak skończymy bierzemy się za coś następnego. I tylko tutaj sie różnię.
Która z tych koncepcji jest tak naprawdę bardziej słuszna, tego nie wiem.
Zresztą, kto ma umiejętności ten ma władzę...
-
Tu nie chodzi o to, że coś będzie niedostępne. Tylko dla fikcyjnej nie ma SRTM, nie ma UMP, nie ma profili pionowych tras, nie ma zdjęć lotniczych, nie ma filmów z przejazdu trasą, nie ma zdjęć okolicy. To z czego taką trasę budować? Potrzebne są jakieś zestawy gotowych elementów, katalogi budowli, generatory wirtualnego terenu, wyglądającego jak realny itd. Ja się nie podejmuję tworzenia takich narzędzi, bo nie mam koncepcji na to.
@Ra, problemy które wymieniłeś są problemami dla budowanai tras realistycznych. Dla tras fikcyjnych nie, gdyż np. sposób stworzenia terenu jest tylko ograniczony wyobraźnią twórcy. Może sobie zrobić nawet ścianę o wysokości 500 [m] i nikt mu tego nie zabroni. Generator jest tylko pewnym dodatkiem, a nie najważniejszą sprawą. Tak samo z modelami. Przecież do scenerii realistycznej też musissz jakoś obiekty wstawiać. Czyli musisz mieć modele w jakiejś formie. Jak dla mnie wystarczy pokonwertować obecnie istniejące obikety i potem móc wybierać sobie z katalogów. Może format *.ive?
Zgadzam się z Shaxem, iż wiele narzędzi, które stworzysz na potrzeby robienia scenerii realistycznych będzie miało zastosowanie przy sceneriach fikcyjnych. Będzie trzeba jeszcze zrobić tylko tych parę brakujących.
-
Tak, zawsze można sobie zrobić nowszą, lepszą, bardziej dopracowaną odmianę Bizonowa i zachwycać sie jazdą po niej. Ewentualnie ułożyć tory na Księżycu, pomiędzy kraterami.
-
Przesadzasz...
-
Tak, zawsze można sobie zrobić nowszą, lepszą, bardziej dopracowaną odmianę Bizonowa i zachwycać sie jazdą po niej. Ewentualnie ułożyć tory na Księżycu, pomiędzy kraterami.
Jesli uważasz Bałtyk za nowszą, lepszą, bardziej dopracowaną wersję Bizonowa to ja jestem za...
Jak sam zauważyłeś na początku tego wątku zrobienie dobrego terenu jest trudne ze względu na niskie przystosowanie narzędzi do tego rodzaju zadań. Jeśli ułatwimy twórcom kreację czyniąc ją prostą to będzie więcej tras jak bałtyk a mniej jak Bizonowo.
-
Ra pisząc poprzedniego posta miał chyba na myśli, te twoje słowa:
Może sobie zrobić nawet ścianę o wysokości 500 [m] i nikt mu tego nie zabroni.
Jeśli ułatwimy twórcom kreację czyniąc ją prostą to będzie więcej tras jak bałtyk a mniej jak Bizonowo.
Tylko nadal pozostaje pytanie po co?
To ma być/jest symulator czego?
Tylko fizyki, czy też może coś bardziej ambitnego, czyli i fizyki i terenu, tym bardziej, iż powstają narzędzia, aby teren był realny.
W symulatorach, gdzie szkolą się piloci, czy też kapitanowie statków (tych co po wodzie pływają), raczej nie ma miejsca na teren fikcyjny.
Oczywiście, Maszyna i ewentualnie SPT to zabawki, więc ciężko to porównywać.
Ja nie przekonam nie przekonanych, ani prawdopodobnie Ty nie przekonasz mnie ani Ra.
-
Ja nie przekonam nie przekonanych, ani prawdopodobnie Ty nie przekonasz mnie ani Ra.
No właśnie przypomina to trochę dyskusję o wyższości masła nad margaryną.
IMHO chodzi o to, żeby scenerie były na odpowiednio wysokim poziomie, nie 30km prostego toru z Vmax=120km/h. I nie jest ważne czy fikcyjna czy realna. Ma wyglądać na realną i nie być nudna.
EOT :)
-
Ma wyglądać na realną
Nie, no jak ma wyglądać na realną, to nie mam pytań, a w zasadzie miałbym (po co? :) ), ale skoro EOT.
Chyba też z mojej strony EOT :)
-
po co? :)
Po co? Ano dlatego, że nie samym realem człowiek żyje. Trasy fikcyjne z otoczeniem do złudzenia przypominające normalny świat i własnym pomysłem na torowisko itd. (oczywiście ma to swoje granice) również zasługują na uwagę.
Mariusz, powiedziałbyś teraz, że gdybym miał Polskę w symku, nie odpalałbym w ogóle fikcyjnej trasy. Mylisz się. Moje upodobanie i reakcja jest odmienna w tej sprawie ;] No ale nie o tym.
Ja myślę, że każdy swoje racje przedstawił i dalsza polemika jest zbędna, bo nic się już nie udowodni i nie zmieni. Także z mojej strony również EOT ;]
-
Ale cholipa korci mnie, aby coś jeszcze napisać :)
Tak, do tej pory jakieś fikcyjne trasy jeśli nam sie podobały, to właśnie ze względu na podobieństwa do realnych tras. Im bardziej coś było zbliżone do realu, tym ogólnie w naszych oczach było lepsze, a im bardziej odbiegało od realiów, tym gorsze. Teraz Ra dąży do ideału, czyli max. urealnić to, ale nagle coś tam Wam się odwiduje :)
Wspomniany Bałtyk- kontynuacja klimatu Całkowa, a właśnie pomimo, iż Całkowo fikcyjne jest, to co nas przyciąga?
Właśnie te klimaty mazurskie i podobieństwa do realu.
A, że nie samym realem człowiek żyje, no cóż, wtedy trzeba by nazwać symulator jakoś półsymulator, czy jakoś tak.
No, ale każdy ma prawo do własnego poglądu.
-
Ja też coś dodam ;]
Różnica jest taka, że to nie symulator linii kolejowych w Polsce. To symulator prowadzenia pociągów... Czyli jak gdyby sceneria przechodzi na drugi plan, ale... No właśnie. Staramy się, aby była normalna. Przy czym torowisko nie musi odpowiadać jakiejś części lub w całości jakiemuś odcinkowi w realu.
-
Tak prowadzenia realnych pociągów po nierealnych trasach, ale skoro są takie Wasze marzenia...
Czyli jak gdyby sceneria przechodzi na drugi plan
NIe wiem, wydaje mi się, iż sceneria jest tak samo ważna, jak wszystko pozostałe.
Zresztą Wy fikcyjnacy macie rację, Shax podjął decyzję i tak będzie jak chcecie :)
Ja jak zwykle w opozycji :)
-
ale skoro są takie Wasze marzenia...
I znów mam wrażenie, jak gdyby pominięto moją wypowiedź, że ja chcę aby realna Polska była...
-
OT. Możecie numerować swoje EOT ? Np. EOT 13 :D
-
41 TOE ,): ein ,tsej kaj zseiw roziweR
-
Chyba niezbyt jasno sie wysłowiłem. Chodziło mi po to, żeby scenerią fikcyjną nie nazywać czegoś takiego jak kpp (taka sceneria z downloadu na stronie głównej). Nic tam praktycznie nie ma. Ale np. takie Całkowo - genialna sceneria choć realna chyba nie jest, nie? Drawinowo - to samo. Podobają się, bo takie coś mogłoby istnieć na serio.
-
Podobają się, bo takie coś mogłoby istnieć na serio.
Całkowo ze swoimi łukami to raczej niezbyt, ale reszta jest strasznie klimatyczna :]
-
Tak wracając do tematu zapisu scenerii na potrzeby edytora, zrobiłem wczoraj analizę.
Podstawowym pojęciem struktury jest ścieżka (ang. path). Matematycznie jest ona łamaną otwartą w przestrzeni kartezjańskiej 3D (a właściwie w planie 2D), składającą się z połączonych, niewspółliniowych odcinków o dowolnej długości, nie przecinających się wzajemnie. W skrajnym przypadku łamana może być zamknięta. Każdy odcinek ma swój unikalny numer. Odcinki w łamanej dzielą się na odcinki właściwe (zwykle o numerach wielokrotności 10) oraz odcinki styczne do łuku (maksymalnie 9 pomiędzy odcinkami właściwymi). W skrajnym przypadku (rondo) ścieżka może nie mieć odcinków właściwych, tylko same styczne. Każda ścieżka ma swój indywidualny identyfikator. Ścieżka w uproszczeniu jest torem ruchu pojazdów. Ścieżki dzielą się na bazowe i wtórne (wyjaśnienie dalej).
Każdy obiekt na scenerii powinien przypisany do jednej ze ścieżek. Nieprzypisanie do ścieżki dopuszczalne jest dla obiektów ozdobnych, których położenie i wielkość nie są w żaden sposób związane z żadną ścieżką (np. drzewa, budynki w oddali).
Odcinki ścieżek oraz pozostałe obiekty są zapisane w postaci rekordów o stałej długości. Rekordy mogą posiadać wskaźniki na inne rekordy, które są z nimi w interakcji (np. przecinają się).
Odcinek może być zdefiniowany jako wolny albo wtórny (tylko dla ścieżki wtórnej). Odcinek wtórny jest równoległy albo umieszczony pod określonym kątem do jakiegoś odcinka ścieżki bazowej. Przy zmianie położenia odcinka bazowego, wszystkie wtórne zostają przemieszczone.
Na styku dwóch odcinków można zdefiniować łuk okręgu o zadanym promieniu, albo równoległy do odpowiedniego łuku ścieżki bazowej. Opcją łuku może być łuk z krzywymi przejściowymi. Łuk ma końce położone na odcinkach właściwych (i styczne do nich), albo jest styczny do odcinka stycznego w dowolnym miejscu.
Ścieżka wraz z jednoznacznie określonymi łukami i krzywymi przejściowymi posiada miarę wzdłużną, względem której mogą być orientowane obiekty.
Ścieżka z niejednoznacznymi łukami może być podzielona na przedziały prawidłowej i niepewnej długości, a obiekty mogą być orientowane albo wg prawidłowej długości (np. słupy sieci trakcyjnej, widoczne na zdjęciach lotniczych), albo wg niepewnej długości (np. słupki kilometrażu).
W profilu ścieżki można zdefiniować jej pochylenie (kąt wzdłużny) oraz przechyłkę (kąt poprzeczny). Istnieje także możliwość zdefiniowania łuku (promienia) w długości (profilu pionowym).
Do ścieżki można przyklejać tory, które są ułożone zgodnie w planie z odcinkami (proste) albo z łukami pomiędzy odcinkami - natomiast w profilu są zgodne z danymi o profilu.
Początek i koniec ścieżki mogą być określone jako:
- odgałęzienie ścieżki nadrzędnej (zwrotnica odchodząca na bok),
- kozioł oporowy,
- zapętlenie z własnym przeciwnym końcem.
W przypadku ulic stosuje się po jednej ścieżce na każdy pas ruchu oraz osobno chodniki. Posiadają one informację, na którą ścieżkę można się przemieścić w przypadku odchylenia kierunku ścieżki (linia ciągła na drodze stanowi ograniczenie, a nie zakaz przemieszczania się).
Poszczególne informacje będą zapisywane binarnie w rekordach o stałej długości. Dzięki temu będzie można usunąć dowolny element bez konieczności przesuwania pozostałych danych, a zwolnione miejsce użyć później na coś innego. Umożliwia również dodawanie nowych pól z zachowaniem zgodności wstecz (starszą wersją edytora da się edytować dane z dołożonymi polami). Użycie struktur o zmiennej długości wiązało by się z koniecznością innej alokacji pamięci, a przez to co najmniej spowolniło wczytywanie i zapis danych.
Problemy:
1. Zdefiniować początek rekordu.
2. Oszacować długość rekordu.
3. Zdecydować, czy wskaźniki mają być indeksami, czy adresami rekordów.
Zalety indeksów względem adresów:
- nie potrzeba przeliczać po wczytaniu,
- rekordy nie wymagają przeliczenia przed ich zapisaniem,
Zalety adresów względem indeksów:
- nie wymagają dodatkowych obliczeń (mnożenia przez długość rekordu i dodawania początku tablicy),
- struktura nie musi być statyczna - można dodawać i usuwać rekordy,
- nie musi być znany z góry rozmiar struktury,
- można przesortować tablicę w dowolnym momencie.
Można zrobić strukturę mieszaną, tzn. zadeklarować odpowiednio większą tablicę i w niej umieścić adresy rekordów. Można wręcz zrobić obiekt, który będzie dynamicznie zakładał tablice adresów w postaci listy (np. tablica zawiera 1000 adresów i wskaźnik na następną tablicę dla kolejnego 1000 adresów). Tablice mogą być o zmiennej długości, np. pierwsza tablica jest wielkości wczytanego pliku, następne są dodawane na 50 pozycji.
Podsumowując, adresy będą działały szybciej i są wskazane dla finalnego formatu, natomiast w edytorze wygodniej będzie się posługiwać indeksami. W przypadku używania rekordów poza edytorem, można indeksy na stałe przeliczyć na adresy, gdyż nie będzie potrzeby modyfikowania struktury rekordów. Finalny format można również spakować, usuwając niepotrzebne fragmenty rekordów - przeliczone adresy będą nadal wskazywać poprawnie.
Struktura scenerii:
- po jednym rekordzie nagłówkowym na każdą ścieżkę
- po jednym rekordzie na każdy odcinek łamanej
- po jednym rekordzie na każdy łuk między odcinkami
- trzy rekordy w przypadku łuku z krzywymi przejściowymi
- po trzy rekordy na każde odchylenie od poziomu (w profilu)
- po jednym rekordzie na każdy odcinek sieci trakcyjnej
- po jednym rekordzie na każdy słup
- po jednym rekordzie na słupek/-ki co 100m (zawiera również profil terenu)
- po jednym rekordzie na każde skrzyżowanie ścieżek (również łączenie)
- jeden rekord na każdą zmiany terenowe częstsze niż 100m
Dla zapisania toru (w sensie MaSzyny), potrzebujemy:
- 4B - numer ścieżki
- 48B - 4×3×4B punkty końcowe i charakterystyczne, XYZ
- 4B - tekstura szyn
- 4B - tekstura podsypki
- 1B - rodzaj toru (kolej, droga, woda, chodnik)
- nazwa lub identyfikator (ewentualnie komentarz)
- 4B - długość toru w [0.1mm]
- 8B - szerokość toru (rozstaw szyn, szerokość pasa jezdni, rzeki)
- na końcu i na początku - zwężenie jezdni/pasa/rzeki
- 1B - współczynnik tarcia
- 4B - odległość dźwięku stukotu (łączenie szyn, studzienki)
- 1B - jakość toru (właściwości, np. brak szyn, urwanie amortyzatora)
- 1B - uszkodzenia od toru (prawdopodobieństwo wykolejenia)
- 1B - otoczenie (dla dźwięku)
- 2B - długość tej tekstury (powtarzanie)
- 2B - wysokość podsypki
- 2B - szerokość podsypki
- 2B - szerokość pochylenia
- 4B - przechyłka początku i przechyłka końca
- 2B - najmniejszy promień (int)
- 2B - dopuszczalna prędkość (int)
- 12B - numery eventów dla zgodności z MaSzyna
- 8B - wskażnik na tor wcześniejszy i następny
Wychodzi 117 bajtów bez nazwy i opisu. Można:
- dać identyfikator zamiast nazwy (indeks na listę, jak tekstury) - 121,
- ewentualny komentarz w sąsiednim rekordzie,
- pozostaje 7 bajtów na zapisanie pierdół typu obwód izolowany, zmiany parametrów w czasie, wskaźniki do semaforów i sygnałów ustalających prędkość itd.,
- w razie potrzeby można utworzyć kolejny obiekt z dodatkowymi parametrami (np. przenieść do niego eventy).
Wychodzi na to, że są 2 możliwości:
- 128 bajtów na rekord przy ciasnym upakowaniu torów,
- 256 bajtów na rekord z wszelkimi informacjami, i jeszcze dajemy możliwość zapisywania własnych zmiennych roboczych w rekordzie.
Listy tekstur oraz modeli również zapiszemy w postaci rekordów (będzie trochę redundancja), ale dzięki temu można będzie użyć wskaźnika na rekord, zamiast indeksu listy.
Struktura początku rekordu będzie następująca:
class BinItem
{//ogólnie obiekt w rekordzie
public:
unsigned __int8 Flags; //flagi rekordu
unsigned __int8 Len; //długość użytkowa (początek komentarza)
unsigned __int16 Type; //rodzaj rekordu
unsigned __int32 Path; //wskażnik na rekord właściciela
unsigned __int32 Id; //identyfikator w ramach listy, numer
};
Najbardziej elastycznym rozwiązaniem będzie przyjęcie rekordu o długości 128 bajtów z możliwością połączenia z następnym. Bit 7 w zmiennej Flags określi długość rekordu (=0 - 128 bajtów, =1 - 256 bajtów). Zmienna Len w przypadku rekordów wskaże na początek wolnego miejsca na komentarz w rekordzie. W przypadku wczytania danych zapisanych nowszą wersją edytora, wartość ta nie może zostać zmniejszona, co pozwoli ochronić pola dodane w nowszej wersji.
Dalsze pola (za Type będą zależne od zawartości zmiennej Type, która określa rodzaj obiektu opisanego w rekordzie.
-
Zastanawiam się, czy jest sens mieszać podsypkę z torem. Z punktu widzenia tworzenia trasy w niektórych miejscach wyświetlanie podsypki jest niepotrzebne (mosty z mostownicami, stacja z terenem w poziomie podkładów) albo wręcz szkodliwe. Jeśli nie zależy nam tak bardzo na wielkości pliku scenerii proponuje przenieść podsypkę jak i całą resztę otoczenia do osobnych rekordów, lub nadania w torze bajta lub flagi o braku rysowania podsypki.
Uważam, że dużym problemem może być definicja terenu. Co prawda można to zrobić jako każda linia osobno, ale wtedy potrzeba w każdym rekordzie zrobić odniesienia do reszty linii lub sprawdzać to programowo (jeśli chcemy zachowywać relacje). Można też definiować trójkąty lub inne figury geometryczne przy czym problem pozostaje ten sam, czyli zachowywanie relacji do innych struktur.
Pojawia się pytanie czy na przecięciach linii terenu i torów (ścieżek?) automatycznie generować nasypy i wykopy wraz z odwodnieniem i nie zapisywać tego, dopiero przy eksporcie (przy torze musiałaby być wtedy flaga generowania nasypu, by nie generować go przy obiektach mostowych/tunelowych) czy może każdy taki obiekt zapisywać jako zestaw rekordów.
Wiem, że to może dalsza przyszłość, ale błędy popełnione na etapie koncepcyjnymi mszczą się latami ;)
-
Aktualnie rekordy dla torów mam bardzo zbliżone do formatu MaSzyny. Tylko eventy mi się nie zmieściły, ale te dam w wersji wzdłużnej i będą wiązane z torami przy eksporcie. Są wskaźniki na tekstury szyn i podsypki, jak nie będzie wskaźnika na podsypkę, to się podsypka nie wyeksportuje.
Definicję pełnego przekroju poprzecznego (szerokość rowu, głębokość rowu, nachylenie skarp w wykopie, linia kontaktowa z resztą terenu) chcę umieszczać przy okazji słupków hektometrowych (co 100m), ewentualnie gęściej (bez słupka), jeśli będzie potrzeba. Samo podtorze (nasyp oraz wewnętrzne pochylenia w rowach) chcę tworzyć jako road, umieszczony równolegle do toru (oczywiście poza stacjami i z przerwami na budowle). Rów i skarpa będą w definicji jw, a dalszy teren w grupach trójkątów (chcę przetestować trianagle_strip, bo chyba tego nikt nie używa) - wydaje mi się, że najbardziej optymalnie będzie dawać je prostopadle do toru. Wszelkie budowle (przepusty, wiadukty) będą zapisane w wersji krzywoliniowej toru, tak więc bezproblemowo zrobi się przerwy w nasypach.
Zapis scenerii będzie dualny. Po pierwsze tory w postaci odcinkowej, ustawiane równolegle do prostych kierunkowych oraz łuku o ściśle określonym promieniu. Przy przestawieniu prostych kierunkowych, tory odcinkowe będą się wyświetlać jako błędne i trzeba będzie zdecydować o sposobie poprawienia ich (będzie kilka do wyboru). Po drugie, w postaci krzywoliniowej, czyli jako ciąg naprzemiennych prostych i łuków (z krzywymi przejściowymi), z obiektami umieszczonymi wg długości toru od pewnego miejsca zerowego.
W przypadku wprowadzenia zmian w układzie torów, trzeba będzie uruchomić weryfikację, która wyświetli miejsca występowania błędów. Najlepiej jest układać od razu tory zgodnie z mapą, wtedy narzędzia modyfikujące nie są potrzebne. Ale mamy kilka realistycznych scenerii, robionych na oko, przez co wiele trzeba w nich poprzesuwać, żeby przypominały rzeczywistość. Poza tym np. na mapach Geoportalu są uskoki rzędu 2m na środku stacji - można będzie ustawić jedną część stacji wg jednego zdjęcia, drugą część wg drugiego, a następnie całość obrócić tak, żeby uzyskać prostoliniowość torów bez sztucznych zakrętów - nie będzie wtedy to pasowało do mapy, ale będzie maksymalnie zgodnie z nią zrobione. No i jeszcze są dane wektorowe UMP, które też trzeba poprzesuwać i porobić w nich łuki.
Dzisiaj zrobiłem prostowanie ciągu torów prostych do linii kierunkowej. Ręcznie się nie da orzesunąć tego z taką dokładnością. Teraz będę dążył w kierunku dzielenia "zawijasów" Beziera na proste i łuki o określonym promieniu. Żeby nie było, że jest prosta, bliżej nieokreślony "fleks" i druga prosta pod innym kątem. Potem jeszcze muszę usztywnić rozjazdy krzyżowe (4 zwrotnice i 8 torów) i ustalić precyzyjnie ich wymiary - aktualnie się nieprzyzwoicie rozjeżdżają przy prostowaniu torów. Potem mnie czeka import semaforów i wiązanie ich z torami. Na tym etapie będzie można już zrobić jakieś AI i uruchomić prototyp serwera ruchu. Dalej to już tylko edytor profilowy...
W załączeniu widok z edytora w powiększeniu 16px/m. Tory (kolor czerwony) są rozmieszczone równo co 5m od linii bazowej (kolor niebieski).
Na dolnym obrazku widać efekty pracy edytora. Przez tor u samej góry przechodzi główna (bazowa) linia kierunkowa (niebieska, pomiędzy czerwonymi szynami). Jest ona jedyną linią dla tej stacji, określoną za pomocą odcinka. Wszystkie tory równoległe do niej są ustawione w odpowiedniej odległości - 5m, 10m, 20m itd. Pozostałe używane kierunki wyznaczone są przez wtórne linie kierunkowe - po lewej stronie widać zwrotnicę wyświetloną na niebiesko, która definiuje wtórną linię. Wtórne linie się nie wyświetlają, ale gdy zaznaczy się odcinek (na zielono), to rysowana jest linia łącząca go z obiektem definiującym linię kierunkową (tu: niebieska, pomiędzy torami). Niebieski kwadrat na zaznaczonym torze oznacza, że jest on dowiązany do linii kierunkowej. Linię wtórną można także użyć do ustawienia kierunku torów niekoniecznie odchodzących od zwrotnicy określającej kierunek. Na obrazku jest zaznaczona grupa torów prostych (na żółto), odległa od ustalonego niebieską zwrotnicą kierunku o 5m. Tak więc zwrotnica po lewej stronie (pod niebieską) nie określa linii kierunkowej, ale się do niej dostosowuje. Podobnie rozjazdy krzyżowe umieszczone są na przecięciu linii równoległych do kierunkowych, przechodzących wzdłuż torów.
-
Jestem swiadom tego, ze od ostatniej odpowiedzi minelo >2 miesiace; chcialem jednak powiedziec, ze jesli chodzi o LokSim3D, a w szczegolnosci o edytor wlasnie, to moge sluzyc swoja osoba; jesli ktos zna nasze forum, to wie, ze ja (tzn. tam "Quork") naleze do aktywnych konstruktorow do LokSim3D, najwiekszym projektem jest oczywiscie trasa, mam jednak tez na koncie kilka objektow, tekstur do nieba, i jedna kabine, wykonana, nota bene, w nowej technice nie stosowaniej dotad w towarzystwie LokSim3D. Moge byc rowniez znany niektorym z postujacych filmy z MaSzyny na YT, tam jako "quorkqtar". Wybaczcie prosze ewentualne bledy ortograficzne lub nieznane skroty, urodzilem sie tu (tzn. w Niemczech) i tu cale zycie ("Cale", tzn. 17 lat) spedzilem dotad, pomijajac urlopy w Ojczyznie.
BTT: Nie przeczytalem jeszcze dokladnie tego, co tu pisaliscie, ale z tego co widze, to troche za skomplikowanie to widzicie; n.p. nasyp: Czym rozni sie, dla programu, nasyp od Giewonta? Sprobuje zwiezle opisac edytor LS3D. Przedtem jeszcze jedna rzecz chcialbym zaznaczyc; nie wypowiadam sie na tematy typu "czy trasy fikcyjne sa czyms gorszym?", gdyz nie bedac uzytkownikiem MaSzyny nie mam, tak uwazam, prawa sie wypowiadac. Rozne zdania wynikaja tez z roznych podejsc do sprawy, do problemow konstrukcyjnych, a rowniez z dostepnosci przepisow kolejowych, ktore, o ile wiem, w Polsce sa mniej jawne niz tutaj. Jestem jedynie tutaj, by sluzyc swoja wiedza na temat LokSim3D, i sie dowiedziec roznych metod pracy stosowanych w EU07, moze znajde tutaj inne ciekawe podejscia do jakichs problemow, ktore mi pomoga rozwiazac swoje problemy, i mam tez nadzieje, ze moze ktores z moich podejsc Wam pomoga.
1. Pliki
Sa trzy podstawowe typy plikow, ktore tu graja role (pomijam .l3dlok, .l3dfpl, .l3dfont itp.). Sa to:
- .l3drail
- .l3dobj & .l3dgrp
- .l3dstr & .l3dkbs
Pierwszy, to jest plik toru. W nim jest zdefiniowany przekroj toru, rozstaw, wysokosc & grubosc szyn oraz tekstura. To znaczy, taki prosty, choc specjalistyczny objekt. (Program generuje wzdluz zdefiniowanej w trasie linii odcinki o danym tu profilu i teksturze, i dlugosci zawsze 10m, ale to juz mniej wazne).
Drugie, to sa objekty i objekty zgrupowane. Proste rzeczy, jak lawke itp. sie robi z pojedynczego objektu. Pojedynczy objekt sklada sie z punktow i powierzchni, ma jedna teksture i ewentualnie jedna teksture przezroczystosci. Najpierw uklada sie punkty, potem "naciaga" powierzchnie miedzy nimi, a potem sie przypisuje odpowiednie czesci tekstury odpowiednim powierzchniom.
Specjalna odmiana objektu, o ile wiem nie znana w EU07, jest objekt "wspolkrecacy" sie. To znaczy, ze automatycznie sie odwraca tak, ze sie zawsze patrzy dokladnie wzdluz jego osi Z. W ten sposob n.p. sa robione bardzo realistyczne, a FPS-oszczedne drzewa: Cztery punkty, powierzchnia, tekstura, tekstura przezroczystosci (moga tez byc skombinowane; mozna zdefiniowac w .l3dobj, ze kazdy pixel tekstury o kolorze x jest przezroczysty). Zawsze sie widzi dokladnie prostopadle, wiec nie przeszkadza, ze jest to plaskie zdjecie, a jak sie to cwanie wykorzysta, to pociag podczas jazdy odtraca galezie.
W objekcie zgrupowanym laczy sie wiele objektow ze soba w jeden duzy objekt. Stosuje sie to zawsze, jak albo nie starczylaby jedna tekstura, jeden element sie powtarza wiele razy, lub jesli jest po prostu bardzo skomplikowany. W objekcie zgrupowanym tez mozna ustawic dodatkowe rzeczy: faktor powiekszenia, tzn. czy objekt sie na ekranie zmienia zaleznie od odleglosci wedlug praw perspektywy, bardziej, czy mniej. Mniej, to n.p. kolorowe swiatelka w semaforach. Jak jestes blisko semafora, to widzisz normalnie szybke, a jak jestes daleko, to widzisz wyraznie swiatla, choc szybka ma <1pix, bo jest tam kolko o kolorze swiatla, ktory z bliska ma rozmiar <1pix i go nie widac, a z daleka ma 3 pix, wiec widzisz. Nastepnie czestotliwosc migania, oraz warunki, kiedy widac. Warunki sa to przede wszystkim sygnaly na semaforze (czyli, jako ze to niem. symulator, Hp0 do Hp2, Vr0 do Vr2, Ks0 do Ks2 itp.), poza tym boolean podany jako argument w pliku trasy, stan zwrotnicy, stan przejazdu kolejowego lub tez generator booleana przypadkowego. Pozatym w objekcie zgrupowanym mozna tez dodac tekst.
Trzecie, najwazniejsze tutaj, to jest plik trasy.
Pojedynczy modul sie buduje w .l3dstr, a w .l3dkbs mozna polaczyc moduly ze soba. Tam tez sie ustawia zwrotnice (nie w trasie!).
W pliku trasy podstawowym elementem jest tor. Kazdy tor definiuje swoj wlasny uklad. Jak tor skreca, idzie w gore czy w dol, lub cokolwiek innego, to os tego ukladu tak samo sie zachowuje.
Tor ma po pierwsze wlasciwosci, takie jak "ktory .l3drail?", "predkosc maksymalna", "tunel", "most", "przejazd" (te trzy nie dla grafiki, tylko dla systemu dzwiekowego), tutaj sie ustawia semafory, jakosc torowiska, stacje, opisy waznych punktow na trasie do EBuLa (nie mam niestety pojecia, jak to sie nazywa w j. polskim). To wszystko jest podane w zaleznosci od kilometrazu, tzn. osi toru.
Po drugie, "topologia". Tutaj sie wpisuje zakrety, stoki, zwrotnice, tzn., to tu sie modyfikuje os toru i definiuje, jak sie osie poszczegolnych torow maja do siebie.
Po trzecie, "objekty trasy". Tutaj sie ustawia wlasnie .l3dobj i .l3dgrp wzdluz toru, pojedynczo, lub inna ilosc ze zdefiniowanym odstepem, przypadkowa odchylka pozycji od sredniej, obrocenie objektu, oswietlenie itp. Jak chce las swierkowy wzdluz toru od HM20/3 (km 20,3) przez trzy kilometry, to zakladam objekt trasy do toru, przy danej pozycji, i w nim laduje .l3dobj ze swierkiem, i definiuje, ze chce miec 3000 swierkow co 1m. Tylko ze stoja one jak zolnierzyki dokladnie po srodku toru. Wiec ustawiam "x=40m", i je mam 40m na prawo od toru. Potem ustawiam przypadkowa odchylke: x=30m (to znaczy, ze objekty beda przypadkowo rozmieszczone miedzy 30m na lewo a 30m na prawo od glownej osi objektu, czyli 10 do 70m na prawo od toru), y=2m (gora-dol), z=.5m (to znaczy, ze odstep miedzy dwoma objektami wzdluz osi toru jest, jak podalem wyzej, 1m, +- wlasnie te 50cm.). Juz mam po prawej stronie toru pas lasu o dlugosci 3km i szerokosci 60m.
I juz mam gotowy ten las, i on mnie w ogole nie interesuje. Moge robic dowolne zakrety w torze, las sie automatycnie wykrzywi. Zawsze sie bedzei zaczynal 10m a konczyl 70m na prawo od toru. Jak dodam stok 6 promili, to las tez bedzie na wysokosci toru zawsze. Moge ustawic wysokosc lasu albo jak y, czyli w zaleznosci od toru, wtedy bedzie zawsze n.p. 10m nad torem, ale moge rowniez podac y nad terenem. To jak z prawej dodam row, to drzewa w rowie beda nizej.
Tym samym doszlismy do "objektow terenu". Objekt terenu sklada sie z punktow. Punkt ma pozycje wzdluz osi toru (jak las; zawsze sie dopasuje do toru), odstep od osi, i wysokosc nad osia. Program potem laczy te punkty, i z nich "zwiesza" powierzchnie. Jak mam zakret, i chce, zeby ta linia tez skrecala, a nie byla bezposrednim polaczeniem tych dwoch punktow, to wlaczam automatyczne punkty co n.p. 10m, i wtedy program dodaje co dziesiec metrow punkt, wiec jak mam dwa punkty, jeden 3m od toru i 2m ponizej, a drugi 30m dalej, 4m od toru i 2m powyzej, i mam na tych 30m zakret, to wtedy, bez automatycznych punktow, jest prosta linia od punktu do punktu, i ewentualnie krzyzuje nawet tor. A jak wlacze te automatyczne punkty, program wygeneruje punkt na 15. metrze, 3.5m od toru i 0m nad torem, i przez niego przepusci linie, przez co znowu jest ona zalezna od osi. Zalezy, czego sie chce, raz sie je wlacza a raz nie. Rowniez w objektach terenu nakladam teksture na teren, n.p. trawe, beton, liscie, itp.
"Lange Rede, kurzer Sinn", dluga mowa a krotka tresc, jak to mowia Niemcy: Niby tez jest uklad descartes-ki, ale jego os Z sie zawsze skreca z torem, X tez, rpostopadle do toru, a Y z nim przesuwa w gore/dol (X,Y,Z troche dziwnie uzyte. Odnoszac sie do opisu stosowanego w rysunkach technicznych lub w matematyce wektorowej: X to x2, Y to x3 a Z to x1) lokalnie. Wiec jak masz przebieg trasy z mapy, to potem ogladasz zdjecia i filmy z trasy, i widzisz: O, HM20/3, jest lasek po prawej, to ustawiasz na km20,3 lasek po prawej, i Cie nie obchodzi, czy byly jakies zakrety i jakie sa wspolrzedne wobec punktu 0,0,0, czy to jest teraz na 333m czy na 3333m n.p.m., bo to wszystko program robi sam. Widzisz: O, tu jest nasyp 3m, to definiujesz pod torem objekt terenu, ktory sie zaczyna 6m na lewo od toru na wysokosci -3m, 1m na lewo od osi wysokosc 0m, 1m na prawo 0m, 6m na prawo -3m, a dlugosc n.p. 300m, a teksture wybierasz zwirowa. A jak widzisz pagorek 200m na prawo, to robisz pagorek 200m na prawo, dokladnie ta samo metoda co nasyp.
Mam nadzieje, ze mi sie udalo troche wyjasnic, do czego Ra sie odnosi, mowiac o LokSim3D, a raczej w tym wypadku o LokSimEdit.
Julian
-
Spiesze ze screenshotami.
Po pierwsze tory.
(http://eu07.pl/userfiles/6257/foto-l3drail_001.jpg)
Z prawej widac teksture. Sa na niej bok szyny, gora szyny i nasyp. Z lewej sa z gory na dol:
- Sciezka do tekstury
- Czarny przezroczysty?
- Rozstaw
- Szerokosc nasypu
- Wysokosc szyny
- Szerokosc szyny
- X, Y lewego gornego rogu, szerokosc, wysokosc czesci tekstury, na ktorej jest nasyp
- Tak samo gora szyny
- Tak samo bok szyny
- Przekroj nasypu
(http://eu07.pl/userfiles/6257/foto-l3drail_003.jpg)
Tak to potem wyglada (obj by JulianG)
(http://eu07.pl/userfiles/6257/foto-l3drail_002.jpg)
(http://eu07.pl/userfiles/6257/foto-l3drail_004.jpg)
Tak samo sa tworzone drogi i rzeczki. To moj strumyk, z tekstura zrobiona w Beskidzie Nowosadeckim
Przechodzimy do objektow:
(http://eu07.pl/userfiles/6257/foto-l3dobj_001.jpg)
(http://eu07.pl/userfiles/6257/foto-l3dobj_002.jpg)
Skrzynka z dw. zach. w Warszawie. Czy to jest wlasnie podstacja? U nas ani takich rzeczy nie widac, ani nie sa one wymnieniane w EBuLa... Z lewej sa punkty, a pod spodem powierzchnie. Z prawej sa wlasciwosci punktu/powierzchni, jesli jest zaznaczony, a jak nie, jak tu, to wlasciwosci calego objektu. Podana jest sciezka do tekstury, nie ma przezroczystosci, powierzchnie widoczne z obu stron (stary objekt, kiedy jeszcze naduzywalem tej funkcji...) TAK, samoswicace NIE, wspolkrecace NIE.
(http://eu07.pl/userfiles/6257/foto-l3dobj_003.jpg)
O, a tu widzicie wlasnie objekt wspolkrecacy (tzn, odwraca sie tak dookola Y, ze zawsze sie go oglada wzdluz osi Z), jak widac po zaznaczonym najnizszym polu. Poza tym jest wybrane, ze kazdy piksel majacy ten sam kolor co gorny lewy rog jest przezroczysty (czyli tutaj czarny). Odpowiednio na dole widzice wysoce realistyczne drzewo, a tym czasem sa to tylko 4 vertices i 1 poly, jak widac po lewej na gorze. (obj by Frieder Cramer)
Nastepuja objekty grupowe:
(http://eu07.pl/userfiles/6257/foto-l3dgrp_001.jpg)
(http://eu07.pl/userfiles/6257/foto-l3dgrp_002.jpg)
Na gorze z lewej widac liste objektow, ktore sie skladaja na ten objekt grupowy. Zaznaczony jest tekst. Z prawej sa wlasciwosci tego tekstu: Czcionka, pozycja, obrocenie, rozmiar, kolor; nie swiecace, nie migajace, ustawienie poziome: srodek, ustawienie pionowe: gora, tekst standardowy, nazwa argumentu ktorym mozna ustawic tekst z perspektywy trasy.
(http://eu07.pl/userfiles/6257/foto-l3dgrp_003.jpg)
A tak wyglada semafor. Zaznaczony jest opisany w poprzednim poscie objekt pomocniczy zwiekszajacy widocznosc sygnalu.
Niedlugo o .l3dstr tez dam.
« Dodano: 17 Marca 2009, 21:55:09 »
Przede wszystkim zapomnialem wyzej przy lokomotywie, (obj by AndreasZ (Nietenzähler) & Lena S. (Br641))
(http://eu07.pl/userfiles/6257/foto-l3dstr_001.jpg)
Widzimy tutaj plik trasy .l3dstr. Na dole z prawej mapa, z lewej na dole podglady, z lewej na gorze lista torow. Jeden tor, Awanst Kaltendorf, jest zaznaczony i dla pokazu calkowicie rozwiniety. Najpierw jest topologia, tutaj tylko jedna zwrotnica (do toru Hauptgleis). Potem wlasciwosci do przodu i do tylu, szczegoly pozniej. Nastepnie lista objektow trasy; w takim objekcie trasy sie laduje objekty i objekty zgrupowane i pozycjonuje wzdluz toru, szczegoly rowniez pozniej, tak samo tez z objektymi terenu. Z prawej na gorze widac teraz wlasciwosci toru. Sa to: Nazwa (Awanst Kaltendorf), typ (tor rownolegly, tzn. nie z jakiegos zdefiniowanego miejsca, tylko rownolegle do istniejacego juz toru), rownolegly do (Hauptgleis), od (5800), do (6600) i w odstepie od oryginalnego toru (10). Jednostki oczywiscie metry.
(http://eu07.pl/userfiles/6257/foto-l3dstr_002.jpg)
Zajmijmy sie wlasciwosciami, kierunek wybrany jest do przodu. Mamy kolumny opis (co jest napisane w EBuLa), predkosc maksymalna, semafory, opcje semafora, przystanki, przejazdy kolejowe, .l3drail, jakosc torowiska, dalej (poza kadrem juz) LZB (Linienförmige ZugBeeinflussung, system wirtualnych semaforow, stosowany przez pociagi >160km/h, n.p. BR401 do BR416, czyli ICE1, ICE2, ICE3 we wszystkich wersjach, ICE T we wszystkich wersjach (ICE TD tez, ale ma inny numer), Thalys (BR406 chyba) itp., oraz lokomotywy n.p. 101, 146, 246 itd.), zmiany kilometrazu widocznego na tablicach hektometrowach (mozna tez ustawic na mile; nie ma wplywu na kilometraz w kontekscie budowy), dodatkowe elementy InduSi (podsystem PZB, odpowiednik SHP), pochylenie toru poprzeczne (albo absolutna liczba w stopniach, albo faktor korekcyjny do automatycznego liczenia z zakretu i predkosci maksymalnej), pozostale (informacje dla systemu dzwiekowego: tunel/most/przejazd/szpara) i informacje o minimalnej drodze hamowania.
(http://eu07.pl/userfiles/6257/foto-l3dstr_003.jpg)
Tutaj jest definiowany objekt trasy. Nazwa (Industrie), pozycja (6300), stopien waznosci (uzytkownik wybiera 0, 1,... lub 5, i odpowiedni widzi objekty o stopniu waznosci do 0, do 1,... do 5) (2: wazne objektu, n.p. mostu, tunele), widoczny tylko jesli pociag nie przejedzie przez te pozycje (zwrotnice w LokSim3D nie sa przestawiane podczas symulacji. Ustawiano sa w pliku .l3dkbs. Tym sposobem mozna wiec ustawic pociagi na trasie, ktore sa widoczne, jak sie jedzie innym torem, bo zawsze wiadomo dokladnie, gdzie pociag przejedzie a gdzie nie) (nie). Z prawej mozny przesunac wzdluz toru (bywa sensowne, zeby n.p. trzy objekty trasy mialy podana te sama pozycje dla przejrzystosci, a przez to dodatkowe pole i tak sa przesuniete), w poprzek toru i w gore/dol.
(http://eu07.pl/userfiles/6257/foto-l3dstr_004.jpg)
Tutaj z kolej widzimy objekt trasy, w ktorym jest ustawione "widoczne tylko przy nieuzytym torze", bowiem jest tu ustawione kilka wagonow stojacych na bocznicy. Jedna linijka to objekty z jednego pliku. W pierwszej kolumnie jest pozycja pierwszego z tych objektow, potem ilosc, sciezka do .l3dobj lub .l3dgrp, odstep miedzy dwoma objektami tej linijki (jesli jest w pierwszej kolumnie inna liczba niz 1)(w tym wypadku oczywiscie dlugosc jednego wagony, zeby byly polaczone a nie oddalone lub powsadzane jedne w drugie), przesuniecie wobec osi objektu (poniewaz wagony maja stac na szynach, zasadniczo 0), wysokosc (oczywiscie znow 0), wysokosc nad terenem (boolean; jesli nie zaznaczone pole, to wtedy wysokosc sie odnosi do toru, a jak zaznaczone, to do terenu w danym miejscu), obrocenie wobec X, Y, Z, dopasowane do stromizny (jesli tak, to wtedy objekt jest obracany wokol osi tak, ze jego os jest rownolegla do toru, tzn. ze jak mam tor skrecajacy i idacy do gory, to wtedy n.p. plot jest odpowiednio pochylony, a pozatym tak odwrocony, ze dwa objekty jeden za drugim sie lacza. Jak nie, to wtedy objekt stoi pionowo, i nie jest w sredniej rownolegle do toru tylko zawsze w punkcie 0,0,0 objektu. Tzn, ze wtedy plot nie bylby polaczony) oraz daleko widoczne (jesli tak, to objekt jest wyswietlany z wyzszym priorytetem, jesli jest wlaczona opcja "uprosc grafike przy FPS < [wybor uzytkownika]" w symulatorze).
(http://eu07.pl/userfiles/6257/foto-l3dstr_005.jpg)
Natomiast tu mamy park. W tle widac, ze te drzewa sa odsuniete o 11m od toru, obnizone o 1m i pozycjonowane nad terenem, a nie torem. Z przodu okienko pozycjonowania przypadkowego. Jesli na gorze sie wlaczy przypadkowe pozycjonowanie, to ponizej sie podaje, o ile metrow najwyzej objekt jest przesuniety od wlasciwej pozycji w porzek toru, w gore lub dol i wzdluz toru. Ponizej liczba inicjalna randomisera. Jak sie ja ustawi, to taka bedzie w tym objekcie zawsze. Wiec jak wybiore taka wartosc, zeby akurat w rzeczce nie wypadalo zadne drzewo, to wtedy w symulatorze tez zadne drzewo nie bedzie w rzeczce, gdyz nie za kazdym razem sa przypadkowo rozmieszczane objekty, tylko jednorazowo.
(http://eu07.pl/userfiles/6257/foto-l3dstr_006.jpg)
Tu mamy liste elementow topologii toru Hauptgleis. Widoczne sa zakrety (Kurve) i stromizny (Steigung), na ktoryms z poprzednich obrazkow byla zwrotnica. Jest tez jeszcze skrzyzowanie. Z prawej sa wlasciwosci zaznaczonego zakretu. Zaczyna sie on na pozycji 1580, konczy na 1900, kat jest 50°, i zakret jest lagodny (nie odcinek kolka, tylko zaczyna sie delikatnie, coraz ciasniejszy sie robi, i znowu konczy delikatnie).
(http://eu07.pl/userfiles/6257/foto-l3dstr_007.jpg)
(http://eu07.pl/userfiles/6257/foto-l3dstr_008.jpg)
Tutaj widzimy roznice, jako robi funkcja punktow dodatkowych. Lewy objekt nie ma punktow posrednich, tzn. bezposrednio sa polaczone zdefiniowane punkty, jak tez widac na obrazku. Ma on nazwe i pozycje, ponizej wlasnie sie wlacza punkty posrednie i ustawia ich czestotliwosc, potem sie wybiera, czy punkty sa laczone w poligon (mozna bowiem zrobic albo jakas powierzchnie, ktora odpowiednio powinna byc ograniczone ze wszystkich stron, n.p. jezioro, ale tez gran, a wtedy ostatni i pierwszy punkt nie powinny byc polaczone), jesli tak, to czy jest teksturowany czy nie, a jesli jest teksturowany, to sie wybiera sciezke do tekstury. Jesli w tym miejscu teren ma byc przezroczysty, n.p. do wjazdu do tunelu, to sie pozostawia to pole puste. Pod spodem mozna wybrac skale tekstury i otworzyc okienko z opcjami jej oswietlenia. Z prawej sie definiuje pozycje punktu wzdluz osi toru, odstep od osi toru, wysokosc nad torem. Mozna tez zaznaczyc prawe pola (ale, choc sa niezalezne w edytorze, musza byc wszystkie TRUE lub wszystkie FALSE), wtedynie wplywa sie tym objektem na ksztaltowanie terenu, a tylko naklada teksture jak obrus. Wtedy jednak nalezy uwazac; jesli w tym miejscu jest jakas struktura terenu, to musza byc wlaczone punkty posrednie, inaczej ten "obrus" wymusi plaszczyzne.
Prawy objekt natomiast ma wlaczone punkty posrednie; punkty juz nie sa polaczone bezposrednio, tylko objekt jest wykrzywiony wzdluz toru. Tego objektu zreszta, jak widac, nie teksturowalem.
Mam nadzieje, ze tym tekstem troche Wam moglem wytlumaczyc sposob dzialania naszego edytora. Podsumowujac ostatecznie: Punktem odnosnym do wszystkiego jest tor. Nie trzeba liczyc skomplikowanych wspolrzednych, tylko mozna budowac bezposrednio wedlug zdjec i flimow jakie sie ma.
Jesli macie jakies dokladniejsze pytania dotyczace edytora czy chcecie cos wyprobowac (moj tekst jest bardziej pod katem opisu systemu, a nie obslugi) to mozecie pytac oczywiscie mnie, ale jesli n.p. jakis budowniczy objektow chcialby sie wymienic dokladniej na ten temat, to prosze zwroccie sie do uzytkownika M-Gleiser, ktory sie tu zarejestrowal rownoczesnie ze mna. On jest naszym oficjalnym 'dyplomata' i wlasnie koordynuje takie wymiany informacji z innymi symulatorami. Tyle ze do niego trzeba w jezykach niemieckim lub angielskim, wiec w przypadku trudnosci oczywiscie sluze tlumaczeniem.
Julian
-
Jak dla mnie, edytor w wersji 2.1 jest bardziej przejrzysty. I bardziej się nadaje do tego, żeby zrozumieć zasadę jego działania. No i jest po angielsku. Problemem może być jedynie znalezienie archiwum z wersją 2.1. Ale bardzo polecam wypróbowanie tego edytora, gdyż obrazuje on zupełnie inne podejście do budowy tras, niż jest możliwe za pomocą 3ds Max.
Z drugiej strony na to patrząc, w trasach realistycznych, robionych wg map, mamy raczej podane wysokości n.p.m. dla danego punktu i opieranie się jedynie na względnych współrzędnych mogłoby być kłopotliwe. Szczególnie jeśli organizacja budowy trasy jest inna niż "zaczynamy z punktu A i metr po metrze idziemy do punktu B".
Ja w swoim edytorze zrobiłem to nieco odwrotnie. Najpierw zostały ułożone tory wg zdjęć lotniczych. Potem np. na pozycji 17593m liczonej wzdłuż toru chciałem wstawić nastawnię - i okazało się, że musiała by stać dalej o parę metrów, niż widać ją na zdjęciu. W takiej sytuacji musiałem wprowadzić współczynniki przeliczeniowe dla długości trasy, bo zdjęcia są zniekształcone. 1km2 na zdjęciu ma fizyczne wymiary 1000.7m×1000m. Niby drobiazg, ale na długości 10km mamy przesunięcie 7m, co jest zauważalne (budynki pozycjonowane w kilometrażu nie pokrywają się z ich pozycją na zdjęciach).
-
Wersja 2.1??? Matko, kiedy to bylo... Dawno, ale to bardzo dawno przed moim czasem w LS3D, ja sie ledwie otarlem o 2.4... *lol*
No coz, jeszcze sie nie zajmowalem problematyka trasy realnej (bo "realistycznymi" sa tez fikcyjne; inaczej nie przejda przez "Beta", pozycja kazdego "magnesu", kazdego czujnika, kazdej tablicy musi byc poprawna (pamietam jaka byla przeprawa, zanim moj przejazd kolejowy zadowolil...)), ale musi ze to sie da, z samych nowszych przykladow byloby:
- Saalebahn: Okolice Großheringen, Jena itp.
- Murgtalbahn: Schwarzwald (miedzy Badenia a Württembergia)
- Seifhennersdorf-Varnsdorf-Zittau-Bily Kostel-Chrastava-Liberec: Trasa przez Niemcy, Polske i Czechy
- ...
Spytaj M-Gleisera, czy Ci moze dac kontakt z ktoryms z konstruktorow, pierwszego (RainerZ) jeszcze widuje w forum, ale Albrechta (lokfan), od Murgtalbahn, to juz dlugo nie widzialem, a do Gerda Bukovskyego to trzeba chyba mejlem, to M-Gleiser moze wie, ja G.B. nie znam.
-
W koncu z tego wszystkiego zapomnialem pokazac, jak to potem wyglada...
http://download.lima-city.de/quorkqtar/Clipboard03.png
Moja wlasna trasa, a "pociong" to VT08, znany zapewne niektorym ZuSi-owiczom
-
Moglbys nam przetlumaczyc sterowanie i opisac 'jak' jezdzic ?:]
pzdr
-
Chetnie, ale dopiero po 19tym, bo wyjezdzamy na urlop... akurat do Wloch...
-
Moglbys nam przetlumaczyc sterowanie i opisac 'jak' jezdzic ?:]
pzdr
W zastępstwie ja mogę pomóc, ale gdzie to wszystko opisać by nie było OT?
-
W test.
-
Wrzuc do biezace kolejowe, bo z testu raz dwa nam zginie :]
-
Ale jak dobrze rozumiem, będzie to opis symulatora ZUSI ?
-
Taa, ale w przyplywie tematow o naszych zwierzatkach i komorkach, mysle ze takie cos chyba nie zaszkodzi, zwlaszcza, ze zadnej polskiej dokumentacji nie mozna nigdzie znalezc...
-
Pewnie i tak. Dziwne, że nie ma polskiego forum o ZUSI. Może sobie utworzycie, liski... :)
-
Zarazara, to w koncu ZuSi czy LokSim3D? Przepisy kolejowe te same oczywiscie, ale klawisze to nie wiem jakie sa w ZuSi...
-
Zacząłem już pisać poradnik do LokSim (o ten symek chodziło, tak uetam?), ale jeśli ktoś chce mogę też napisać kompletny poradnik do ZuSi, nie ma problemu :)
-
Właśnie za chwilę będziemy opisywać wszystkie symulatory. Ustalcie co chcecie ostatecznie i wydzielić trzeba będzie do nowego tematu. Obecnie zboczyliśmy z kursu.
-
Ja chcialem do Loksima :P
-
Wracając do profilu pionowego trasy, krytyczną sprawą okazuje się zlokalizowanie punktów o znanym kilometrażu. Dzięki temu można między tymi punktami rozpiąć niweletę i równomiernie rozłożyć powstały błąd, bez powielania go na dalsze odcinki torów. Optymalną odległością lokalizowania słupków jest kilka kilometrów.
Najbardziej przydatne okazują się zdjęcia słupków, robione prostopadle do torów z charakterystycznymi obiektami terenu w tle. Obiekty te powinny być wystarczająco "grube" aby dało się je odszukać na zdjęciach lotniczych/satelitarnych - im więcej tym lepiej. Przykład idealnego zdjęcia jest w załączniku - widać pozycję słupka względem 2 słupów oraz osi asfaltu w tle (autor - @surgeon).