Wiadomości

1

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 12 Października 2023, 21:02:21 »

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.

2

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 11 Października 2023, 21:09:37 »

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.

3

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 09 Października 2023, 00:10:53 »

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

4

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 30 Września 2023, 01:56:08 »

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:

5

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 22:26:33 »

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

6

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 21:14:55 »

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…

7

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 20:53:55 »

Jeden temat mniej.

8

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 20:18:18 »

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.

9

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 20:08:52 »

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.

10

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 17:38:54 »

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.

11

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 16:39:47 »

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.

12

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 15:52:20 »

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.

13

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 13:10:25 »

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

14

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 26 Września 2023, 03:24:10 »

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:

15

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 25 Września 2023, 20:49:25 »

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.

16

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 25 Września 2023, 17:41:14 »

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

17

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 25 Września 2023, 16:32:37 »

Planowałem w 2015 roku wczytywanie z RSF do MaSzyny, po czym ktoś uznał, że nie warto tego robić

Ja się nie wypowiem w kwesti adaptacji RSF w EXE. Problemy z SCN są i uważam, że można je rozwiązać tylko wymianą SCN na format dostosowany do doczytywania sekcjami (teoretycznie tekstowe SCN też by obleciały, ale mają trochę ograniczeń i nie mogłyby być edytowalne - szkoda zachodu, IMO). Nie lubię wynajdować kół na nowo, więc jestem za adaptacją sprawdzonych rozwiązań. Jeśli RSF jest dobrym kandydatem, to nie mam nic przeciwko. Jednak nie podejmę się implementacji w EXE. Mogę tylko coś sugerować.

Natomiast nie widzę przeszkód, żeby zrobić wyrzut z edytora do RSF. Sam edytor powinien pracować na plikach tekstowych, które są przyjazne dla człowieka i VCS typu Git. To że Maszynowe pliki SCN/INC nie są zbyt dobre do edycji, to już inna kwestia. Traktuję je jako źródło, edytor będzie zapisywał sceny po swojemu, a eksport mogę zrobić do czegokolwiek. To otwiera ciekawe możliwości, np. edycję torów Rainstedem i dekorowanie scenerii w nowym edytorze bez konieczności odpalania symulacji, mając do tego hot reloading. A gdyby pracować sektorami, i gdyby dało łączyć się tory między sektorami, to nawet całą Polskę można było zamodelować kwadrat po kwadracie ;)

Przy okazji - czy podtorze generuje Rainsted? Scala je z rzeźbą terenu?


PS. Ciekawostka: rzeźba terenu na niewielkim Zwierzyńcu składa się z ~10 tys elementów. Nie jest to najbardziej optymalny układ ani dla exe (exe scala i dzieli na sektory), ani dla edytora (bez scalania nic z tym w praktyce nie idzie zrobić). Dwoma kolejnymi węzłami o ciężkości ponadprzeciętnej ze względu na liczebność elementów, w tym trudność edycji, to drzewa i trawa. Te trzy elementy powinny być traktowane specjalnie i to już na poziomie edycji, z czego terenu na razie nie dotykam.

18

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 25 Września 2023, 14:03:08 »

exe skleja wszystkie trawki o jednym materiale w jedno.

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

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

19

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 25 Września 2023, 03:45:41 »

Odczytałem wstępnie pliki scn w Godot (całe levele, jeszcze bez torów). Na szybko wnioski: dopóki trawy, drzewa i inne złogi węgla będą wczytywane za pomocą includes z trójkątami, i zamiast jednego mesha obiekty będą poskładane z dziesiątek kąsków, to będzie lipnie z czasem ładowania a nawet renderingiem. A że format plików nie nadaje się do wczytywania sektorami, to ilość elementów powinna być jak najmniejsza. Edytora nie trzeba będzie pisać, bo Godot Editor daje się mocno rozbudowywać. Trzeba jednak ogarnąć edycję sektorami, bo edytor zamula przy rozbudowanych scenach.

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

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

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

20

Bieżące Symulatorowe / Odp: Potencjalne zmiany w zarządzaniu projektem

« dnia: 12 Września 2023, 14:24:53 »

Co do pobierania dodatków przez starter, to przecież jest taka możliwość w programie od @ra, tylko kto w efekcie z tego korzysta?

Najpierw regular user musiałby korzystać z Rainsteda. Narzędzia które powstają do Maszyny nie są cross platform. Np. ja mam prymitywny starter zrobiony w pythonie i odpalam z terminala.
Mamy exe cross platform, ale soft do odpalania tego exe - nie.

Addon manager, dla ułatwienia sprawy, mógłby być oddzielnym programem, który byłby w paczce. Natomiast problem z dodatkami jest taki, że ich instalacja jest względnie prosta, ale ich pliki mieszają się z bazowymi. Łatwo też o konflikty. Wolałbym pokombinować żeby addonsy miały swoje subfoldery np. w addons/ czy mods/, choć to wymagałoby sporych zmian w exe i nie wiem jak bardzo byłoby możliwe.

Ale addon manager będzie potrzebował serwera. To może być centrala (jak PyPI,  NPM, Docker Hub itp - pytanie kto to będzie utrzymywal i za czyje pieniądze), albo jak proponowałem wcześniej - autorzy paczek mogliby wrzucać wydania gdziekolwiek i być w pełni odpowiedzialni za utrzymanie storage (za jego dostępność i opłaty). Centrala byłaby wygodniejsza dla autorów paczek, ale kiedy myślę o przechowywaniu różnych wersji takich dodatków, to szybko możemy pójść w terabajty. Dziś autorzy paczek hostują je "gdzieś tam", więc można to podtrzymać, a tylko zrobić cetralny indeks tychże.

