Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Pokaż wątki - marcinn

Strony: [1]
1
Poszukuję, chcę zrobić / Edytor Scenerii
« dnia: 06 Marca 2023, 02:24:06 »
Cześć.

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

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

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

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

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

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

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

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

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



2
Bieżące kolejowe / Farby i kolory
« dnia: 03 Października 2022, 18:44:02 »
Cześć.


  • Jaka farba (najlepiej spray) będzie zbliżona do tej starej szarej z pierwszego zdjęcia (wg RAL)?
  • Co to za rodzaj farby / lakieru, którą pokryta jest sklejka z drugiego zdjęcia? Powierzchnia jest śliska, gładka - bez faktury. Czy to może być laminat?
  • Jakiej zielonej farby (najlepiej wg RAL) użyto do pomalowania aparatury z trzeciego zdjęcia?


Za odpowiedzi serdecznie dziękuję z góry. Raczej nie będę odpowiadał żeby nie nabijać postów, ale rozdam polubienia.

3
Tabor kolejowy / Terminal MTE-15 i coś jeszcze
« dnia: 03 Października 2022, 13:11:57 »
Cześć.

Co to za urządzenie obok MTE-15, i czy współpracowało z MTE-15?
Jaką funkcję spełnia MTE-15, tzn. jak się go na PKP używa? Jako tachograf i/lub ewentualnie gps?

Zdjęcia proszę załączać jako załącznik, ewentualnie na upload forum.
Matek123


4
Bieżące Symulatorowe / [Linux] UART błąd synchronizacji?
« dnia: 09 Maja 2021, 04:18:50 »
Witajcie.

Jestem po dosyć długiej diagnostyce problemów komunikacji z Maszyną.
Wydaje mi się, że synchronizowanie ramek nie działa. Tzn. działa, ale łapanie synchronizacji jest dziełem przypadku i zależy od kompilatora.

W momencie kiedy Maszyna gubi synchronizację, zaczyna czytać bajt po bajcie. Preambuła sprawdzana jest tak:

                if (sc == 0xEF)                                                                     
                        sync_cnt++;   

Jednak zmienna "sc" zdefiniowana jest jako char, a char jest signed:

    char sc = 0;


Skutkuje to (przynajmniej u mnie) pomijaniem bajtów "0xEF" i "zmęczeniem" synchronizacji ze względu na przekroczoną ilość prób.
Może ktoś będzie w stanie to potwierdzić. U siebie zmieniłem na unsigned char i widzę poprawę.
 
PS. Wrzucam na tę chwilę na forum, bo zgodnie z odp. PW od Milek7 najpierw trzeba dogadać komu (do którego forka i której gałęzi) podrzucać PR. Poza tym wydaje mi się, że kompilator VS (dla Windows) może dawać ten sam efekt, co czyniłoby błąd raczej krytycznym (dla korzystających z pulpitów).

Strony: [1]