Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Edytor Scenerii
marcinn:
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
matek123:
--- Cytat: marcinn w 06 Marca 2023, 02:24:06 ---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.
--- Koniec cytatu ---
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ą.
marcinn:
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.
Sm 42 driver:
--- Cytat: marcinn w 06 Marca 2023, 02:24:06 ---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.
--- Koniec cytatu ---
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.
marcinn:
--- Cytat: Sm 42 driver w 07 Marca 2023, 21:36:25 ---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.
--- Koniec cytatu ---
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.
Nawigacja
[#] Następna strona
Idź do wersji pełnej