Ja się nie wypowiem w kwesti adaptacji RSF w EXE.
Chodziło mi tylko o to, że format RSF był projektowany z myślą o zastąpieniu nim formatu SCN, dzięki czemu odpadłyby operacje, które są wykonywane podczas wczytywania oraz po wczytaniu. W efekcie sceneria by się wczytywała szybciej i kawałkami, przez co można by dynamicznie doczytywać fragmenty podczas jazdy. Przez ostatnie 8 lat nie zaproponowano alternatywnego rozwiązania w tym zakresie. Zastanawiałem się nad zrobieniem wczytywania RSF do MaSzyny, miało to służyć początkowo jako podgląd 3D do edytora RSF. Ale póki co mam inne zajęcia i w dającym się przewidzieć czasie się za to nie zabiorę. Sens używania formatu tekstowego zanegowałem w 2008 roku, po próbach ustawienia profilu pionowego na scenerii "PMPPW".
Sam edytor powinien pracować na plikach tekstowych, które są przyjazne dla człowieka i VCS typu Git.
Jako że integrowałem klony scenerii przy użyciu SVN, jak również robiłem na plikach tekstowych inne operacje (obracanie scenerii "Kaliska", dzielenie dużych scenerii na mniejsze fragmenty), to mogę powiedzieć, że format tekstowy robi więcej problemów niż daje korzyści. Główne problemy to brak powiązań pomiędzy obiektami, literówki prowadzące do uszkodzeń obiektów, setki zmian widocznych w systemach śledzenia po drobnych korektach obiektów (np. nieznaczna korekta promienia łuku zmienia kilkanaście odcinków torów oraz kilkadziesiąt słupów i przęseł sieci trakcyjnej). Śledzenie zmian w scenerii przy użyciu SVN jest absurdem. O ile jeszcze byłem w stanie przejrzeć z uwagą 200 zmian, to już przy ilościach idących w kilkanaście tysięcy zmian dopatrzenie się błędu i skorygowanie go na poziomie systemu śledzenia wersji jest nierealne. Obecnie ograniczam śledzenie wersji do przeglądania torów (zmiany geometrii, nazw, przypisanie sygnalizacji), oraz sygnalizacji (zmiany nazw obiektów oraz połączeń), natomiast sieć trakcyjną czy otoczenie weryfikuję wyłącznie wizualnie (może oprócz łączenia sieci na granicy komórek).
Przy okazji - czy podtorze generuje Rainsted? Scala je z rzeźbą terenu?
Częściowo tak. Tzn. obecnie istnieje możliwość wczytania punktów wysokościowych (domyślnie NMT-100 albo istniejących trójkątów scenerii, np. fikcyjnych) i modelowania przekrojów poprzecznych podtorza pomiędzy linią niwelety (w uproszczeniu: poziom szyn) a terenem wyznaczonym z tych punktów. Mając przekroje podtorza można je zszyć z trójkątami terenu (z NMT-100) albo ścianami lasu, których dolna krawędź jest ustawiania wg punktów wysokościowych (lub trójkątów terenu).
Jednak jakiś czas temu opublikowano dane wysokościowe w rozdzielczości 1m i używanie tych danych w plikach RSF oraz w symulacji jest skrajnie niewydajne, z uwagi na ogromną ilość. Przymierzam do grupowania tych danych w kwadraty i następnie używania ich podobnie, jak ortofotomapy, tzn. byłyby używane do obliczeń, jednak do symulacji by szły jako siatki uproszczone. Z Geoportalu można również pobrać chmury punktów, które mogą być przydatne w edytorze, jednak używanie ich bezpośrednio w symulacji (bez uproszczenia) nie ma sensu praktycznego.
Moja koncepcja sprzed lat sprowadzała się do tego, że dla wybranego miejsca (np. co 100-500 metrów) tworzymy z dostępnych zdjęć i danych geodezyjnych siatkę (mesh), która w miarę dobrze przedstawia otoczenie tego miejsca, widziane z różnych punktów. Przemieszczając się wzdłuż torów, w pewnym momencie następuje przełączenie na sąsiednią siatkę, która ma większą szczegółowość bliżej tego nowego miejsca. Pierwotne moje założenie było w zakresie wykonywania tych siatek ze zdjęć stereoskopowych (np. film z przejazdu, choć to nie do końca stereoskopia), obecnie można wykorzystać chmury punków i bryły CityGML.
Pokaż wiadomości
1 Lubię to