Autor Wątek:  Edytor Scenerii  (Przeczytany 11445 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Edytor Scenerii
« dnia: 06 Marca 2023, 02:24:06 »
Cześć.

W paru niedawnych wątkach traktujących pobocznie o przyszłości MaSzyny, przewinęło się stwierdzenie że symulatorowi brakuje scenerii, a to głównie przez poziom skomplikowania narzędzi edytorskich. Kilka miesięcy temu, w jakiejś tam rozmowie z synem, uznałem podobnie - nie mieliśmy czym zrobić scenerii, a próg wejścia w obecne narzędzia okazał się zbyt wysoki i temat odpuściłem.

Zakiełkował mi wtedy pomysł zrobienia edytora do MaSzyny, a że proste to nie będzie, i że mam tam jakieś doświadczenie w developerce i różnych projektach, i biorąc pod uwagę dość ograniczony czas na zabawę, to założyłem że twórcy edytora muszą skupić się na mięchu a nie programowaniu kontrolek UI albo 3D. Na to nie ma po prostu czasu i zasobów. Pisanie w C(++) nie kalkuluje się - szczególnie do projektu edytora, bo to nie silnik symulatora który ma być jakoś super optymalny. Założyłem też, że edytor musi być multiplatformowy, co samo w sobie staje się pewnym wyzwaniem.

Ponieważ amatorsko interesuję się gamedevem (ścieżka kariery, którą ostatecznie nie poszedłem bo łatwiej było zarobić na tabelkach dla biznesu), jestem zwolennikiem opensource, lubię MaSzynę ponad inne symulatory (kolega EU40 pisze o jakiejś "magii" i wydaje mi się, że go rozumiem), no i przyszedł w końcu kryzys wieku średniego, to zacząłem kręcić się wokół niespełnionych ambicji młodości, czyli wokół narzędzi do gamedevu (w międzyczasie zbierając złom na pulpit do MaSzyny). Przeszedłem przez Unity, Unreal Engine, przyglądałem się samym silnikom oraz wynalazkom typu Bevy (w Rust), a do poduszki czytałem o OpenGL. W tej podróży przewijał się ciągle, trochę na zasadzie love-hate, wieloplatformowy silnik/edytor opensource - Godot (https://godotengine.org/).

Macałem Godota (!) w różnych kontekstach i z różnymi pomysłami. Zachłysnąłem się możliwościami współczesnego gamedevu, gdzie mogłem skupić się na mięchu a nie mapowaniu rysunków na trójkąty, mając jednocześnie otwarte źródła do ewentualnego spatchowania renderera wg potrzeb. Przemknął mi oczywiście irracjonalny pomysł "przepisania MaSzyny na [wpisz nazwę ulubionego engine]", ale znam trochę exe Symulatora i wiem że w fizyce dzieje się sporo. Wiem, jak czasem niektóre rozwiązania z wielu warstw są od siebie mocno zależne. Zrozumiałem siłę customowego renderera (bo gotowce, mimo cudów na kiju, wbrew pozorom mogą być ograniczone, zbyt generyczne, i bez patchowania niekoniecznie optymalne do tego zadania), jego lekkości, w tym czasu kompilacji. Pomysł "przepisania" MaSzyny, nawet jako wieloosobowy projekt, ostatecznie skreśliłem - nie miałby szans na powodzenie przede wszystkim dlatego, że nie wnosiłby niczego nowego poza PBR (do którego konwersja byłaby raczej czasochłonna), IK, łatwiejszym skryptowaniem, poukładanym kodem (z nowymi chorobami wieku dziecięcego), i może jeszcze jakimiś kilkoma pierdołami.

Siłą MaSzyny jest content, fizyka, swoboda konfiguracji i eksploatacji symulatora, pomieszana ze wspomnianą magią oraz podlana otwartymi źródłami, które tworzą społeczność. A jak wiemy, społeczność ma problem z dostarczaniem contentu. I tym sposobem docieramy do zamysłu projektu, który chciałbym nazwać ogólnie Edytorem MaSzyny, a którego realizację chciałbym zaproponować narzucić z użyciem Godot Engine. Jednym z problemów jest nasz czas, a właściwie jego deficyt - mamy go za mało na projekty poboczne, dlatego gotowiec w wielu aspektach nas wyręczy. A że nie jest to engine dla samego Symulatora, to nie powinno mieć dla nikogo znaczenia czy ma jakąś funkcję czy nie, czy go ktoś lubi czy też nie. Celem jest budowa narzędzia lub wielu narzędzi do Symulatora.

Ale że robić edytor do gry w edytorze gier? Dokładnie. I nie jest to wyjątek (vide Material Maker i inne). Godot ma pewną unikalną cechę w porównaniu do innych silników - ma świetnie zrealizowane, współgrające ze sobą 2D i 3D, gdzie dla 2D jest cały zestaw komponentów dla UI. Zapewnia wieloplatformowość, renderer 3D, rozszerzalność i wygodne mechanizmy tworzenia narzędzi (w tym pluginów samego edytora), wygodny hierarchiczny system scen i węzłów, skryptowy język do szybkiego prototypowania GDScript (czerpiący z Pythona garściami), i szereg pierdół ułatwiających pracę nad narzędziem. Do tego jest opensource, na licencji MIT (żadnego bulenia korporacjom), i odpali się nawet na Androidzie (nie wiem po co, ale sportowali go na Andka - ponoć ktoś tego używa w podróży pociągiem). Niewątpliwą zaletą jest też to, że można zacząć dłubać narzędzie niekoniecznie znając algebrę (do tej pory łamię sobie głowę na kwaternionach, a coś tam mimo tego wychodzi). Czyli próg wejścia jest stosunkowo niski, a system operacyjny programistów i późniejszych użytkowników nie będzie miał znaczenia (można nawet próbować wydać build w WebGL i odpalać edytor w przeglądarce).

Czego nie ma na teraz Godot? Nie czyta plików MaSzyny (E3D, SCN, itd), oraz nie obsługuje DDS-ów w runtime (importer obsługuje, ale nas interesuje runtime). Te pierwsze da się ogarnąć w formie pluginu do Godota, czego jakiś tam prototyp mam i wsysam sobie testowo obiekty z MaSzyny. To drugie (DDS) będzie wkrótce obsługiwane w upstreamie (moje patche czekają na merge, bo dostały względnie niski priorytet). Czyli narzędzie do budowy narzędzia jest niemal gotowe do użycia.

Po co piszę post zamiast robić ten edytor w tym tak wspaniałym narzędziu? Doskonale zdaję sobie sprawę, że sam tego nie pociągnę. A nawet jeśli pociągnę, to zakładając że nie umrę ze zgryzoty lub nie wpadnę pod pociąg, projekt musi spotkać się z zainteresowaniem społeczności MaSzyny. Choćby dlatego, żeby ktoś inny mógł prowadzić rozwój edytora dalej, oraz żeby sami twórcy contentu byli zainteresowani modernizacją swojej narzędziowni. Żeby to wszystko zadziałało, musielibyśmy mieć określoną ogólną wizję przyszłości Symulatora, którą wg mnie przede wszystkim jest content. Dopiero później, kiedy Edytor już coś tam mógłby zmieniać, można byłoby zacząć pochylać się nad usprawnieniami exe/renderera, który mógłby zacząć pozwalać na np. heightmapy, automayczne sianie trawska, splatmapy i inne cuda na kiju, które Edytor Scenerii wspierałby na bieżąco wraz z rozwojem EXE.

Tak sobie wyobrażam rozwój Symulatora. Tyle ode mnie tej nocy. Pozdrawiam.
Marcin


« Ostatnia zmiana: 06 Marca 2023, 02:31:06 wysłana przez marcinn »

Offline matek123

  • Moderator
  • Wiadomości: 6176
    • Zobacz profil
  • Otrzymane polubienia: 2112
Odp: Edytor Scenerii
« Odpowiedź #1 dnia: 06 Marca 2023, 18:36:27 »
nie obsługuje DDS-ów w runtime (importer obsługuje, ale nas interesuje runtime). Te pierwsze da się ogarnąć w formie pluginu do Godota, czego jakiś tam prototyp mam i wsysam sobie testowo obiekty z MaSzyny.
Cześć. A jak tam z obsługą tga? Bo pracujemy i przechowujemy oryginały tekstur w tga. Dopiero robiąc paczkę całościową automat konwertuje do dds, który jest lżejszy, ale ma kompresję stratną.
Poszukuję zdjęć na tekstury pociągów sieciowych. Szczególnie platform z pomostami.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #2 dnia: 06 Marca 2023, 19:47:08 »
TGA jest obsługiwane także w runtime. Czy w runtime - dopiero potwierdzę, ale nawet jak nie, to się przerobi.

Można też myśleć o użyciu edytora do konwersji między formatami - API jest bogate i czytelne. W razie czego - jest interfejs do robienia rozszerzeń w C++, a jeśli tego będzie mało a zmiana sensowna dla nich,  to się puści PR do upstreama.

Long story short - nie przejmowałbym się tym. Wyzwaniem będzie edycja dużych scen i trzeba będzie zrobić chunking.
« Ostatnia zmiana: 06 Marca 2023, 22:33:43 wysłana przez marcinn »

Offline Sm 42 driver

  • Wiadomości: 320
  • Trasopisarz
    • Zobacz profil
  • Otrzymane polubienia: 70
Odp: Edytor Scenerii
« Odpowiedź #3 dnia: 07 Marca 2023, 21:36:25 »
W paru niedawnych wątkach traktujących pobocznie o przyszłości MaSzyny, przewinęło się stwierdzenie że symulatorowi brakuje scenerii, a to głównie przez poziom skomplikowania narzędzi edytorskich. Kilka miesięcy temu, w jakiejś tam rozmowie z synem, uznałem podobnie - nie mieliśmy czym zrobić scenerii, a próg wejścia w obecne narzędzia okazał się zbyt wysoki i temat odpuściłem.

Zakładam, że mowa tutaj o Rainstedzie, który pozwala na odwzorowanie torów zgodnie z rzeczywistymi zasadami ich budowy. Niestety, żeby nie wyszedł rollercoaster czy rzucanie na łukach o ścianę to twórca powinien zaznajomić się chociażby z podstawowymi zasadami projektowania linii kolejowych, np. po co stosuje się przechyłki, krzywe przejściowe, jakie mamy minimalne promienie łuków poziomych w zależności od maksymalnej prędkości itd. I mówię teraz zarówno o sceneriach realnych jak i fikcyjnych. Być może jako inżynier przyzwyczaiłem się już do możliwości jakie daje Rainsted. Ale właściwie w kontekście propozycji nowego edytora to zmierzam do pytania: czy zakładasz jakieś uproszczenia (i jakie) w stosunku do obecnie stosowanych narzędzi? Domyślam się, że na tym etapie ciężko szczegółowo odpowiedzieć na to pytanie ale chociaż nakreśl założenia. Osobiście, jako twórca, z dużą rezerwą patrzę na sytuację, w której osiągnęliśmy pewien poziom dokładności oferowany przez narzędzia edytorskie a następnie będziemy iść w uproszczenia czyli wrócimy do czasów przed powstaniem/wykorzystaniem obecnie stosowanych narzędzi.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #4 dnia: 08 Marca 2023, 01:28:38 »
Osobiście, jako twórca, z dużą rezerwą patrzę na sytuację, w której osiągnęliśmy pewien poziom dokładności oferowany przez narzędzia edytorskie a następnie będziemy iść w uproszczenia czyli wrócimy do czasów przed powstaniem/wykorzystaniem obecnie stosowanych narzędzi.

Cieszę się, że poruszyłeś te aspekty. Zakładam podejście, które chyba zbyt słabo zaznaczyłem w pierwotnym tekście:
  • EXE oraz pliki zachowają dotychczasową funkcjonalność - żadnych cięć i wywrotek formatów.
  • Uproszczeniu ma być poddane UI oraz UX - krótko mówiąc chodzi o zwiększenie wygody użytkowania (edytowania).
  • Wydaje mi się, żę wyeliminowanie przełączania się między edytorami zależnie czy robisz trasy, czy układasz scenerię, będzie plusem
  • Zanim zostanie napisana linijka kodu, chciałbym zrobić konsultacje z docelowymi użytkownikami, zebrać wiedzę jak pracują i jakie mają problemy
  • Wiedzę dziedzinową chciałbym pozyskiwać od specjalistów, lub (jeśli będą chcieli) zaprosić ich do programowania

Mając nowy codebase edytora będzie możliwość dobudowywania usprawnień. Przykład: podobno mozolne jest obsiewanie trawy. Jeśli exe nie będzie wspierał proceduralnego generowania zielonego, to edytor może zawierać odpowiednie funkcje załatwiające temat jednym klikiem.

Wy powinniście się skupić na mięchu - na odwzorowaniu przebiegu linii. Dekoracje powinny być robione automatycznie, półautomatycznie lub przez miłośników dekorowania scenerii. Dodasz wielokąt o nazwie "las", i na scenerii w tym miejscu pojawi się wygenerowany las (czy to będą płaszczyzny czy drzewka - to już do ustalenia).

A jeśli można byłoby jakoś usprawnić (-> skrócić czas) opracowywania linii, biorąc pod uwagę workflow jaki stosujecie, to byłoby już całkiem świetnie. W tym zakresie mam najmniejszą wiedzę. Wiem jak to wygląda w plikach, w formie literek i cyferek, ale jak pracujecie i z czym walczycie - nie.

Chciałbym też zaznaczyć, że projekt musi mieć jasno określone założenia, które będą musiały być pilnowane. Żadnych hype, ucieczek w bok - reżim twórczy mozolnie prowadzący do celu. Tak jak w b2b realizujesz oprogramowanie wg potrzeb biznesowych a nie swojego widzimisię, tak tu realizujesz soft na potrzeby specjalistów dziedzinowych.

PS. Ponieważ zakładamy pełną kompatybilność plików z danymi, to zamienne używanie Rainsteda będzie możliwe, dopóki ktoś nie zrobi zmian w EXE za którymi Rainsted nie pójdzie.

Offline Toprus

  • Deweloper
  • Wiadomości: 234
  • peprus
    • Zobacz profil
  • Otrzymane polubienia: 616
Odp: Edytor Scenerii
« Odpowiedź #5 dnia: 08 Marca 2023, 08:11:12 »
Jako osoba aktywnie biorąca udział w tworzeniu scenerii, wtrącę kilka przemyśleń od siebie co do tematu:
-jedną z najbardziej żmudnych i nieproporcjonalnie niewygodnych części tworzenia scenerii realistycznych jest układanie, a zwłaszcza poziomowanie dróg dla samochodów. Najwygodniejszą opcją byłaby możliwość chwytania punktów na drodze w jakimś edytorze z widokiem 3D, do którego da się wczytać docelowy teren i możliwość przesuwania tych punktów samemu w osi góra-dół z widokiem na wszystko. Ta opcja byłaby też fajna do torów, chociaż tutaj podchodzę już trochę bardziej sceptycznie. Takie coś mogłoby istnieć jako osobny programik.
-Rainsted (stety lub niestety) jest edytorem prawie idealnym, ale tym, co go od ideału dzieli, jest dosyć przytłaczający interface. Jest to tak na prawdę jedyna rzecz, która mogłaby ulec zmianie, bo zakres możliwości i precyzja, jaką oferuje, są niezastąpione.
"Jestem ToPrusem i nic co pruskie nie jest mi obce." - Terencjusz

Obiekty statyczne i dekoracje dla scenerii <3

Offline JAN21

  • Deweloper
  • Wiadomości: 500
  • Tory se robie se
    • Zobacz profil
  • Otrzymane polubienia: 1488
Odp: Edytor Scenerii
« Odpowiedź #6 dnia: 08 Marca 2023, 09:42:56 »

PS. Ponieważ zakładamy pełną kompatybilność plików z danymi, to zamienne używanie Rainsteda będzie możliwe, dopóki ktoś nie zrobi zmian w EXE za którymi Rainsted nie pójdzie.
Temat nie osiągalny. Rainsted korzysta ze swojego formatu plików roboczych. Trzeba albo napisać Ry na nowo, albo zarzucić temat torów i wszystkiego co z nimi powiązane, na rzecz bardziej potrzebnych rzeczy tj. Drogi, export SBT czy zalesianie.

UI w Rainstedzie to myślę że jest kwestia do dogadania z @Ra. Tylko niech ktoś (kto nie ma wyklikanego 1000 godzin, bo mi to tam wszystko jedno) opracuje jakiś OP interfejs
Dobrowolne wsparcie: Tipply

Offline MP5

  • Wiadomości: 73
    • Zobacz profil
  • Otrzymane polubienia: 28
Odp: Edytor Scenerii
« Odpowiedź #7 dnia: 08 Marca 2023, 12:02:09 »
Niestety, żeby nie wyszedł rollercoaster czy rzucanie na łukach o ścianę to twórca powinien zaznajomić się chociażby z podstawowymi zasadami projektowania linii kolejowych, np. po co stosuje się przechyłki, krzywe przejściowe, jakie mamy minimalne promienie łuków poziomych w zależności od maksymalnej prędkości itd. I mówię teraz zarówno o sceneriach realnych jak i fikcyjnych.

Głupie pytanie, a nie dało by się tego jakoś zautomatyzować, nawet w pewnym uproszczeniu? Wyobrażam sobie to tak, że edytor pozwalałby na ustalenie odpowiednich parametrów łuku w zależności od prędkości jaką chce mieć osoba tworząca scenerię lub odwrotnie - użytkownik kładzie tor a program określa na podstawie tego jaka jest możliwa Vmax. To samo z przechyłkami

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #8 dnia: 08 Marca 2023, 12:03:37 »
Temat nie osiągalny. Rainsted korzysta ze swojego formatu plików roboczych.

Dzięki za informacje.  Czyli Rainsted nie potrafi otwierać SCN? Bo próbowałem to robić i nie udało mi się.

Cytuj
UI w Rainstedzie to myślę że jest kwestia do dogadania z @Ra. Tylko niech ktoś (kto nie ma wyklikanego 1000 godzin, bo mi to tam wszystko jedno) opracuje jakiś OP interfejs

Część rzeczy usprawnisz, ale całkowite ulepszenie jest awykonalne. To są komponenty UI i środowisko Win32 ze swoimi ograniczeniami, których Ra nie przeskoczy. Musialby budować lub znaleźć zupełnie nowy toolkit UI, ale zakładam że kod programu jest bardzo mocno powiązany z tymi konkretnymi kontrolkami (bo tak się zazwyczaj pisze te softy). Rainsted nie jest multiplatformowy, a tego w zastosowanym środowisku nie zmienisz.

A co z tworzeniem narzędzia przez społeczność? Czy Rainsted jest opensource i możemy coś usprawniać lub posiłkować się zastosowanymi rozwiązaniami?

-Rainsted (stety lub niestety) jest edytorem prawie idealnym, ale tym, co go od ideału dzieli, jest dosyć przytłaczający interface.

To jest rzeczywiście skomplikowany i dobry soft, z rzeczywiście dość złożonym UI. Oglądałem trochę filmików i widzę że nawet jak się robi proste odcinki, to jest dużo klikania i robienia operacji, które można byłoby skrócić. Pewne rzeczy są nieintuicyjne, oraz trzeba mieć mocną wiedzę dziedzinową żeby choćby wiedzieć co kliknąć. Poza intuicyjnością w sztuce projektowania dobrych interfejsów istnieje pojęcie "sane defaults". Chodzi o to, żeby te 80% powtarzalnych rzeczy szło jak po maśle (bo domyślne zachowanie i wartości są dobre), a te 20% wymagało dostrajania.


EDIT: Jeszcze jedno pytanie, i wydaje mi się że ważne.

Jeśli chodzi o odcinki to opieram się na strukturze https://wiki.eu07.pl/index.php/Obiekt_node::track
Wiem już, że Rainsted ma swoje pliki robocze.
Czy w tych plikach roboczych Rainsteda zawarte są informacje, których nie ma już w node::track, a które są Wam potrzebne do pracy ze scenerią? Jakiś przykład?
« Ostatnia zmiana: 08 Marca 2023, 12:23:37 wysłana przez marcinn »

Offline JAN21

  • Deweloper
  • Wiadomości: 500
  • Tory se robie se
    • Zobacz profil
  • Otrzymane polubienia: 1488
Odp: Edytor Scenerii
« Odpowiedź #9 dnia: 08 Marca 2023, 12:45:50 »
Temat nie osiągalny. Rainsted korzysta ze swojego formatu plików roboczych.
Dzięki za informacje.  Czyli Rainsted nie potrafi otwierać SCN? Bo próbowałem to robić i nie udało mi się.

Potrafi ale jest to bardzo ułomne a na dodatek traci się bardzo ważne elementy pomocnicze (niwelety, parametry łuków).

Cytuj
Jeśli chodzi o odcinki to opieram się na strukturze https://wiki.eu07.pl/index.php/Obiekt_node::track
Wiem już, że Rainsted ma swoje pliki robocze.
Czy w tych plikach roboczych Rainsteda zawarte są informacje, których nie ma już w node::track, a które są Wam potrzebne do pracy ze scenerią? Jakiś przykład?

Jak wyżej: niwelety z hektometrami i załomami, linie kierunkowe, oraz parametry łuku określające krzywe przejściowe i przechyłki. Importując scny do Ry tracimy praktycznie najważniejsze dane.
Dobrowolne wsparcie: Tipply

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #10 dnia: 08 Marca 2023, 13:20:58 »
Jak wyżej: niwelety z hektometrami i załomami, linie kierunkowe, oraz parametry łuku określające krzywe przejściowe i przechyłki. Importując scny do Ry tracimy praktycznie najważniejsze dane.

Dzięki. Wiem już więcej i już rozumiem ideę. Rainsted pełni rolę nie tyle edytora SCN, co generatora SCN (Rainsted edytuje swoje pliki). EDIT: A nawet nie tylko SCN, bo ma eksport do różnych symulatorów.

EDIT: Pytanie pomocnicze - czy niwelety z hektometrami, albo linie kierunkowe, są potrzebne dla dróg i rzek? Oglądałem video, gdzie robiona jest droga i twórca musi ręcznie nastawiać odcinkom drogi jakieś kody szesnastkowe, nastawiać tekstury i korygować wysokość na przechyłce, bo się asfalt źle renderuje. Nie jest to przekombinowane?
« Ostatnia zmiana: 08 Marca 2023, 15:13:13 wysłana przez marcinn »

Offline JAN21

  • Deweloper
  • Wiadomości: 500
  • Tory se robie se
    • Zobacz profil
  • Otrzymane polubienia: 1488
Odp: Edytor Scenerii
« Odpowiedź #11 dnia: 08 Marca 2023, 14:46:31 »
Jak wyżej: niwelety z hektometrami i załomami, linie kierunkowe, oraz parametry łuku określające krzywe przejściowe i przechyłki. Importując scny do Ry tracimy praktycznie najważniejsze dane.

Dzięki. Wiem już więcej i już rozumiem ideę. Rainsted pełni rolę nie tyle edytora SCN, co generatora SCN (Rainsted edytuje swoje pliki).

EDIT: Pytanie pomocnicze - czy niwelety z hektometrami, albo linie kierunkowe, są potrzebne dla dróg i rzek? Oglądałem video, gdzie robiona jest droga i twórca musi ręcznie nastawiać odcinkom drogi jakieś kody szesnastkowe, nastawiać tekstury i korygować wysokość na przechyłce, bo się asfalt źle renderuje. Nie jest to przekombinowane?

Rzeki niechaj ci głowy nie zaprzątają, powstają razem z terenem a ich przyszłość w formacie node track jest mocno dyskusyjna. Niewidzialne mogą posłużyć za ścieżki po których mają pływać łódki, statki czy coś podobnego.

Dla dróg nie ma potrzeby praktycznie niczego ponad to co zawiera wpis node track. Ważne żeby dało się dzielić, przemieszczać w pionie i ustawiać przechyłkę.

Ewentualnie można napisać drogi na nowo wzorując się na jakimś ETSie czy Omsi.
Dobrowolne wsparcie: Tipply

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6321
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 354
Odp: Edytor Scenerii
« Odpowiedź #12 dnia: 19 Marca 2023, 14:17:08 »
Czyli Rainsted nie potrafi otwierać SCN? Bo próbowałem to robić i nie udało mi się.
Rainsted ma dwa edytory. Edytor SCN wczytuje pliki MaSzyny, a następnie tworzy obiekty powiązane z fragmentami tekstu w plikach — obiekty te można modyfikować, a one następnie będą generować odpowiednie formy tekstowe. Edytor RSF obsługuje własne pliki, w których na każdy obiekt jest przeznaczone 128 bajtów — dzięki zapisaniu wskaźników nie ma potrzeby wykrywać powiązań, nieobecnych w SCN. Istnieją algorytmy konwersji danych SCN na RSF, natomiast z RSF plik SCN jest generowany tekstowo. Są też operacje posługujące się obydwoma formatami, np. można otworzyć plik torów SCM i korygować w nim pojedyncze tory, przesyłając je z edytora RSF (gdzie można poprawić geometrię). Mam też warstwę wyższego poziomu (służy obecnie do generowania skryptów sterujących ruchem) — widzi ona odcinki torów w sposób niezależny od tego, czy są one wczytane z SCM, czy RSF.

Musialby budować lub znaleźć zupełnie nowy toolkit UI, ale zakładam że kod programu jest bardzo mocno powiązany z tymi konkretnymi kontrolkami (bo tak się zazwyczaj pisze te softy). Rainsted nie jest multiplatformowy, a tego w zastosowanym środowisku nie zmienisz.
Starałem się, aby algorytmy edytora nie były powiązane z oknem edycyjnym, mając na uwadze zrobienie kiedyś innego okna edycyjnego. Natomiast przepisywanie Rainsted na inną bazę kodu uważam za przerost formy nad treścią, która zajmie mi czas. Natomiast jeśli będzie zapotrzebowanie na używanie Rainsted, to będę taką opcję rozważał.

A co z tworzeniem narzędzia przez społeczność? Czy Rainsted jest opensource i możemy coś usprawniać lub posiłkować się zastosowanymi rozwiązaniami?
Niezbyt wierzę w tworzenie edytora przez społeczność — gdyby coś takiego miało powstać, było 20 lat na to. Do mnie czasem są zgłaszane uwagi i jeśli uda mi się zrozumieć, co autor miał na myśli, to staram się to zrealizować. Rainsted nie jest opensource i przynajmniej na razie nie widzę takiej potrzeby, a jest ryzyko wyssania moich rozwiązań.

To jest rzeczywiście skomplikowany i dobry soft, z rzeczywiście dość złożonym UI. Oglądałem trochę filmików i widzę że nawet jak się robi proste odcinki, to jest dużo klikania i robienia operacji, które można byłoby skrócić. Pewne rzeczy są nieintuicyjne, oraz trzeba mieć mocną wiedzę dziedzinową żeby choćby wiedzieć co kliknąć. Poza intuicyjnością w sztuce projektowania dobrych interfejsów istnieje pojęcie "sane defaults". Chodzi o to, żeby te 80% powtarzalnych rzeczy szło jak po maśle (bo domyślne zachowanie i wartości są dobre), a te 20% wymagało dostrajania.
Rainsted jest robiony pod kątem ustalenia algorytmów, co trzeba zrobić, żeby w ogóle się to dało zrobić. Np. niedawno dopiero dopracowałem kwestię wysokości obiektów na łukach pionowych, a przede mną są jeszcze łuki koszowe i podział krzywych przejściowych na odcinki. Plus jeszcze przebudowa mocowań sieci trakcyjnej. Gdybym z góry wszystko wiedział, co jak ma być zrobione, to bym się skupił na wyglądzie, a póki co wciskam kontrolki w miarę potrzeby. Pewnym problemem edytora jest "składanie z klocków", podczas gdy powinno się zacząć od naniesienia sieci kolejowej, wpisania parametrów linii, następnie wyginania szlaku i wstawiania miejsc szczególnych, a "podział na klocki" powinien być ostatnim etapem...

Czy w tych plikach roboczych Rainsteda zawarte są informacje, których nie ma już w node::track, a które są Wam potrzebne do pracy ze scenerią? Jakiś przykład?
Odpowiednik w formacie RSF ma wskaźnik do odcinka niwelety, ów odcinek niwelety pozwala odnaleźć numer linii, a na podstawie numeru linii można zweryfikować nazewnictwo urządzeń, poza tym niweleta ma przypisany profil pionowy, który można pobrać albo porównać z bazą danych. Odcinki torów w RSF są również połączone logicznie w listy dwukierunkowe. Poza tym, każdy odcinek toru może mieć wskaźnik na obiekt pilnujący geometrii, np. linię kierunkową, obiekt parametrów łuku nadzorujący krzywe przejściowe, albo krzywą pomocniczą, po której powinien przesuwać się punkt łączenia odcinków toru. Podział toru na odcinki może wynikać z bardzo wielu kontekstów, np. zmiana geometrii (w planie lub profilu), inna podsypka, rozdzielenie izolacji, punkt wstawienia taboru, ograniczenie prędkości.

EDIT: Pytanie pomocnicze - czy niwelety z hektometrami, albo linie kierunkowe, są potrzebne dla dróg i rzek? Oglądałem video, gdzie robiona jest droga i twórca musi ręcznie nastawiać odcinkom drogi jakieś kody szesnastkowe, nastawiać tekstury i korygować wysokość na przechyłce, bo się asfalt źle renderuje. Nie jest to przekombinowane?
Teoretycznie, gdyby robić symulator pływania barką, to rzeki mają również kilometraż, aczkolwiek tu głównym czynnikiem jest zmiana wysokości wody. ;) Zmiana kodów szesnastkowych (warstwy) była pewnie robiona dla peronów, które są obsługiwane jako warstwa z wyjątkiem w postaci wysokości ponad niweletę. Obecnie warstwę dróg powinno się dać zmienić z listy rozwijalnej, jeśli ktoś tak preferuje. Szesnastkowe kody obiektów są awaryjną metodą zmiany typu obiektu, co może być przydatne w bardzo rzadkich przypadkach. Co do zasady drogi mają 16 warstw i dla każdej jest osobny zestaw tekstur (aby np. nie mieszać tekstur peronów razem z drogami polnymi). Co do renderowania dróg, to w 2014 planowałem zrobić do MaSzyny automatyczne sklejanie dróg z terenem poprzez nasyp o odpowiedniej wysokości i zadanym pochyleniu...
¯\_( ͡° ͜ʖ ͡°)_/¯ Ra

Polecam: kręgarz Wojciech Walczak, projekt masarni

Offline bve2

  • Wiadomości: 195
    • Zobacz profil
    • http://www.admineu07.prv.pl
  • Otrzymane polubienia: 35
Odp: Edytor Scenerii
« Odpowiedź #13 dnia: 06 Maja 2023, 22:57:53 »
Do tej pory nie powstal edytor jak w Trainz , gdzie jedno narzedzie pozwala na stworzenie trasy w calosci. Dla mnie najwieksza bolaczka jest dekorowanie otoczenia. Brakuje niestety wielu modeli , jak chocby kladek modulowych , obecne nie nadaja sie do zastosowania na trasie Bieszczady/Galicja. Po co zamienac w Excelu jakies komendy? Czy Edytor nie moglby tego robic od razu? To mi sie marzy - otwieram edytor ,wczytuje scenerie i dzialam z otoczeniem jednym narzedziem . Pod tym wzgledem Trainz nie ma sobie rownych  - dlatego jest taka mnogosc tras i ciagle powstaja nowe - w Maszynie jedna trasa powstaje 4 - 5 lat....

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1560
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1214
Odp: Edytor Scenerii
« Odpowiedź #14 dnia: 07 Maja 2023, 02:21:44 »
Niestety, priorytetem wydają się rzeczy głównie niespotykane w innych symulatorach, czyli krzywe przejściowe i przechyłki. Jeżeli chodzi o MaSzynę, Rainsted ma w tej kwestii monopol, a zamknięty kod źródłowy powoduje, że napisanie podobnego narzędzia i rozgryzienie wszystkich rzeczy samemu zajmie obłędną ilość czasu. Ja osobiście byłbym za prostym edytorem, w którym nawet nie byłoby ani edycji terenu, ani krzywych przejściowych, ani przechyłek, ale żeby po prostu był. Jeżeli tylko będzie prosty w obsłudze, z automatu powstanie gigantyczna ilość scenerii fikcyjnych do przejechania. A osoby, które chcą jeździć po realnych sceneriach z profilem pionowym i krzywymi przejściowymi też nic nie stracą, ponieważ dotychczasowe skomplikowane narzędzia dalej będą istniały.

Stworzymy w ten sposób swego rodzaju oddzielną scenę, w której będzie dużo scenerii nieco gorszej jakości, ale za to z dobrym otoczeniem, jeżeli jego układanie będzie przyjemne. Takie osoby będą miały już wprawę, a edytor mógłby powoli ewoluować, wzbogacając się o kolejne funkcje. Wbudowany w exe edytor miał taką szansę, ale jest toporny w obsłudze, ma mało funkcji (brakuje tych wręcz oczywistych, jak podświetlanie zaznaczonego obiektu) oraz został kompletnie porzucony i nie jest rozwijany.

Moje podejście do edytora już znacie:
Pomysł prostego i przystępnego edytora scenerii jak najbardziej ma sens. Można nawet zrezygnować z niezbędnych w pełnym edytorze funkcji, gdyż te dalej by były dostępne w Rainstedzie. Chodzi tu o aplikację, za pomocą której użytkownik będzie w stanie poznać i zastosować podstawowe pojęcia, którymi posługują się twórcy scenerii. Programu, w którym można by się sprawdzić. Czy jestem w stanie stworzyć scenerię? Jak dobrze mi to idzie? 5 lat później, hmm, ten edytor już obcykałem, może bym się przesiadł na bardziej zaawansowanego Rainsteda? Takie rozwiązanie spłaszczyłoby learning curve w budowie scenerii i mogłoby zachęcić potencjalnych trasopisarzy do zabawy z symulatorem. W Scratchu nie da się zrobić gry na poziomie Cyberpunka, a mimo to korzystają z niego miliony ludzi.

Jak widać, różni się ono w porównaniu do poglądów innych osób. Dlatego jestem otwarty na dyskusję. Też byłbym zainteresowany pracą nad edytorem, aczkolwiek nie w najbliższym czasie (dużo innych projektów na głowie). Jeżeli nastąpi wspólny konsensus w sprawie edytora i jednoznacznie ustalimy kierunek działań, będziemy w stanie zrobić jeden edytor szybciej.

Na koniec dodam, że Balaclava również pracuje nad edytorem scenerii.
« Ostatnia zmiana: 07 Maja 2023, 02:34:58 wysłana przez jakubg1 »
10 lat na forum MaSzyny!

Offline trzecia_bateria

  • Wiadomości: 48
    • Zobacz profil
  • Otrzymane polubienia: 43
Odp: Edytor Scenerii
« Odpowiedź #15 dnia: 07 Maja 2023, 10:24:11 »
Dołożę swoje 0.03$ z perspektywy zwykłego, szarego usera. Usera, który póki co tylko jeździ, ale może gdzieś, kiedyś coś by sobie "poedytował".
Cytuj
Ja osobiście byłbym za prostym edytorem, w którym nawet nie byłoby ani edycji terenu, ani krzywych przejściowych, ani przechyłek, ale żeby po prostu był
Prosty edytor, z prostymi funkcjami de facto stworzy (ewentualnie na amen zabetonuje już istniejący) standard maszynowych scenerii- prostych, płaskich naleśników z mało realnym układem torowym. Chyba jestem trochę rozpieszczony Bieszczadami albo nową L61, ale moim zdaniem, to właśnie powinien być nowy standard. Pozornie głupia rzecz, jaką jest profil pionowy, diametralnie zmienia przyjemność z prowadzenia pociągu. Nie nadrobi się tego ciekawą dekoracją.
Rainsted być może jest skomplikowany, mój kontakt z jego funkcjami edycyjnymi jest skromny. Ale to skomplikowanie daje możliwości. Blender tudzież Gimp też są skomplikowane, też właściwie użyte dają super efekty, jednak nie ma tutaj głosów, aby pierwszego zastąpić chociażby jakimś Sketchup-em a drugiego windowsowym Paintem.

Offline Toprus

  • Deweloper
  • Wiadomości: 234
  • peprus
    • Zobacz profil
  • Otrzymane polubienia: 616
Odp: Edytor Scenerii
« Odpowiedź #16 dnia: 07 Maja 2023, 10:49:24 »
Popieram jednak bve2 pod tym względem, że największą bolączką scenerii jest dekorowanie. Spostrzeżcie, że tak na prawdę, położenie 200km torów w Rainstedzie dla wprawionego użytkownika jest robotą na max tydzień i jest wiele osób, które bez problemu by coś takiego dla kogoś innego wykonały. Scenerie (te realistyczne, bądź nie) rozbijają się głównie na terenie (którego obróbkę aktualnie ogarniają może 3 osoby) oraz na dekoracjach.

Inną sprawą jest to, że może część użytkowników jest niechętna, aby cokolwiek zrobić? Nasza Galicja to w praktyce, w połączeniu z Zakopianką, kilkaset kilometrów szlaku, gotowych zaspokoić potrzeby użytkowników (są dwu- i jednotorowe, z drutem i bez), ale brakuje osób chętnych do podjęcia się dekorowania, pomimo, że edytor F11 jest banalnie prosty i nie ma tutaj mowy o żadnym learning curve. Wejść i zacząć się nim bawić może każdy, a kwestią do wyuczenia po prostu jest to, jak dekorować, żeby było ładnie. Wspomniany Excel jest potrzebny na absolutnie końcowym etapie tworzenia, a w trakcie prac wszystko można wykonywać wyłącznie przy użyciu notatnika. Tutaj fakt, że dałoby się wprowadzić jakieś ułatwienia, ale i tak nie jest to jakiś dramat. Chodzi wyłącznie o skopiowanie zawartości jednego pliku do innego.
« Ostatnia zmiana: 07 Maja 2023, 10:50:58 wysłana przez Toprus »
"Jestem ToPrusem i nic co pruskie nie jest mi obce." - Terencjusz

Obiekty statyczne i dekoracje dla scenerii <3

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1560
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1214
Odp: Edytor Scenerii
« Odpowiedź #17 dnia: 07 Maja 2023, 12:25:53 »
Prosty edytor, z prostymi funkcjami de facto stworzy (ewentualnie na amen zabetonuje już istniejący) standard maszynowych scenerii- prostych, płaskich naleśników z mało realnym układem torowym. Chyba jestem trochę rozpieszczony Bieszczadami albo nową L61, ale moim zdaniem, to właśnie powinien być nowy standard. Pozornie głupia rzecz, jaką jest profil pionowy, diametralnie zmienia przyjemność z prowadzenia pociągu. Nie nadrobi się tego ciekawą dekoracją.
Rainsted być może jest skomplikowany, mój kontakt z jego funkcjami edycyjnymi jest skromny. Ale to skomplikowanie daje możliwości. Blender tudzież Gimp też są skomplikowane, też właściwie użyte dają super efekty, jednak nie ma tutaj głosów, aby pierwszego zastąpić chociażby jakimś Sketchup-em a drugiego windowsowym Paintem.
Z jednej strony tak, jednak z drugiej skomplikowanie narzędzi jest obecnie zbyt duże, żeby początkujące osoby miały jakąkolwiek szansę się wykazać. Wymaganie od nowicjusza stworzenia trasy realnej z profilem pionowym i wiernie odwzorowanym otoczeniem to jak wymaganie od pierwszoklasisty obliczania całek. Nie każdy musi jeździć sceneriami z "piaskownicy". Nie każdy będzie miał też talent. Ale prosty edytor może takie talenty odkryć, na przykład wśród osób, które obecnie nie mają konta na forum.
Edytor mógłby owszem pełnić wyłącznie funkcje dekoracyjne na początku. Ba, nawet jest przecież sceneria td i wbudowany w exe edytor! Tylko ten edytor również jest przekombinowany i listę jego wad mógłbym wymieniać bez końca. Tylko w ten sposób wracamy do miejsca "uczysz się exe i C++, to dawaj, napisz lepszy". Ech...
edytor F11 jest banalnie prosty i nie ma tutaj mowy o żadnym learning curve. Wejść i zacząć się nim bawić może każdy, a kwestią do wyuczenia po prostu jest to, jak dekorować, żeby było ładnie.
No to lecimy. Wiem, że trochę prowokuję, ale chcę pokazać, dlaczego wciąż garstka osób będzie się od tego edytora odbijać.
1. Jak można wstawić ściany lasu?
2. Jak wstawić pojedyncze drzewa?
3. Klikam (jakiś długi skrót do zapisywania zamiast Ctrl+S). Czy się zapisało? Dlaczego na ekranie nie mam potwierdzenia ani nazwy pliku?
4. Edytor mi się wysypał!!! 3 godziny pracy na marne!!! Dlaczego nie ma autozapisu?
5. Skąd mam wiedzieć, który obiekt jest obecnie zaznaczony?
6. Jak mogę precyzyjnie ustawić pozycję modelu?
7. Jak mogę zmienić tekst na tablicy peronowej ze zmiennym napisem?
8. Czy jest możliwość podglądu obiektu, zanim go wstawię?
Myślę, że tyle wystarczy. Odpowiedz sobie na te pytania w kontekście Trainza i MaSzyny, a zobaczysz, że ludzie preferują to pierwsze.
« Ostatnia zmiana: 07 Maja 2023, 12:35:51 wysłana przez jakubg1 »
10 lat na forum MaSzyny!

Offline Toprus

  • Deweloper
  • Wiadomości: 234
  • peprus
    • Zobacz profil
  • Otrzymane polubienia: 616
Odp: Edytor Scenerii
« Odpowiedź #18 dnia: 07 Maja 2023, 13:23:59 »
Nie do końca odniosłeś się do mojej wypowiedzi, bo większość z Twoich pytań odnosi się do braku funkcji tego edytora, a nie tego, jak go używać. Właśnie ta prostota edytora aktualnie sprawia, że jest stosunkowo łatwy, a i tak jest dużym przeskokiem względem tworzenia scenerii w notatniku. Uważam, że faktycznie zmiana sposobu zapisu (w tym autozapis) to coś, co znacząco by ułatwiło nowym osobom korzystanie z edytora (przynajmniej możliwość wskazania lokalizacji i nazwy pliku z zapisem, lub opcja automatycznego merge z wybranym plikiem by wystarczyła).
"Jestem ToPrusem i nic co pruskie nie jest mi obce." - Terencjusz

Obiekty statyczne i dekoracje dla scenerii <3

Online robert357

  • Wiadomości: 181
    • Zobacz profil
  • Otrzymane polubienia: 202
Odp: Edytor Scenerii
« Odpowiedź #19 dnia: 07 Maja 2023, 23:02:30 »
Eliminacja braków to też poprawa przystępności edytora, i to nie tylko dla tych mniej doświadczonych. Etap dodawania podstawowych opcji już dawno był i teraz wszystko rozbija się o potencjalne braki, detale i ogólną wygodę obsługi. Taki przykład z edytora pod F11. Nie ma tam (chyba) rozbicia obsługi na zaznaczanie/edytowanie i przemieszczanie obiektów, przez co łatwo jest przez przypadek coś przesunąć. Przez brak zaznaczania można nawet tego nie zauważyć. Wektorów pokazujących w jakim kierunku będzie się obracać obiekt też nie ma. Obie rzeczy są podstawą w praktycznie każdym edytorze jakim widziałem, i to są wręcz podstawy podstaw.

Dodatkowo chciałbym zaznaczyć, że "prosty edytor" niekoniecznie oznacza dosłownie prostego edytora z podstawowymi opcjami do edycji, tylko prosty w obsłudze i intuicyjny.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #20 dnia: 29 Sierpnia 2023, 23:51:35 »
Cześć.

1. Dziękuję Ra za objaśnienia. Nie dyskutuję, bo wszystko zostało napisane. Mój wniosek: nie powstanie drugi Rainsted

2. Podzielam zdanie @jakubg1, że prosty edytor scenerii / całości dałby więcej nowych tras i byłaby to wartość dodana. Mój młody chce się bawić, ale przecież nie Rainstedem. Niższa jakość tras? Bez znaczenia. Nie muszą trafiać do paczki. Zrobi się serwer z addonsami do pobrania, i kto będzie chciał to sobie polata po „gorszych”, ale będzie miał fun. Teraz mamy do wyboru: HQ raz na X lat, albo nic. A to co jest, już zostało oblatane do znudzenia.

3. Pośrednio związane: Dlaczego trzeba dodawać „ścianę lasu” a nie las? Potrzebny jest tylko mesh instancing z lod, a las proceduralnie wygeneruje edytor. Kosztem będzie tylko większy plik scn/inc, chyba że doda się generator do silnika a w scn/inc zadeklaruje tylko obszar, meshe, gęstość i ziarno. Ściana z lasem trąci latami 90-tymi.

4. Edytor musi być crossplatform lub platform independent, także dla devów. Nie musi a nawet nie powinien to być w c++, tylko w języku/-ach wysokiego poziomu. Edytor powinien mieć autosave i/lub commitlog - żadna robota nie może się stracić po crashu.

Z pkt. 1 i 2 wynika, że dodatkowy edytor nie będzie konkurował z Rainstedem, więc nie musi spełniać oczekiwań inżynierów (ci zostaną z Rainstedem). Co za tym idzie można go tworzyć niezależnie i mając na uwadze odbiorcę amatorskiego.


Pozdrawiam,
Marcin

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #21 dnia: 01 Września 2023, 00:17:19 »
Popieram jednak bve2 pod tym względem, że największą bolączką scenerii jest dekorowanie.

Analogicznie do wzmianki o „ścianie lasu” widziałbym proceduralne dekorowanie scenerii z opcją manualnego finetuningu (parametry, obszary exclude, ręczne sadzenie). Nie ma sensu siać traw i polnych kwiatków. To może ogarnąć edytor, a po stronie engine potrzebne minimum to wspomniany instancing plus jakieś rozwiązanie dedykowane dla trawska/zbóż.

Niech się ludzie skupią na dekoracji przestrzeni obiektów przemysłowych. Przy okazji - dobrze byłoby zrobić decale (bo chyba engine nie wspiera).

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #22 dnia: 25 Września 2023, 03:45:41 »
Odczytałem wstępnie pliki scn w Godot (całe levele, jeszcze bez torów). Na szybko wnioski: dopóki trawy, drzewa i inne złogi węgla będą wczytywane za pomocą includes z trójkątami, i zamiast jednego mesha obiekty będą poskładane z dziesiątek kąsków, to będzie lipnie z czasem ładowania a nawet renderingiem. A że format plików nie nadaje się do wczytywania sektorami, to ilość elementów powinna być jak najmniejsza. Edytora nie trzeba będzie pisać, bo Godot Editor daje się mocno rozbudowywać. Trzeba jednak ogarnąć edycję sektorami, bo edytor zamula przy rozbudowanych scenach.

Technika zapisu terenu w Maszynie jest ciekawa i została przemyślana pod kątem renderingu, choć nie czasu wczytywania (vide próby z sbt). Nie powinno się jej jednak używać do assetów statycznych czy zieleniny.

Parametryzowane meshe drzew czy traw są ciekawe, ale mało wydajne i lepiej mieć kilka modeli i dorzucić ich skalowanie w celu różnicowania (obok rotate).

Jak pozbędę się rażących baboli, to wrzucę jakiś filmik.

Offline matek123

  • Moderator
  • Wiadomości: 6176
    • Zobacz profil
  • Otrzymane polubienia: 2112
Odp: Edytor Scenerii
« Odpowiedź #23 dnia: 25 Września 2023, 09:34:30 »
Tu nawet nie chodzi o parametryzowanie drzew, tylko o wydajność, bo exe skleja wszystkie trawki o jednym materiale w jedno. Jakiś czas temu dopatrzyłem się, że na wrzosach było grass.t3d. Po zmianie na inc grywalność skoczyła.
Na upartego można w excelu albo zrobić mały programik, żeby przed edycją gras.inc podmienić na gras.t3d.
Najlepszym rozwiązaniem byłoby, żeby exe w t3d/e3d rozpoznawało czy obiekt zawiera jakieś animacje, czy nie (np kubły/ławki na peronach, trawa) i ich scalanie w jeden obiekt (tak jak geometrie na trójkątach terenu).
Poszukuję zdjęć na tekstury pociągów sieciowych. Szczególnie platform z pomostami.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #24 dnia: 25 Września 2023, 14:03:08 »
exe skleja wszystkie trawki o jednym materiale w jedno.

To dobrze, choć to nie przyspieszy wczytywania. A odnosiłem się do użycia np. scenery/tree.inc, który ma parametryzowane wierzchołki trójkątów.

Cytuj
Najlepszym rozwiązaniem byłoby, żeby exe w t3d/e3d rozpoznawało czy obiekt zawiera jakieś animacje, czy nie (np kubły/ławki na peronach, trawa) i ich scalanie w jeden obiekt (tak jak geometrie na trójkątach terenu).

Edytor powinien mieć podobne rozwiązania. I dochodzimy do sytuacji, w której źdźbła w plikach scn/inc są niepotrzebnie podefiniowane jako pojedyncze obiekty z meshami inline. Każdy taki inc to koszt parsowania -> czas ładowania scenerii.  Najtaniej byłoby zmienić sposób definiowania i renderowania trawska, a dla reszty powielanych modeli (lub kompromisem dla trawska na jakiś czas) - prostsze definiowanie w plikach scn (ew. w binarnym formacie) i renderowanie np z glDrawArraysInstanced  (podzielonymi na sektory).

Przy czym exe w wątku edytora najmniej mnie interesuje - wskazuję tylko miejsca które są/będą przeszkodami przy wczytywaniu scenerii, bo dokładnie ten problem mam w edytorze  - rendering jest szybki, ale wczytywanie scenerii jest czasochłonne. Szybciej jest wczytać jeden model i renderować go setki razy z nałożonymi transformami (obrót, przesunięcie, skala - oczywiście musi być shader do tego).

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6321
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 354
Odp: Edytor Scenerii
« Odpowiedź #25 dnia: 25 Września 2023, 14:07:20 »
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.
¯\_( ͡° ͜ʖ ͡°)_/¯ Ra

Polecam: kręgarz Wojciech Walczak, projekt masarni

Offline jakubg1

  • Wydział Repozytorium
  • Wiadomości: 1560
  • MaSzyna ma szynę, szyna ma MaSzynę - na kołach.
    • Zobacz profil
  • Otrzymane polubienia: 1214
Odp: Edytor Scenerii
« Odpowiedź #26 dnia: 25 Września 2023, 14:26:25 »
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.
« Ostatnia zmiana: 25 Września 2023, 14:29:51 wysłana przez jakubg1 »
10 lat na forum MaSzyny!

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6321
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 354
Odp: Edytor Scenerii
« Odpowiedź #27 dnia: 25 Września 2023, 16:03:13 »
Problem jest taki, że dokumentacja formatu RSF nie jest dostępna publicznie.
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.

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.
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ć.

Offline marcinn

  • Wiadomości: 65
    • Zobacz profil
  • Otrzymane polubienia: 86
Odp: Edytor Scenerii
« Odpowiedź #28 dnia: 25 Września 2023, 16:32:37 »
Planowałem w 2015 roku wczytywanie z RSF do MaSzyny, po czym ktoś uznał, że nie warto tego robić

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.
« Ostatnia zmiana: 25 Września 2023, 17:06:09 wysłana przez marcinn »

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6321
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 354
Odp: Edytor Scenerii
« Odpowiedź #29 dnia: 25 Września 2023, 17:25:29 »
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.
¯\_( ͡° ͜ʖ ͡°)_/¯ Ra

Polecam: kręgarz Wojciech Walczak, projekt masarni