Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Edytor Scenerii
Ra:
Ja bym proponował przejście na format RSF, bo masę pracy włożyłem w jego dopracowanie. Praktycznie wszystkie własności formatu SCN zostały odwzorowane w RSF (jeśli nie, to brakujące można dodać w ramach możliwości rozbudowy jego struktury). Dodatkowo format RSF zawierać może powiązania obiektów, które nie mogą być podane jawnie w SCN (ze względu na ograniczenia formatu tekstowego), a są częściowo odtwarzane po zakończeniu wczytywania SCN. Moim zdaniem format SCN nie nadaje się jako bazowy do edytora i powinien być używany jedynie do zachowania zgodności wstecznej oraz wykonania pewnych działań przy użyciu doraźnych narzędzi (np. edytorów tekstu).
Co do edycji sektorami, to moją propozycją jest podział na komórki (obszary mieszczące się w kwadracie o boku od kilku do około 30 kilometrów — optymalną wartość trzeba wyznaczyć eksperymentalnie). Część scenerii już ma podział na komórki, w podziale pozostałych mogę pomóc.
Format RSF pozwala odwzorować obszar kwadratowy o boku 524km, co jest porównywalne z obsługiwanym obszarem w MaSzynie (przynajmniej tak było w 2015 roku), więc teoretycznie całe scenerie można zapisać w RSF. Jednak w przypadku scenerii realistycznych nie ma to większego sensu, bo lepiej jest mieć osobne komórki i doczytywać je w miarę potrzeby. Jednak nie żadnego problemu z tym, żeby w RSF były zapisane dużo mniejsze komórki.
jakubg1:
Problem jest taki, że dokumentacja formatu RSF nie jest dostępna publicznie.
Uważam, że każdy edytor powinien mieć swój własny format pliku projektu, a import projektów z innych edytorów opcjonalny i potencjalnie stratny. Zawsze znajdzie się coś, czego format nie obsługuje, a chcemy zapisywać. Na przykład komentarze w sceneriach.
Ra:
--- Cytat: jakubg1 w 25 Września 2023, 14:26:25 ---Problem jest taki, że dokumentacja formatu RSF nie jest dostępna publicznie.
--- Koniec cytatu ---
To nie jest problem rzeczywiście istniejący. O dokumentację formatu RSF nikt nigdy nie pytał. Coś tam na ten temat pisałem, ale wobec totalnego braku zainteresowania nie chciało mi się wytwarzać bezużytecznych materiałów. Zwłaszcza, że ciągle dopracowywałem szczegóły i pewne rzeczy się zmieniały. Planowałem w 2015 roku wczytywanie z RSF do MaSzyny, po czym ktoś uznał, że nie warto tego robić i nie napotkałem na dyskusję, czemu taka decyzja i co zostało zaproponowane w zamian. Po 8 latach widać, że raczej nic.
--- Cytat: jakubg1 w 25 Września 2023, 14:26:25 ---Uważam, że każdy edytor powinien mieć swój własny format pliku projektu, a import projektów z innych edytorów opcjonalny i potencjalnie stratny. Zawsze znajdzie się coś, czego format nie obsługuje, a chcemy zapisywać. Na przykład komentarze w sceneriach.
--- Koniec cytatu ---
OK, zróbcie sobie sami, co chcecie. Zawsze można od nowa rozwiązywać problemy, które już zostały dawno rozwiązane. Tylko zróbcie więcej, niż obiecywacze, którzy na bazie hejtu na mnie zebrali popularność w 2015 roku i następnie jakoś w nieustalonych okolicznościach zniknęli. Ja mogę poczekać na gotowe. RSF obsługuje komentarze przy konwersji danych z SCN, aczkolwiek ich przydatność uważam za znikomą. W ramach Rainsted mam zrobiony system obsługi notatek do scenerii, w którym można do wskazanego miejsca przyczepić plik z opisem, a następnie dodawać w nim kolejne uwagi (np. postęp prac). System ten miał jeszcze współpracować z serwerem i zgłaszaniem błędów przez stronę internetową, ale to jest na razie zawieszone i na razie nie wiem, czy kiedyś dokończę. Format RSF ma również opcje rozbudowy i jeśli "czegoś nie obsługuje", to istnieją algorytmy, jak coś dodać, aby nie zepsuć.
marcinn:
--- Cytat: Ra w 25 Września 2023, 16:03:13 ---Planowałem w 2015 roku wczytywanie z RSF do MaSzyny, po czym ktoś uznał, że nie warto tego robić
--- Koniec cytatu ---
Ja się nie wypowiem w kwesti adaptacji RSF w EXE. Problemy z SCN są i uważam, że można je rozwiązać tylko wymianą SCN na format dostosowany do doczytywania sekcjami (teoretycznie tekstowe SCN też by obleciały, ale mają trochę ograniczeń i nie mogłyby być edytowalne - szkoda zachodu, IMO). Nie lubię wynajdować kół na nowo, więc jestem za adaptacją sprawdzonych rozwiązań. Jeśli RSF jest dobrym kandydatem, to nie mam nic przeciwko. Jednak nie podejmę się implementacji w EXE. Mogę tylko coś sugerować.
Natomiast nie widzę przeszkód, żeby zrobić wyrzut z edytora do RSF. Sam edytor powinien pracować na plikach tekstowych, które są przyjazne dla człowieka i VCS typu Git. To że Maszynowe pliki SCN/INC nie są zbyt dobre do edycji, to już inna kwestia. Traktuję je jako źródło, edytor będzie zapisywał sceny po swojemu, a eksport mogę zrobić do czegokolwiek. To otwiera ciekawe możliwości, np. edycję torów Rainstedem i dekorowanie scenerii w nowym edytorze bez konieczności odpalania symulacji, mając do tego hot reloading. A gdyby pracować sektorami, i gdyby dało łączyć się tory między sektorami, to nawet całą Polskę można było zamodelować kwadrat po kwadracie ;)
Przy okazji - czy podtorze generuje Rainsted? Scala je z rzeźbą terenu?
PS. Ciekawostka: rzeźba terenu na niewielkim Zwierzyńcu składa się z ~10 tys elementów. Nie jest to najbardziej optymalny układ ani dla exe (exe scala i dzieli na sektory), ani dla edytora (bez scalania nic z tym w praktyce nie idzie zrobić). Dwoma kolejnymi węzłami o ciężkości ponadprzeciętnej ze względu na liczebność elementów, w tym trudność edycji, to drzewa i trawa. Te trzy elementy powinny być traktowane specjalnie i to już na poziomie edycji, z czego terenu na razie nie dotykam.
Ra:
--- Cytat: marcinn w 25 Września 2023, 16:32:37 ---Ja się nie wypowiem w kwesti adaptacji RSF w EXE.
--- Koniec cytatu ---
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".
--- Cytat: marcinn w 25 Września 2023, 16:32:37 ---Sam edytor powinien pracować na plikach tekstowych, które są przyjazne dla człowieka i VCS typu Git.
--- Koniec cytatu ---
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).
--- Cytat: marcinn w 25 Września 2023, 16:32:37 ---Przy okazji - czy podtorze generuje Rainsted? Scala je z rzeźbą terenu?
--- Koniec cytatu ---
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.
Nawigacja
[#] Następna strona
Idź do wersji pełnej