- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Poszukuję, chcę zrobić => Wątek zaczęty przez: marcinn w 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
-
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ą.
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
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ę.
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?
-
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).
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.
-
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?
-
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.
-
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...
-
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....
-
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.
-
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ł".
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.
-
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.
-
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.
-
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).
-
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.
-
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
-
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).
-
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.
-
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).
-
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.
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).
-
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.
-
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.
-
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ć.
-
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.
-
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.
-
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.
Dokładnie tak powinno być.
format tekstowy robi więcej problemów niż daje korzyści
Żebyśmy się dobrze zrozumieli - nie chcę zapisywać tekstowo meshy czy terenu. To byłoby problematyczne i niewydajne. Natomiast ustawianie parametrów, komentarzy, deklaracje obiektów - to jest przydatne. Jeśli np. zrobię autoscatter do lasu, to w pliku txt będzie tylko jego deklaracja i parametry, a w efekcie edytor może generować setki drzewek np. do INC. Teraz, jak masz 10tys includowanych traw, to diffy są oczywiście o kant tyłka. Chcę powiedzieć, ze przy odpowiedniej organizacji plików (np. podział na sektory, niekoniecznie techniczne co logiczne), da możliwość panowania nad zmianami. No ale jak ktoś porobi ubercommity, to nic nie pomoże.
Pliki TSCN Godota wspierają zależności. Wewnątrz edytora jest to zrobione dwustopniowo: na ścieżkach i na UID. Sprawdzają się, bo w razie rozwalenia czegoś wchodzisz vimem, poprawiasz i scena znowu działa. Grzebanie w uszkodzonej binarce to w praktyce oznacza koniec - porzucenie lokalnych zmian i przywrócenie poprzedniej wersji. TSCN wspiera zależności binarne, więc tak mogę dołączyć wyrzuty z Rainsteda, które pojawią się jako customowe node/nodes (external resources). Czy to się sprawdzi - jeszcze nie wiem. Dopiero eksperymentuję.
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.
https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-2-terrain-rendering-using-gpu-based-geometry
-
Grzebanie w uszkodzonej binarce to w praktyce oznacza koniec - porzucenie lokalnych zmian i przywrócenie poprzedniej wersji.
Format RSF ma strukturę bazy danych, która jest pokłosiem moich doświadczeń z uszkodzonymi dyskami. Podstawowy rekord danych ma 128 bajtów, na jego początku 4 bajty określają sposób interpretacji pozostałych 124. Teoretycznie odzyskanie danych z uszkodzonego dysku pozwala odtworzyć zawartość RSF, nawet jeśli została zagubiona kolejność sektorów — będzie brakować tylko tych obiektów, których odczytanie nie było możliwe. No ale obecnie chyba dyski się mniej uszkadzają. Efektem poniekąd ubocznym jest możliwość sklejenia dwóch plików RSF razem przy użyciu bardzo prostych narzędzi (np. COPY /B).
Drugim z poważniejszych problemów jest uszkadzanie danych przez edytor, co mi się kilka razy zdarzyło. Format jest niezależny od wersji edytora, więc edytor powinien być w stanie otworzyć plik zapisany dowolną wcześniejszą wersją i ewentualnie skorygować uszkodzenia, jeśli znany jest sposób powstawania tych uszkodzeń i da się je odwrócić (na ogół się da, ponieważ wyświetlanie obiektów odbywa się bezpośrednio z RSF, bez struktur pośrednich, więc poważne uszkodzenia widać od razu). Ale w razie co jest potrójny system tworzenia kopii zapasowych.
Trzeci problem to niezależna edycja w tym samym czasie przez różne osoby. Zacząłem robić narzędzia pozwalające porównać pliki RSF, a także wyciąć i przekleić wybrane fragmenty (np. geograficznie, albo wg warstwy). W ostateczności da się dopracować możliwość zapisania zawartości RSF w formacie tekstowym, np. YAML (ze względu na obsługę wskaźników/referencji), żeby następnie porównać tekstowo, zintegrować i zapisać ponownie jako RSF bez zgubienia informacji. Póki co można to zrobić jedynie w ograniczonym zakresie, jako SCN (co też robiłem: po wyeksportowaniu można porównać przez SVN, wypisać różnice i dokleić je do jednego z RSF jako konwersję wypisanych różnic z SCN do RSF).
Co jeszcze rozważałem, to specjalny edytor binarny do plików RSF. Odpowiedni zestaw definicji pozwalałby łatwo interpretować poszczególne fragmenty i przemieszczać się po zależnościach, zupełnie niezależnie od algorytmów edytora. No ale nie miałem jeszcze takiej skali uszkodzeń, żeby to było potrzebne, w kilku przypadkach wystarczył mi edytor szesnastkowy (i raczej wiele lat temu to było).
-
Odpowiem krótko, że nie odpowiedzialnością formatu pliku jest recovery. Systemu plików - tak. Mnie chodzi o to, że proste fixy (oraz review) idzie zrobić właśnie na tekście, plus do tego tekst jest scm-friendly. Binarki - nie.
Dlatego godot ma tscn (wersję tekstową), którą można zapisać jako scn (binarnie) - semantycznie to jest to samo. Ale też ma escn - wersję binarną eksportową. I Twój format wydaje się być alternatywą dla ESCN (ewentualnie SCN), a nawet go przewyższać - streaming segmentów, ktorych Godot nie ma i nie da się robić streamingu ani meshy, ani tekstur. Z resztą trochę podobnie jest z roboczym tekstowym gltf vs binarnym glb.
Tak czy owak format edycyjny nie ma większego znaczenia. Maszyna ma problem z scn/inc, gdzie Twój format rozwiązałby wiele problemów ładowania i narzutu konwersji/merge w samym exe. Plik wynikowy może być produkowany przez edytory lub narzędzie pakujące części składowe w jeden plik.
EDIT: problemem nie jest format plików edycyjnych, tylko ograniczona semantyka scn/inc. To że coś jest trawą/terenem/drzewami wynika tylko z nazwy include’a. Musimy mieć oddzielne klasy dla tych obiektów, ponieważ inaczej je obsługujemy (well… powinniśmy inaczej pbsługiwać, jeśli to ma przynieść korzyści). Ladując scn/inc do edytora nie wiem co jest foliage, a co terenem. Mogę tylko odróżnić node triangles od reszty, i je ewentualnie połączyć dla tych samych deklaracji materiału. A i tu może być deklaracja inline, albo przez .mat. Ogólnie widać 20 lat długu technicznego.
-
Mnie chodzi o to, że proste fixy (oraz review) idzie zrobić właśnie na tekście, plus do tego tekst jest scm-friendly.
Kto miałby to robić? Chociaż ja mogę mieć skrzywione postrzeganie, bo patrzę głównie na geometrię torów. Ostatnio wypłynęła sytuacja z Całkowem, gdzie była zepsuta geometria na moście (chyba od początku istnienia tej scenerii). Zaproponowanie korekty zajęło mi dosyć dużo czasu, a mam 15 lat doświadczenia w układaniu torów... Są scenerie, na których drzewa wchodzą w tory... Wystarczy zaobserwować w scenerii, ustalić orientacyjnie pozycję, wczytać scenerię do Rainsted i odszukać obiekt do przesunięcia (edytor SCM podaje nazwę pliku i linijkę wpisu). I mimo to nie ma kto poprawić, zaglądając do plików tekstowych — za duży próg wejścia. Ponieważ dla mnie poprawienie niektórych rzeczy jest trywialne, wolałbym aby powstała możliwość zrobienia zrzutu ekranu, zaznaczenia na nim czegoś oraz opisania, co jest źle i dlaczego, a następnie wysłania tego na serwer. Gdyby taki system istniał, to następnie osoba odpowiedzialna za dany fragment poprawiałaby to albo argumentowała za innym rozwiązaniem, po zapoznaniu się z sytuacją. Ja w Linii 61 (którą głównie naciągałem na mapy, a której wygląd i funkcjonalność teoretycznie były już dopracowane wcześniej) wiem o istnieniu całej masy różnych błędów — tylko po co mam poprawiać rzeczy, na które nikt nie zwraca uwagi? Wszyscy już scenerię objechali w 2007 roku, to po co coś w niej poprawiać? "Nie poprawiajmy starych, tylko róbmy nowe." — z tych samych niedopracowanych cegiełek, które nie zachowują spójności i są źródłem błędów... Aż mi się przypominają czasy samoobracających się wskaźników W27...
Ladując scn/inc do edytora nie wiem co jest foliage, a co terenem. Mogę tylko odróżnić node triangles od reszty, i je ewentualnie połączyć dla tych samych deklaracji materiału. A i tu może być deklaracja inline, albo przez .mat.
To jest dopiero początek zamieszania... Dlatego ja mam cały algorytm "heurystyczny", który przy wczytywaniu SCN próbuje zgadywać, co jest czym. Co jest drzewem, co semaforem, a co słupkiem (czasami to się myli i muszę dodać wyjątek, gdy zauważę). Swego czasu powstał katalog obiektów, w którym do plików INC dopisane są kategorie. Nie jest to dopracowane, ponieważ nikomu się nie chciało zrobić z tym porządku... Co gorsza, nie są unormowane kąty wstawienia niektórych obiektów, np. niektórych wskaźników We, półbramek, więc dodatkowo trzeba skąd wiedzieć, które obiekty są odwrotnie, niż by się mogło wydawać na podstawie innych obiektów tego typu. A jeszcze jest kwestia przesunięcia w pionie, z czym też bywa różnie.
Ogólnie widać 20 lat długu technicznego.
No tak to jest, jak się dorabia shadery, zamiast zacząć od uporządkowania podstawowych elementów składowych, żeby miały jakiś sens i były solidną bazą. Potem już nie ma nikogo odpowiedzialnego i czekamy, aż ktoś ostatni zgasi światło.
-
Kto miałby to robić? Chociaż ja mogę mieć skrzywione postrzeganie, bo patrzę głównie na geometrię torów.
Nie wiem. Obecnie chyba mało kto cokolwiek robi.
za duży próg wejścia
Ogólnie jest za duży próg wejścia i mocno specyficzny workflow.
z tych samych niedopracowanych cegiełek, które nie zachowują spójności i są źródłem błędów...
Im dłużej eksperymentuję z edytorem, tym więcej mam ochoty przekonwertować "cegiełki" i do starych nie wracać. Przekonwertowany* "Stary Jawor Eszelon" (bez torów, trakcji, trainsetów, bo tego jeszcze nie mam) wczytuje się w Godocie 4 sekundy (jak wywalę trawy - <2 sekundy). EXE Maszyny wczytuje mi scenę 24 sekundy. Problemem jest niewydolny format plików SCN/INC i ich parsowanie. SBT nie pomaga. W ogóle pierwsze do wywalenia są trawska, zaraz za nimi drzewa. Trzeba definiować je inacze, nie setkami tysięcy inców.. Co z tego że EXE robi merge meshy, skoro to jest paskudnie wolne.
* Konwertuję scenki bo eksperymentuję, a Godot nie pracuje z zewnętrznymi resources (nie mam jeszcze edytora w runtime i korzystam z wbudowanego w Godota). No i żeby zapisać sceny w jego formacie, muszę je "spakować" do projektu. Czas wczytywania przekonwertowanej sceny był dziś jak plaskacz - dało mi to do myślenia. Np. na ile prace nad Maszyną blokuje archaiczny workflow i formaty plików. Jak mi kolega pisze, że żeby Galicję przetestować / udekorować odpalają scenariusz bitą godzinę, to tylko pozostaje mi podziwiać za wytrwałość. Ja bym to olał. I inni pewnie olewają, albo ograniczają się do malowania siódemek i stonek (bo to się łatwo podpina).
To jest dopiero początek zamieszania... Dlatego ja mam cały algorytm "heurystyczny", który przy wczytywaniu SCN próbuje zgadywać, co jest czym.
Nie no, podziwiam. To jest jednak error prone i każdy nowy twórca scenariuszy może "to zepsuć" nazwą pliku.
Swoją drogą zrozumiałem, że INC-e z parametrami działają na zasadzie preprocesora. Trudno byłoby je parametryzować w runtime. Nie twierdzę że to niemożliwe, ale konieczny byłby dodatkowy krok inicjujący - błędogenny i właściwie zbędny, jeśli zrobić assety w dzisiejszych standardach. W ogóle w Godocie jest format PCK. Służy do dostarczania paczek danych - podstawowej, jak i jakichkolwiek modów czy DLC. Oczyma wyobraźni widzę, jak to mogłoby pchnąć rozwój.
No tak to jest, jak się dorabia shadery, zamiast zacząć od uporządkowania podstawowych elementów składowych, żeby miały jakiś sens i były solidną bazą.
Wiesz, patrzę na to wszystko już dłuższy czas... Widzę, że są gotowe narzędzia - i wizualne, i programistyczne. glTF/GLB, (T/E)SCN, PCK. Dlatego klaruje mi się koncepcja, żeby przejść z assetami na nowe formaty. Do tego zrobić konwerter do plików obsługiwanych przez EXE. Czyli workflow twórców scenerii, modeli, tekstur byłby nowy, a do exe robiłoby sie eksport. Nawet automat niech eksportuje, a nie ludzie. To jest dla mnie odwrócenie pomysłu, bo wcześniej zakładałem edytowanie plików SCN/INC z Maszyny (ale widzę, że to nie ma sensu przez wspomniane już ograniczenia)
Oczywiście w tym wszystkim potrzebne są przede wszystkim tory. Workflow mógłby zaczynać się od Rainsteda, a jego pliki wynikowe byłyby ładowane jako zależności do edytora scenerii. I dopiero narzędzie do konwersji generowałoby pliki kompatybilne z maszynowyme exe.
EDIT:
Gdyby udało mi się wyeksportować teren z tego pluginu, to można byłoby fantazjować tak:
-
Nie wiem. Obecnie chyba mało kto cokolwiek robi.
Chodziło mi głównie o to, że systemy śledzenia wersji są raczej poza percepcją ludzi, którzy są w stanie coś zrobić. Najpierw trzeba ogarniać format tekstowy, umieć to "swobodnie czytać", żeby następnie móc porównywać zmiany i być w stanie wyłapać cośkolwiek na tym etapie.
Problemem jest niewydolny format plików SCN/INC i ich parsowanie. SBT nie pomaga. W ogóle pierwsze do wywalenia są trawska, zaraz za nimi drzewa. Trzeba definiować je inacze, nie setkami tysięcy inców.. Co z tego że EXE robi merge meshy, skoro to jest paskudnie wolne.
Format RSF jest raczej pośrednim pomiędzy SCN, a tym, co by można było zoptymalizować pod silnik graficzny. Na poziomie edytora RSF obiekty typu "include" są osobnymi obiektami. Wczytując taki RSF do MaSzyny, należałoby nadal parsować pliki INC, z odpowiednimi parametrami (ale pobranymi już z RSF). Jednak można również utworzyć RSF, w którym będą zapisane elementy składowe z plików INC, wtedy dodatkowe parsowanie będzie zbędne (zyskuje się szybkość wczytania kosztem wielkości pliku i uniwersalności) — plus jest też taki, że wtedy wiemy z góry, ile będzie obiektów i ile łącznie zajmą pamięci, co potem upraszcza wyrzucenie tego, gdy przestaje być potrzebne.
Jak mi kolega pisze, że żeby Galicję przetestować / udekorować odpalają scenariusz bitą godzinę, to tylko pozostaje mi podziwiać za wytrwałość.
No to i tak jest po wielu optymalizacjach. Oryginalnie obiekty były wyszukiwane w listach jednokierunkowych. Jak zaczęły powstawać scenerie w Rainsted, to czas ich wczytywania szedł w godziny. Były dużo większe, niż scenerie w paczkach z MaSzyną. Opracowałem format binarny dla modeli, żeby ich nie parsować cyferka po cyferce i nie liczyć potem wektorów normalnych za każdym razem. Przerobiłem algorytmy wyszukiwania, żeby łączenie torów szukało tylko w najbliższej okolicy, a nie po wszystkich wczytanych torach. No i finalnie doszedłem do wniosku, że to parsowanie plików tekstowych oraz każdorazowe wyszukiwanie powiązań to droga donikąd i trzeba to robić inaczej. Na przykład wczytać informację o obiektach binarnie i znać liczbę obiektów z góry, żeby potem móc je usunąć i wczytać obiekty z innego miejsca (dlatego nie chciałem się angażować w robienie pasków postępu wczytywania). No ale pisk się zaczął, że potrzebne są głównie światła i cienie, a nie jakieś tam optymalizacje.
Swoją drogą zrozumiałem, że INC-e z parametrami działają na zasadzie preprocesora.
Tak. Co gorsza, jest to robione na wczesnym etapie parsera, więc w czasie wczytania nie jest nijak wiadomo, że dane obiekty są zgrupowane np. w ramach semafora (chyba że ktoś to jakoś przerobił ostatnio). W efekcie edycja na poziomie MaSzyny nie jest w stanie wyprodukować zestawu danych, który można by zapisać i ponownie wczytać. A przynajmniej format nie jest... jakby to powiedzieć... odwracalny?
Oczyma wyobraźni widzę, jak to mogłoby pchnąć rozwój.
Przede wszystkim musisz wiedzieć, po co to robisz. ;) Mi głównie zależy na tym, żeby moja dotychczasowa praca się nie zmarnowała. Więc mogę się dzielić moim punktem widzenia i opisywać moje rozwiązania. Ale, póki co, nie czuję potrzeby, żeby robić coś więcej (tzn. pisać jakiś kod). Jeśli będą potrzebne zmiany w zakresie formatu RSF, to je opracuję w miarę możliwości. Problem z zaczynaniem od zera jest taki, że może z tego nic użytecznego nie powstać (patrz Nebula, SPT), a ja wolę ulepszać coś, co już działa, bo przynajmniej działa i może zadziała lepiej (chociaż będzie miało dług techniczny).
To jest dla mnie odwrócenie pomysłu, bo wcześniej zakładałem edytowanie plików SCN/INC z Maszyny (ale widzę, że to nie ma sensu przez wspomniane już ograniczenia)
Popieram. Bazowanie na SCN/INC nie ma sensu, dla mnie to jest jedynie format wstecznej zgodności, ewentualnie przydatny do awaryjnego wykonania pewnych przekształceń wobec braku lepszych narzędzi.
Gdyby udało mi się wyeksportować teren z tego pluginu, to można byłoby fantazjować tak:
To jest też droga donikąd, tzn. nie ma realnej potrzeby, by kształtować teren w ten sposób. Pewnie wielbiciele scenerii fikcyjnych będą mieli inne zdanie, ale potem z tymi sceneriami fikcyjnymi są same problemy (z obiegami taboru, sensem tras, kilometrażem, alternatywnymi wariantami rzeczywistości po łączeniu z innymi fikcyjnymi itd.). Moim zdaniem trzeba zacząć od przekształcania danych oferowanych przez Geoportal, w załączeniu widok na chmurę punktów ze stacji Zwardoń. W takiej postaci nie nadaje się ona do użycia w symulacji, ze względu na ciężar, dziury na pionowych powierzchniach oraz zbędne odzwierciedlenie infrastruktury. Tutaj punkty mają kolory związane z interpretacją punktu (teren, budynki, zieleń, inne), ale jest też chyba wersja z kolorami "naturalnymi" (aczkolwiek mają tam ewidentny problem z wyrównaniem balansu bieli, więc korekta tego by się przydała w edytorze).
-
Tak. Co gorsza, jest to robione na wczesnym etapie parsera, więc w czasie wczytania nie jest nijak wiadomo, że dane obiekty są zgrupowane np. w ramach semafora (chyba że ktoś to jakoś przerobił ostatnio). W efekcie edycja na poziomie MaSzyny nie jest w stanie wyprodukować zestawu danych, który można by zapisać i ponownie wczytać. A przynajmniej format nie jest... jakby to powiedzieć... odwracalny?
Teraz jest jeszcze gorzej, bo jakiś czas temu doszło losowanie includów, więc zawartości docelowej nie da się już nawet przewidzieć. Ale przydaje się czasem, więc optuję za wprowadzeniem takiej możliwości również do nowego formatu modeli.
-
To już nie wspominam, że ktoś upchnął "include" do plików FIZ, MMD i T3D. Pozostaje mi kupić popcorn i przyglądać się, czy kiedykolwiek ktoś to jeszcze ogarnie. ;) Kiedy mogłem, to protestowałem przeciw wprowadzaniu pewnych rozwiązań, które może były ciekawe i jakoś przydatne, ale były również istotnym źródłem dalszych problemów. Niektóre przepchnięto, po czym problemy się ujawniły i niektóre z nich pozostają nadal nierozwiązane. Nie mam już ambicji, żeby to sprzątać. Nie widzę też innych chętnych.
Należałoby określić, co w zasadzie chcemy osiągnąć. Ja — powiedzmy — mam pod opieką trasę od Słowacji do Opola, Kępna i Częstochowy, chciałbym dołączyć "Kaliską" oraz CMK, a także odkopać tory z Łodzi do Torunia. Być może coś jeszcze, jeśli się da... Chciałbym, żeby to jakoś działało, jakoś wyglądało i nadawało się do użytku. Fajnie by było zrobić scenerie na stan z połowy XX wieku i dokończyć symulację parowozów, ale to na razie sobie odpuszczam. ;)
-
Chodziło mi głównie o to, że systemy śledzenia wersji są raczej poza percepcją ludzi, którzy są w stanie coś zrobić. Najpierw trzeba ogarniać format tekstowy, umieć to "swobodnie czytać", żeby następnie móc porównywać zmiany i być w stanie wyłapać cośkolwiek na tym etapie.
Jest możliwość. Może debugowanie bisectem coś komuś technicznemu powie. Tekst czyta się łatwiej niż binarkę. Chyba że bisekcja miałaby polegać na ocenie wizualnej lub odpalaniu symulacji, ale wtedy uderzasz w inny problem - czas odpalania symulacji, i to z jego powodu nikt tego nie będzie robił.
Format RSF jest raczej pośrednim pomiędzy SCN, a tym, co by można było zoptymalizować pod silnik graficzny
(Jeszcze) Nie wiem czy RSF użyłbym do edytora. Co do EXE, to nie moja bajka. Jak masz gdzieś choćby szczątki dokumentacji, to możesz podesłać linka.
Jak zaczęły powstawać scenerie w Rainsted, to czas ich wczytywania szedł w godziny. Były dużo większe, niż scenerie w paczkach z MaSzyną.
Plus sprzęt był inny. Mimo tego są to czasy nieakceptowalne.
Przede wszystkim musisz wiedzieć, po co to robisz. ;) Mi głównie zależy na tym, żeby moja dotychczasowa praca się nie zmarnowała.
Początkowo chciałem edytować scenerie maszyny, ale po czasie (roku?) cel się krystalizuje: oszczędność czasu w celu tworzenia nowych scenerii za pomocą wygodnego edytora scenerii dla nowych tras, z opcją importu istniejących na potrzeby ewentualnego rozwoju.
I początkowo myślałem że da się oblecieć to na obecnych assetach jako źródłach, tj. użyć ich jako gotowych klocków, ale to podejście też będzie problematyczne. Ostatecznie wychodzi na to, że musi powstać i edytor, ale i nowy format asset packów. Ale przed tym trzeba będzie dodefiniować klasy obiektów, a szczególnie wyróżnić terrain i foliage (wszelkiej maści trawska), żeby nie były tylko trójkątami. To jest konieczne do pracy edytora i ew. współpracy narzędzi (np. z Rainsted). EDIT: i chcę podkreślić, że przy założeniu konwersji/buildów paczek do EXE nowy workflow nie wyklucza współistnienia starego.
To jest też droga donikąd, tzn. nie ma realnej potrzeby, by kształtować teren w ten sposób. Pewnie wielbiciele scenerii fikcyjnych będą mieli inne zdanie
Nie zgodzę się w pierwszej części. Bo o ile faktycznie scenerie fikcyjne też są celem projektu (choć może nie są celem standardowej paczki danych do maszyny), to dane z Geoportalu można potraktować jako źródło do pluginu/edytora, który pokazałem na filmie. Tak zaimportowany teren można poddać ręcznej obróbce choćby po to, żeby lepiej wyglądał w grze. Symulator kolejowy nie jest platformą dla geoinżynierów, która musi rzeźbę terenu odzwierciedlać 1:1. Tu należałoby wspomnieć o arsenale narzędziowym związanym z foliage / biomes - czy to scatterami, czy generowaniem proceduralnym zieleniny (np. na podstawie kolorów z danych z geoportalu), które są możliwe do zastosowania przy edycji WYSIWYG w jednym narzędziu.
Założenie: teren jest otoczeniem wizualnym tylko i wyłącznie. Natomiast tor - tj. jego geometria, związana oczywiście z ukształtowaniem terenu w świecie rzeczywistym, jest dla symulacji kluczowa. W świecie symulacji jestem za odseparowaniem terenu (otoczenia) od geometrii toru. I jestem przekonany że istnieje techniczna możliwość automatycznego wykonania rzeźby dla podtorza na podstawie geometrii toru, co otwiera możliwość współdziałania narzędzi i wykorzystania ich mocnych stron. Chcę podkreślic, że ręczna rzeźba terenu to jest możliwość, a nie jedyna droga. Zastosowanie gotowych i/lub rozwijanych przez kogoś innego narzędzi daje szersze możliwości, i nie wymaga developmentu wszystkiego od podstaw. Przynajmniej w części związanej z budową edytora.
To już nie wspominam, że ktoś upchnął "include" do plików FIZ, MMD i T3D
Nie chcę tego wiedzieć.
-
Jest możliwość. Może debugowanie bisectem coś komuś technicznemu powie. Tekst czyta się łatwiej niż binarkę. Chyba że bisekcja miałaby polegać na ocenie wizualnej lub odpalaniu symulacji, ale wtedy uderzasz w inny problem - czas odpalania symulacji, i to z jego powodu nikt tego nie będzie robił.
To jest chyba zbyt duży poziom abstrakcji, jak na scenerie. Jeśli już, to debugowałem skrypty sterujące stacjami, gdy nie miałem gotowego generatora i trzeba było ustalić, jak to w ogóle zrobić, żeby w ogóle realizowało założony cel (przepuszczanie pociągów z unikaniem kolizji oraz wzajemnego blokowania się). Obecnie mam generator i potrzeba debugowania pojawia się bardzo rzadko.
Jak masz gdzieś choćby szczątki dokumentacji, to możesz podesłać linka.
https://rainsted.com/pl/Klasa/BinPos — widzę, że na niektórych stronach trzeba by poprawić linkowanie. Jak przejrzysz i będziesz mieć uwagi, to spróbuję w październiku poprawić czy uzupełnić (chwilowo mam inne zajęcia).
I początkowo myślałem że da się oblecieć to na obecnych assetach jako źródłach, tj. użyć ich jako gotowych klocków, ale to podejście też będzie problematyczne.
Większość rzeczy wymaga uporządkowania (raczej jako katalog obiektów, a nie przesuwanie plików pomiędzy podkatalogami), niektóre znacznej przebudowy (np. mocowania sieci trakcyjnej muszą mieć możliwość regulacji w poziomie i w pionie). Trzeba raczej mieć pomysł na to, jak to docelowo powinno wyglądać, a potem sprawdzić, na ile da się użyć dostępnych materiałów. Ja zakładałem użycie silnika graficznego z wbudowanymi np. elementami zieleni, typu Outerra, Esenthel czy Unreal Engine, więc rozpisywanie tego na konkretne tekstury i modele T3D nie miało dla mnie sensu. Podobnie powinien być system dla budynków, czyli zestawy okien, drzwi, dachów, rynien itd. do składania tego w konkretne bryły. Podobnie mosty, powinny być składane z typowych elementów.
Nie zgodzę się w pierwszej części. Bo o ile faktycznie scenerie fikcyjne też są celem projektu (choć może nie są celem standardowej paczki danych do maszyny), to dane z Geoportalu można potraktować jako źródło do pluginu/edytora, który pokazałem na filmie.
Ja od początku jestem zdania, że do stworzenia scenerii fikcyjnej potrzebne jest dużo większe przygotowanie merytoryczne niż do kopiowania rzeczy obserwowalnych w rzeczywistości. Dostrzegam potencjał w sceneriach fikcyjnych w zakresie robienia eksperymentów. Bo pytanie, czy budowa trasy z Bełchatowa do Wielunia to nadal sceneria fikcyjna? O ile można wziąć tory LK139 z 2008 i ulepszać tę trasę o otoczenie i lepsze dopasowanie do map, to co dalej z Quarkiem, Drawinowem czy Krzyżową? Ktoś tam wstawi krzywe przejściowe w końcu? Ktoś przerobi nierealnie poziome tory na jakoś bardziej prawdopodobny profil pionowy?
Założenie: teren jest otoczeniem wizualnym tylko i wyłącznie.
A ja tam brałem pod uwagę jeżdżenie po trójkątach terenu. Zastanawiałem się nad tym, że można by MaSzynę zintegrować razem z Virtual Bus w ramach jednego projektu — tam zrobiono dużą różnorodność autobusów (tylko były jakieś problemy licencyjne, bo chyba autobusy były powiązane z trasami, czy coś). Ale nie wystarczyło mi samozaparcia, żeby coś więcej zrobić. W zasadzie to nawet nie mamy jednego dobrego modelu miasta, gdzie byłyby tramwaje i kolej — Wrocław czy Częstochowa to jednak są zbyt duże. Początkowo też chciałem robić jakąś formę integracji z Trancity, gdzie była również symulacja trolejbusów... Teoretycznie do zrobienia jest Elbląg, ale musiałoby się komuś jeszcze chcieć.
-
To ja może przedstawię jeszcze moją wizję edytora, który już zacząłem robić, ale na razie wstrzymałem prace, żeby nie dublować roboty. Nie pamiętam, czy ja to już kiedyś pisałem?
Teren: Oryginalnie pod uwagę brałem dwa systemy terenu. Trainzowy jest bardzo prosty i do edycji terenu są pędzle, ale ze względu na skończoną (i niską) precyzję siatki spowodowałoby to brzydkie efekty, np. "ząbkowanie" terenu na brzegach nasypów niebędących pod kątem prostym względem siatki. Z kolei MaSzynowy oferuje w teorii nieskończoną dokładność i możliwości, ale z powodu oparcia na trójkątach jego edycja byłaby żmudna i wymagałaby licznych optymalizacji, aby nie przegiąć z ilością trójkątów. Od @MichauSto padła ciekawa propozycja użycia systemu trainzowego z możliwością zagęszczania siatki w poszczególnych kwadratach, aby połączyć prostotę z precyzją i zminimalizować negatywne efekty.
Tory: System układania torów bardzo różni się od przyjętego przez Ra, mimo to uważam że miałby duży potencjał, elastyczność i możliwość rozbudowy. Opierałby się na interakcjach z torami. Na przykład można by było zaznaczyć tor i dodać kolejny segment z przodu, z tyłu, bądź też z boku z zadaną separacją. Tworzenie rozjazdów i głowic rozjazdowych opierałoby się na wstawianiu odcinka toru pod kątem (w tym przypadku 1:9), a następnie dobudowie tak, by w miejscu przecięcia torów można było ustawić łuk lub rozjazd o zadanym promieniu, zarówno rozjazdy zwyczajne, jak i krzyżowe. Prosty przykład jak by to działało zamieściłem w załączniku.
Pozostałe rzeczy jak i sam interfejs byłyby podobne do edytora w Trainzie, jednak z udogodnieniami chociażby z edytora w Train Driverze 2, np. przyklejanie obiektów przy torach bądź elementów sieci trakcyjnej do siebie.
-
Technika terenu w pluginie który pokazałem to jedno z popularnych rozwiązań - Geometric Clipmap Mesh Terrain. Link do materiału Nvidii podałem, technika stosowana m.in. w Wieśku 3. Nie ma sensu wymyślać kół na nowo. W kontekście >tego< edytora zostanę z tym narzędziem.
Natomiast w kontekście EXE to już się nie wypowiadam i zakładam że edytor i tak będzie eksportował do plików zjadliwych dla exe symulatora, więc na początku będą to trójkąty. Może od razu byłby to wyrzut do sbt.
-
Z mojego punktu widzenia, kwestie terenu i układania torów zostały dawno rozwiązane i nie ma potrzeby się nad nimi pochylać. To, co jest teraz do zrobienia, to regulacja sieci trakcyjnej ("przyklejanie (...) elementów sieci trakcyjnej do siebie", które wymaga opisania ich rozmiarów na potrzeby edytora), łatwe i sprawne wypełnianie otoczenia roślinnością i zabudowaniami w sposób przypominający rzeczywistość (i żeby jeszcze to nie zamulało) oraz generator misji, który na podstawie wykresów ruchu utworzy rozkłady i sterowanie stacjami tak, aby po wybraniu dowolnego rozkładu przejechać trasę pociągu, mijając odpowiednie inne...
Ostatnio znalazłem pociąg TLK48502/3 z 2010 roku, jadący od stacji Bielsko-Biała na Ostrów Wlkp. (tory mam do Kępna). Chciałbym to uruchomić i przejechać ten odcinek... Ale ilość rzeczy do spięcia sprawia, że na razie mi się nie chce. Fajnie by było znaleźć coś ze Słowacji, ale to pewnie trzeba przejrzeć wcześniejsze lata.
Tworzenie rozjazdów i głowic rozjazdowych opierałoby się na wstawianiu odcinka toru pod kątem (w tym przypadku 1:9), a następnie dobudowie tak, by w miejscu przecięcia torów można było ustawić łuk lub rozjazd o zadanym promieniu, zarówno rozjazdy zwyczajne, jak i krzyżowe.
Chcesz budować proste stacje, OK. Ja zaczynałem w 2008 od naciągania na mapy scenerii PMPPW, która zrobiona w 3DS Max miała w miarę dobrą topologię, ale problemy z odległościami przekładały się na brak możliwości dopracowania profili pionowych (a były tam fest pochylenia). 10 lat temu miałem trasę z Opola do Zielonej Góry, ale błędy w symulacji skutkowały nieprzewidywalnym zachowaniem pociągów i w efekcie nie miało to sensu. Jeszcze w 2017 roku pociąg wyjeżdżający z Wrocławia w kierunku na Kłodzko wracał tyłem po 20 minutach, bo mu się zrywała przyczepność do torów i się gubił. A nawet w 2020 roku osobowy nie potrafił ruszyć z ostatniego przystanku przed Zwardoniem.
-
Z mojego punktu widzenia, kwestie terenu i układania torów zostały dawno rozwiązane i nie ma potrzeby się nad nimi pochylać.
łatwe i sprawne wypełnianie otoczenia roślinnością
Z perspektywy tego edytora jest na czym się pochylać. Są standardy i narzędzia do użycia, a czas na development jest mniej niż skromny. Jest stagnacja w projekcie i wracający problem braku chętnych do dekorowania scenerii. Na Galicji nie ma kto poprawić trójkątów terenu i się nie dziwię, bo obecny sposób jest trudny. Ten edytor ma w tym pomoc. Tak samo chcę wyelimnować sianie trawy - to jest bez sesnu. Dosiać to można sobie parę kwiatków scatter toolem (podrzucę film), a nie jak ogrodnik na emeryturze pojedyncze pęki ;) Po co tracić cenny czas na dekoracje, skoro można się wspomóc.
Jak już wspominałem - to wszystko nie dotyczy exe, ale może nie wyraziłem się jasno - nie dotyczy też innych narzędzi jak np. Rainsted.
To, co jest teraz do zrobienia, to regulacja sieci trakcyjnej ("przyklejanie (...) elementów sieci trakcyjnej do siebie", które wymaga opisania ich rozmiarów na potrzeby edytora)
Wydaje mi się, że piszesz o Rainstedzie. Jak będę miał więcej czasu, to naszkicuję schemat ideowy który "klocek" do czego może być użyty, a w którym miejscu się spotykamy. Bardzo ogólnie - chcę doprowadzić do sytuacji, gdzie ktoś będzie mógł robić teren albo w Rainstedzie, albo w nowym edytorze, gdzie exe i tak dostanie <coś co potrafi odczytać> do wyrenderowania. I dla tych którzy będą mieli terrain w Rainstedzie, będę chciał dać możliwość jego wczytania do edytora w celu podglądu (teren wyświetli się analogicznie jak exe, ale bez możliwości jego edycji). Tak samo Rainsted miałby być bazą dla budowania linii czy sieci trakcyjnej, którą edytor dekoracji po prostu by wyświetlał w formie podglądu. Czyli byłby to zamiennik edytora dekoracji z exe, który dla nowych sceneriii poszedłby w odstawkę.
Jeśli chodzi o sieć trakcyjną czy tory, to na tę chwilę nie przewiduję narzędzi edycjnych poza ewentualnym prototypem dla dzieciaka, żeby sobie stacje i linie budował. Czyli narzędzie nie dla inżynierów i nawet nie chcę wchodzić w szczegóły dziedzinowe. I prawdopodobnie będzie to działać tak, że odcinki będą się alignowały do rzeźby terenu i będzie automat korygujący nachylenie za pomocą modelowania rzeźbt podtorza, drążący tunele czy też dodający mosty, z jakimiś podstawowymi parametrami odcinków istotnymi dla symulacji. Coś jak w ciągnięcie torów w Railroad Tycoon, na których delikwent będzie mógł sobie pojechać Maszyną. Nie będzie to podejście ani narzędzie inżynieryjne, czyli absolutnie nie planuję tym zastąpić Rainsteda. Widzę te narzędzia jako współpracujące.
-
Tak samo chcę wyelimnować sianie trawy - to jest bez sesnu.
Na ile pamiętam, to planowałem zrobić automatyczną trawę ("pionową") na trójkątach z odpowiednią teksturą. Niestety, sypanie się symulacji i chęć dopracowania tematu organizacji sieci trakcyjnej (żeby było wiadomo, jak ją układać w edytorze, coby potem nie poprawiać) sprawiły, że kwestie trawy miały u mnie niski priorytet. Bo co z tego, że trawa będzie ładna, jeśli pociągi będą się zatrzymywać w przypadkowych miejscach i nie będzie można ukończyć misji z powodu samoorganizującej się katastrofy na drugim końcu scenerii?
Wydaje mi się, że piszesz o Rainstedzie.
Chodzi mi raczej o modele sieci trakcyjnej w MaSzynie, które trzeba by przerobić tak, aby pozycja słupa nie była sztywno powiązana z elementem trzymającym drut jezdny. Najpierw muszą być takie modele, potem trzeba zobaczyć, na ile się to sprawdza, na koniec może dopracować obsługę tego w Rainsted. Być może nie dotyczy to tego, co chcesz zrobić.
Jeśli chodzi o sieć trakcyjną czy tory, to na tę chwilę nie przewiduję narzędzi edycjnych poza ewentualnym prototypem dla dzieciaka, żeby sobie stacje i linie budował.
OK. Ja patrzę na to z perspektywy kogoś, kto ma już ułożone kilkaset kilometrów tras (czyli wiele tysięcy kilometrów torów), nawet już z jakimś tam terenem (patrz LK139) i chciałby z tym iść gdzieś na wyższy poziom, a nie dreptać wokół rozważań, jak się powinno wstawiać rozjazd, czy modelować abstrakcyjny teren.
-
OK. Ja patrzę na to z perspektywy kogoś, kto ma już ułożone kilkaset kilometrów tras (czyli wiele tysięcy kilometrów torów), nawet już z jakimś tam terenem (patrz LK139) i chciałby z tym iść gdzieś na wyższy poziom
Koncepcyjnie: jeśli leżą dekory tych scenerii, to nowe narzędzie może w tym pomóc. Jeśli najdzie kiedyś kogoś ochota na zmianę rzeźby terenu, drzew czy trawska - ma być taka opcja. Twoje oczekiwanie przejścia na "wyższy poziom" odczytuję jako zbiór zmian w EXE, i to bardziej na gruncie symulacyjno-fizyczno-inżynieryjnym, może częściowo optymalizacyjnym, a ja nie ruszam exe (z wielu powodów nie chcę). I rozumiem Cię doskonale, jednak wydaje mi się że to narzędzie nie będzie dla Ciebie.
To ma być dla tworców scenerii - designerów, nie inżynierów (jedna osoba może pełnić te role, ale nie musi), oraz (jeśli eksperyment sie powiedzie) narzędzie mogłoby zapoczątkować powstanie nowego formatu data packa na potrzeby edycji, żeby umożliwić workflow ze standardowymi narzędziami na miarę roku 2023 w kontekście modeli 3D, terenu, udźwiękawiania, tworzenia scenariuszy.
-
No i może mam trochę skrzywienie, bo ciągle przed oczami mam to:
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
-
Z mojego punktu widzenia, kwestie terenu i układania torów zostały dawno rozwiązane i nie ma potrzeby się nad nimi pochylać.
Z mojego nie. Brakuje intuicyjności, wszystko jest tępe do obsługi i wymaga szkoleń i kursów, co sam zresztą widzisz, bo sam takie kursy również organizujesz. Nie każdy będzie miał tyle czasu, a proponowanie jedynie narzędzi dla prawdziwych elit i robienia tylko i wyłącznie superrealistycznych tras na najwyższym poziomie w tempie 1km/1000 godzin będzie działać na szkodę symulatora, bo większość ludzi się odbije.
No i może mam trochę skrzywienie, bo ciągle przed oczami mam to:
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
Dlaczego twierdzisz, że to jest złe? Poza oczywiście faktem, że to nie doczekało się światła dziennego.
-
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
Narzędzie bez użytkowników jest jak sztuka bez odbiorców. Nie znam zacytowanego projektu i jego historii, może popełniono błędy już w samych w założeniach.
Moimi prerequiremenstami są stosowanie standardów i dostępnych narzędzi, multiplatform i opensource, z najmniejszym angażem programistycznym i łatwością utrzymania projektu, bo być może jutro umrę i mają być w zasięgu wzroku ludzie znający użyte narzędzia, biblioteki, frameworki, algorytmy czy formaty plików. Żadnego reinventing the wheel. Każdy custom to vendor/person lock-in i znacznie wyższe koszty developmentu. Pójdziesz na discorda Godota i znajdziesz chętnych contributorów, tylko trzymaj ich za gęby żeby nie narobili bałaganu (jak wyraźnie określisz guidelines, to każdy skrupulatny koleś będzie mógł projekt poprowadzić).
Jak eksperyment się powiedzie i community Maszyny przekona się do zmian (nie do edytora per se), to dopiero wtedy będzie sukces. Ogromny, bo ma szansę przełamać stagnację.
Obecnie MaSzyna jeszcze kogoś cieszy, ale projekt umiera. A nawet najlepszy exe bez danych jest wart całe nic. (Nowych) Danych prawie nie ma, a te co są - to porody kleszczowe.
-
Brakuje intuicyjności, wszystko jest tępe do obsługi i wymaga szkoleń i kursów, co sam zresztą widzisz, bo sam takie kursy również organizujesz.
Słuszne uwagi. A propos hajsu - jakbym mógł przekonać do ustandaryzowanych data packów np w PCK, i Maszynę dałoby się w końcu modować, to robi się rynek zbytu na płatne mody nie tylko dla przemysłu, ale i rozrywki. Maszyna wisi na steamie jako coming soon (z tym co jest aktualnie, to jest nevercoming zaczynający się od braku sensu). Ale to już offtopic, sorry.
-
Płatne dodatki z kolei stoją w sprzeczności z licencją MaSzyny. Ale to już temat na oddzielny wątek.
-
Jeden temat mniej.
-
Nie każdy będzie miał tyle czasu, a proponowanie jedynie narzędzi dla prawdziwych elit i robienia tylko i wyłącznie superrealistycznych tras na najwyższym poziomie w tempie 1km/1000 godzin będzie działać na szkodę symulatora, bo większość ludzi się odbije.
Jak ktoś nie ma czasu, to po co mu symulator? Można pograć w Bobry, podobno fajna gra. ;) I własne plansze też można robić, nie jest to bardzo wymagające. Większość ludzi chyba już się odbiła. I raczej nie przeze mnie, bo przez ostatnie 8 lat się nie wtrącałem. Każdy mógł robić, co tylko chciał i zachwycić innych swoją własną wizją rozwoju.
Dlaczego twierdzisz, że to jest złe? Poza oczywiście faktem, że to nie doczekało się światła dziennego.
To nie jest złe, to jest edytor plansz do gry. Nie wymaga od użytkownika żadnej wiedzy o budownictwie kolejowym ani odniesień do rzeczywistości. Po prostu klikasz i po chwili możesz mieć własne Bizonowo. W dalszej kolejności można by dodać losowe wstawianie wskaźników i lokomotywy sterowane strzałkami.
-
Nie wymaga od użytkownika żadnej wiedzy o budownictwie kolejowym ani odniesień do rzeczywistości
Edytor scenerii (dekorów, scenariusza, assetów) nie jest dla tych osób. Od tego jest specjalistyczne oprogramowanie typu Rainsted. Nikt nie robi rysunku technicznego w paincie (choć można), ani nie maluje tekstur w CAD/CAM (choć pewnie można).
A że ktoś wyklika Bizonowo, to jego sprawa. Przecież nik nie zabrania zrobić tego obecnie z użyciem Notepada++ i wyobraźni, a jakoś nikt Notepada nie piętnuje…
-
Koledzy, ciekawy wątek. Liczę, że w niedługim czasie będzie liczył 20 stron. Czytam go głownie w drodze do i z pracy - czas szybko mija.
-
Dlatego ja mam cały algorytm "heurystyczny", który przy wczytywaniu SCN próbuje zgadywać, co jest czym
Obserwacja: parser SCN/INC w EXE omija nieznane tokeny i nie wywala się. Umożliwia to opakowanie istniejących plików w nowe konstrukcje bloki typu terrain..endterrain, czy foliage..endfoliage. Dla exe to zbędne, ale dla edytora - cenna informacja. Tym sposobem można częściowo klasyfikować elementy sceny. Dla plików include będących kompozycją modelu, eventów i dźwięków (bodaj zwrotnice tak są przygotowane) , można wprowadzić jednoargumentową dyrektywę `item_type` lub po prostu `class`.
Zakładając że żaden edytor nie wywali tych tokentów, można byłoby wprowadzić je do istniejących plików scenerii. Nie trzeba byloby już zgadywać co jest czym.
EDIT: Działa pięknie. EXE jest nienaruszone tymi dyrektywami. Czas konwersji spadł z minut (stary jawor) do sekund. Oczywiście z pominięciem importu terenu i trawsk. Teraz mogę zrobić z tymi sekcjami cokolwiek\. Z tego odkrycia zrobiłbym standard i w obecnym data packu dyrektywy dodał. Exe mogłoby zrobić z tego użytek, szczególnie przy SBT (można opuścić wszystko od terrain do endterrain).
-
Nie każdy będzie miał tyle czasu, a proponowanie jedynie narzędzi dla prawdziwych elit i robienia tylko i wyłącznie superrealistycznych tras na najwyższym poziomie w tempie 1km/1000 godzin będzie działać na szkodę symulatora, bo większość ludzi się odbije.
Jak ktoś nie ma czasu, to po co mu symulator? Można pograć w Bobry, podobno fajna gra. ;) I własne plansze też można robić, nie jest to bardzo wymagające. Większość ludzi chyba już się odbiła. I raczej nie przeze mnie, bo przez ostatnie 8 lat się nie wtrącałem. Każdy mógł robić, co tylko chciał i zachwycić innych swoją własną wizją rozwoju.
Jeżeli ogarnięcie edytora będzie zajmowało godzinę-dwie, a nie wiele dni/tygodni, to już samo w sobie może przynieść duże oszczędności czasu na przyszłość. A na pewno użytkownikowi końcowemu będzie się bardziej chciało.
Dlaczego twierdzisz, że to jest złe? Poza oczywiście faktem, że to nie doczekało się światła dziennego.
To nie jest złe, to jest edytor plansz do gry. Nie wymaga od użytkownika żadnej wiedzy o budownictwie kolejowym ani odniesień do rzeczywistości. Po prostu klikasz i po chwili możesz mieć własne Bizonowo. W dalszej kolejności można by dodać losowe wstawianie wskaźników i lokomotywy sterowane strzałkami.
Nie no, nie idźmy w tą stronę. Co bym sobie wyobrażał to liczne kontekstualne podpowiedzi (np. opisy obiektów, gdzie co się stawia, itp.), a co z tym użytkownik zrobi to już jego sprawa. Jakieś ważniejsze/podstawowe wyciągi z zasad projektowania linii kolejowych. Coś a'la http://www.kontrakt-bhp.com.pl/paul/projektowanie/ (swoją drogą - bardzo polecam), ale zintegrowane w edytor i częściowo zautomatyzowane (np. kalkulator prędkości na torze o zadanym promieniu).
-
Work in progress. Tak, przez te lata nazbierało się trochę quirków w obsłudze plików inc czy materiałów, i sporo nie mam jeszcze uwzględnionych.
Fine tuning importu trochę potrwa. Mesh terenu merguję. Zieleninę wczytuję - jeszcze jako dziesiątki tys includów każdego krzaka.
Obiecany diagram koncepcyjny:
(https://eu07.pl/forum/index.php?action=dlattach;topic=35181.0;attach=157636)
-
Mi się podoba sposób edycji torów w symulatorze makiet EEP (ostatnia wersja którą widziałem to 8) To jest coś pomiędzy edytorem Trainza a skryptami do 3ds max. Można sobie ręcznie giąć promień łuku jak w Trainz albo wpisać z palca wartości. Są też dostępne popularne szablony rozjazdów. Można nawet sobie generować części głowicy rozjazdowej. Ciekawą opcją jest też kopiowanie toru (można do przodu dokleić taki sam tor, ale najciekawszą moim zdaniem opcją jest możliwość generowania sąsiedniego toru z zadanym odstępem między torami.
-
Cześć.
Nagrałem kolejny preview z postępów prac. Tym razem jest zalążek tego, czego nie miało być w pierwszych wersjach - edycja i eksport torów, a właściwie dowolnych node tracków (tory, drogi, rzeki, itp). Sama serializacja była formalnością, bo node track jest w miarę prosty.
W tym miejscu chcę nadmienić, że tory są w Maszynie bardzo fajnie przemyślane. Niby proste, ale zasada ciągłości toru oparta o współrzędne punktów daje bogate możliowości budowania niezależnych obszarów i łączenia między nimi linii. Gdyby EXE obsługiwało jakiś rodzaj streamingu, to można byłoby przejechać Polskę wzdłuż i wszerz :)
Edytor nadal jest w edytorze (jako editor plugin do Godot Editor), jednak docelowo tak nie pozostanie - są pewne ograniczenia i zbyt wiele można zepsuć, ale na prototyp / proof-of-concept póki co wystarcza. W tej chwili najważniejsza jest obsługa wszystkich obiektów występujących w Symulatorze, tak import jak i eksport. Dopiero mając ten "klocek" będę pracował nad docelowym UI edytora.
Ponieważ obawiam się że nadwyrężę zasady forum tymi postami, a chcę co jakiś czas wrzucać informacje o postępach, to założyłem dedykowany serwer na Discord: https://discord.gg/ArkzuXGP
-
Spoko, możesz tu pisać. Można też założyć osobny kanał publiczny u nas na czacie. :)
-
No i może mam trochę skrzywienie, bo ciągle przed oczami mam to:
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
No to w pewnym sensie zostałem wywołany do tablicy (chyba nikogo więcej z tamtej ekipy tu nie ma oprócz matek__9292), bo między innymi ja brałem w tym udział. Założenia były jakie były, wyszło z tego co wyszło.
Nie chciałbyś Ty, żeby wyszło takie narzędzie, ale myślę, że większość społeczności ma odmienne zdanie. Bo patrząc ile scenerii wychodzi z takich edytorów jak w Trainz czy TD2, a ile wychodzi w MaSzynie, to odpowiedź jest prosta - obecne narzędzie jest za trudne, nieintuicyjne i pewnie na palcach dwóch rąk da się policzyć ludzi, którzy je ogarniają. Gracze chcą prostego, przejrzystego układania torów i rozjazdów - click i jest. Teren pędzlem, tekstury pędzlem, rozwinąć sieć, postawić semafory, domki, trawę nasiać z drzewami, rozwinąć płoty z peronami i jazda. I można zaklinać rzeczywistość, ale tak jest. Naprawdę w nosie mam, czy jest zrobiona porządnie krzywa przejściowa (pozdrawiam nadgorliwców z TD2), czy inne rzeczy i pewnie większość młodzieży też (widać po FB jaka średnia wieku komentuje). Na to i tak w większości przypadków nikt nie będzie zwracał uwagi, tylko jeździł i cieszył się z całości scenerii.
Za to można się latami "podniecać" cudownym narzędziem, który pozwala ułożyć tory co do mm jak w rzeczywistości, generatorem terenu co do centymetrów, a efektu w postaci finalnych scenerii od kilku, może i nawet kilkunastu lat brak.
-
Nie chciałbyś Ty, żeby wyszło takie narzędzie, ale myślę, że większość społeczności ma odmienne zdanie.
No OK, nie widzę przeciwwskazań, żeby powstawały super trasy, zrobione przez ludzi w dwie godziny, po wcześniejszych dwóch godzinach zapoznawania się z edytorem. Być może jest to możliwe — ja poświęciłem kilkanaście tysięcy godzin na tworzenie edytora oraz tras w nim, a nadal nie umiem tego robić dobrze. Chyba jedynie nie chciałbym, żeby taki edytor plansz do gry był uznawany za główne narzędzie do tworzenia tras do symulatora. Ale być może zbytnio i niepotrzebnie zasugerowałem się, że ktoś chce zrobić jakiś faktyczny symulator czegoś, a nie grę o pociągach.
Naprawdę w nosie mam, czy jest zrobiona porządnie krzywa przejściowa (pozdrawiam nadgorliwców z TD2), czy inne rzeczy i pewnie większość młodzieży też (widać po FB jaka średnia wieku komentuje). Na to i tak w większości przypadków nikt nie będzie zwracał uwagi, tylko jeździł i cieszył się z całości scenerii.
Ja widzę różnicę pomiędzy jazdą po łuku z krzywą przejściową, a łukiem, gdzie jej nie ma. Gdyby w MaSzynie była lepsza fizyka bujania kabiną (której nie zdążyłem zrobić), to brak krzywej przejściowej byłby dla wszystkich oczywisty i zauważalny. Jeśli komuś nie zależy na realizmie symulacji, to równie dobrze może pograć w Timberborn, tam się łatwo plansze edytuje i na ile oglądałem (bo jeszcze nie zdążyłem zagrać), bardziej wciąga niż pociągi — polecam.
Za to można się latami "podniecać" cudownym narzędziem, który pozwala ułożyć tory co do mm jak w rzeczywistości, generatorem terenu co do centymetrów, a efektu w postaci finalnych scenerii od kilku, może i nawet kilkunastu lat brak.
Tory zostały ułożone około 2013 roku, kolej piaskowa, prawie całe dolnośląskie, trasa z Katowic do Herbów, z Łodzi do Torunia... Ale się symulacja sypała i pociągi wariowały, więc nie było sensu tego udostępniać (tzn. np. autor miał wątpliwości, a ja nie nalegałem). A potem zostałem uznany za hamującego rozwój sabotażystę, zarzucono mi, że chcę produkować komercyjne pulpity i następnie pobierać opłaty za lepszą wersję MaSzyny. W końcu się udało wyprowadzić kod MaSzyny poza licencję MaSzyny, dzięki czemu podobno MaSzyna "zaczęła się rozwijać zgodnie z oczekiwaniami użytkowników". No i było 8 lat na to, żeby udowodnić mi, jak bardzo się myliłem. Nikomu nie broniłem zrobić wspaniałego edytora i robić trasy nim. Ba, nadal można to robić, ja chętnie zapoznam się z efektami.
-
Chyba jedynie nie chciałbym, żeby taki edytor plansz do gry był uznawany za główne narzędzie do tworzenia tras do symulatora.
Edytor Scenerii współpracuje i będzie współpracował z profesjonalnymi trasami roboionymi w profesjonalnym narzędziu - Rainsted, dopóki ten ostatni wygeneruje kompatybilny plik (obecnie INC z node::track). To że Edytor może mieć opcję alternatywnego tworzenia czy modyfikowania tras nie koliduje z innymi narzędziami.
Co jest głównym narzędziem dla danej scenerii, niech decyduje już sam twórca scenerii. Nadto otwiera się możliwość prototypowania tras, a w dalszych etapach ich finetuningu. Workflow jest elastyczny dzięki elastyczności plików symulatora.
-
Kibicuję mocno temu projektowi, sam próbowałem zrobić prosty edytor WYSIWYG w blenderze - trzeba było nieźle się gimnastykować żeby zaimplementować pewne rzeczy ale zabawa była przednia. Ja zatrzymałem się na wizualizacji torów z szynami oraz wizualizacji modeli. Podjąłem też pewne prace pod kątem generycznego rozwiązania dla wizualizowania zawartości plików INC, ale nie skończyłem.
Wymyśliłem se nawet pseudo streamer który miał wczytywać kod scenerii i sortować wpisy obiektów geograficznie. Sceneria miała być podzielona na sekcje odpowiadające rozmiarowi sekcji zaszytej w exe. Każda sekcja miała mieć swój bufor tekstowy, który wczytywałby zapisane w nim obiekty na żądanie. Po edycji obiektów byłaby możliwość zrzucenia tego z powrotem do postaci tekstowej. W ten sposób chciałem oszczędzić pamięć a także czas na tworzeniu wizualnej reprezentacji obiektów w blenderze, bo o ile sam import tekstu trwał śmiesznie krótko, to po dodaniu na to generowania geometrii czas zaczął się wydłużać niemiłosiernie. W połączeniu z możliwością odpalenia podglądu scenerii z poziomu blendera miało to dać oszczędność czasu na dokonywaniu małych poprawek, bo nie było by potrzeby odpalania całej scenerii za każdym razem, a jedynie jej fragment. Blender oczywiście totalnie nie nadaje się na edytor scenerii, ale ile zabawy miałem przy wymyślaniu takich fikołków xD No i niejako efektem ubocznym tego przedsięwzięcia było przeoranie całej maszynowej dokumentacji sceneriowej, z której zapewne intensywnie korzystasz, więc fajnie że przynajmniej w ten sposób ten projekt miał jakiś sens rozwojowy.
-
Kibicuję mocno temu projektowi,
Mersi. Ja też kibicuję. Szczególnie żeby było jeszcze ze dwóch aktywnych cotnributorów :)
zatrzymałem się na wizualizacji torów z szynami oraz wizualizacji modeli
Wyglądaly bardzo dobrze!
miał wczytywać kod scenerii i sortować wpisy obiektów geograficznie. Sceneria miała być podzielona na sekcje odpowiadające rozmiarowi sekcji zaszytej w exe
W tym temacie mam pewne przemyślenia i jakieś próby, bo rzeczywiście duże sceny potrafią zamulić edytor Godota (ma jeszcze nieoptymalne implementacje paru operacji na drzewie obiektów sceny).
Edytor może budować sektory w runtime, albo może też budować je podczas importu, a scalać do układu źródłowego podczas eksportu. Może to się dziać wewnętrznie bez udziału i informowania użytkownika.
Teoretycznie edytor mógłby zmienić układ plików INC a nawet narzucać porządek. Nie jestem jednak przekonany czy to będzie dobre, więc zostawiam rozważania o tym na później.
Performance badam na scenach: E. Dobre, Zwierzyniec, Stary Jawor, Galicja (tu teren przekształcony do plików Godota wczytuje się w mig, ale drzewa i trawy strasznie męczą).
Z pewnością zrobię markery dla designerów, żeby mogli szybko teleportować się do zapisanych miejsc, bo latanie po scenerii jest stratą czasu. No ale to co innego.
W połączeniu z możliwością odpalenia podglądu scenerii z poziomu blendera miało to dać oszczędność czasu na dokonywaniu małych poprawek, bo nie było by potrzeby odpalania całej scenerii za każdym razem
Tak. To też chcę osiągnąć. Chyba że ktoś zrobiłby hot-reloading do EXE, jednak wątpię że to nastąpi - za dużo przeróbek procesu wczytywyania/parsowania plików. Na tę chwilę rendering jednak się różni. I o ile fejsy, normalmapy, inny model oświetlenia i inne shadery można olać myśląc o operacjach dużego kalibru (zalesianie, dodawanie budynków, a nawet prowadzenie dróg), to kiedy zaczynasz kłaść rzekę czy drogę, która inaczej się rysuje na terenie, to nie da się jej dokładnie ustawić i narzędzie nie jest już WYSIWYG. Dlatego jednak chcę/muszę zbliżyć się z renderingiem do EXE, a z tyłu głowy mam narzędzie do edycji terenu, które automatyzowałoby dostosowywanie jego rzeźby do koryta rzeki, wyrównywałoby teren pod drogę, czy też (jeśli konieczne) robiło most czy tunel.
Przemkła mi nawet myśl zaadaptowania renderera EXE jako alternatywnego renderera dla Godocta (jest taka możliwość), tyle że oceniam to zadanie na zbyt czasochłonne, choćby przez konieczny decoupling renderera od symulacji i jego refaktoryzację do pracy na encjach i materiałach godotowych. Wolę zbliżyć się do wyglądu EXE custom shaderami w Godocie.
niejako efektem ubocznym tego przedsięwzięcia było przeoranie całej maszynowej dokumentacji sceneriowej, z której zapewne intensywnie korzystasz, więc fajnie że przynajmniej w ten sposób ten projekt miał jakiś sens rozwojowy.
Tak, korzystam prawie codziennie z dostępnych materiałów. Przydaje się :) A to czego nie pokrywają (pewnie coś zmieniało się w czasie), muszę uzupełniać czytaniem źródeł exe.
-
Tak, korzystam prawie codziennie z dostępnych materiałów. Przydaje się :) A to czego nie pokrywają (pewnie coś zmieniało się w czasie), muszę uzupełniać czytaniem źródeł exe.
Jak przeczytasz coś nowego to dopisz na Wiki, niech ta dokumentacja żyje bo ja ostatnio nie mam czasu ani weny na szamynę :)
-
Czy prace na tym projektem zostały wstrzymane czy projekt został zaniechany?