21

Bocznica / Odp: [HIT] Bieszczady/Galicja WIP - do pobrania

« dnia: 04 Września 2023, 23:19:08 »

Popraw i podeślij autorowi.

Snailem? Wolałbym wrzucić commit. Względnie patcha sendmailem.

22

Bieżące Symulatorowe / Odp: Potencjalne zmiany w zarządzaniu projektem

« dnia: 04 Września 2023, 20:45:38 »

1. Dodatki
- Oddzielny manager dodatków.
- Rozważyć, czy exe nie powinien dodatkowo obsługiwać nowych ścieżek do addonsów (w schemacie addons/<id>/<wszystkie pliki dodatku>)
- Website z dodatkami (właściwie indeks, content mógłby leżeć gdziekolwiek)
- Ocena dodatków przez community bez względu na autorstwo
- Moderowanie dodatków po zgłoszeniu naruszenia zasad

2. Exe
- Jedno docelowe repozytorium dla exe
- Wyznaczyć cele makro (żeby wiedzieć co warto, a czego nie warto robić z exe)
- Wyznaczyć więcej osób do review i mergowania PR
- Usprawnić cykl wydawniczy (dev buildy, stable buildy, release branche do testow i stabilizacji) - ten punkt ma zabezpieczyć przed wejściem na stable nieewidentnych baboli

Ad. 2
Co wracam do exe, to rozbijam się o nieustalony coding standards i nieprzeformatowany kod, co utrudnia merge / rozwiązywanie konfliktów. Mam też uwagę, że źródła są prawie płasko w jednym katalogu - przydałby się sensowniejszy podział na podkatalogi (zrobiłem próbę czegoś takiego - kompiluje się, a lata się po plikach wygodniej). Przed zaproszeniem większej liczby osób warto byłoby to ogarnąć.

Fantazje: ponieważ kręcę się wokół tematu edytora, chciałem użyć renderera/engine. Ten jest mocno powiązany z elementami symulatora, co też trzeba byłoby nieco ruszyć. Myślałem też o hot reloading, ale to wymagałoby zmiany sposobu wczytywania danych (parser) oraz wprowadzenia drzewa obiektów (hot reload wybranej gałęzi lub pojedynczych węzłów - ściśle związane z tym jak tworzone są pliki z danymi, szczególnie scn). Z tyłu głowy wisi refaktoryzacja buttonow/gauges, o której gadane było z rok temu i roboty miało być na dwa lata.

Niestety na chwilę obecną ciągle odbijam się od poczucia że jest ogrom roboty, którą nie wiadomo czy warto zaczynać. Stąd punkt o celach. Bo może nie ma sensu robić rewolucji?

EDIT: Dotarłem w końcu do paczki z Galicją. Jestem pod wrażeniem tego projektu, talentu i zawziętości Twórców. Po instalacji oczywiście nie działa, a oprócz customowego exe win-only czas wczytywania się jest kosmiczny. Tzn. jeszcze niczego nie udało mi się wczytać, więc oglądam sobie screeny i filmiki na YT. Dopisałbym do listy fantazji jakiś level streaming.

23

Na warsztacie / Odp: [HIT] Bieszczady/Galicja WIP - do pobrania

« dnia: 04 Września 2023, 22:52:09 »

Różni się tym, że została dodana obsługa PBRa (@MichauSto), efekt Bloom (@MichauSto), możliwość obrotu w 3 osiach w edytorze i różne pomniejsze bajerki (Dymy od Toprusa, ładniejsza mgła czy bieda-rzucanie kamerą na rozjazdach i łączeniach szyn).

Nie zostało to zmergowane do upstreama?
EXE w paczce jest windows-only. Co z innymi platformami?

EDIT: Stosujecie różne wielkości znaków w nazwach plików. O ile wiem na Windowsie to nie robi różnicy, ale na innych (file)systemach może to generować problemy - pliki nie będą odnalezione i coś się nie wczyta.
EDIT2: Jeden scenariusz się w końcu odpalił i powiem tylko tyle, że takich scenerii w Maszynie jeszcze nie widziałem, mimo standardowego exe. Drzewa i pagóry robią robotę. I słupy.

24

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 01 Września 2023, 00:17:19 »

Popieram jednak bve2 pod tym względem, że największą bolączką scenerii jest dekorowanie.

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

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

25

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 29 Sierpnia 2023, 23:51:35 »

Cześć.

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

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

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

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

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


Pozdrawiam,
Marcin

26

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 08 Marca 2023, 13:20:58 »

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

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

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

27

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 08 Marca 2023, 12:03:37 »

Temat nie osiągalny. Rainsted korzysta ze swojego formatu plików roboczych.

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

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?

28

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 08 Marca 2023, 01:28:38 »

Osobiście, jako twórca, z dużą rezerwą patrzę na sytuację, w której osiągnęliśmy pewien poziom dokładności oferowany przez narzędzia edytorskie a następnie będziemy iść w uproszczenia czyli wrócimy do czasów przed powstaniem/wykorzystaniem obecnie stosowanych narzędzi.

Cieszę się, że poruszyłeś te aspekty. Zakładam podejście, które chyba zbyt słabo zaznaczyłem w pierwotnym tekście:

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

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

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

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

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

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

29

Poszukuję, chcę zrobić / Odp: Edytor Scenerii

« dnia: 06 Marca 2023, 19:47:08 »

TGA jest obsługiwane także w runtime. Czy w runtime - dopiero potwierdzę, ale nawet jak nie, to się przerobi.

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

Long story short - nie przejmowałbym się tym. Wyzwaniem będzie edycja dużych scen i trzeba będzie zrobić chunking.

30

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