Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Edytor Scenerii
marcinn:
--- Cytat: Ra w 25 Września 2023, 17:25:29 ---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.
--- Koniec cytatu ---
Dokładnie tak powinno być.
--- Cytuj ---format tekstowy robi więcej problemów niż daje korzyści
--- Koniec cytatu ---
Ż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ę.
--- Cytuj ---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.
--- Koniec cytatu ---
https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-2-terrain-rendering-using-gpu-based-geometry
Ra:
--- Cytat: marcinn w 25 Września 2023, 17:41:14 ---Grzebanie w uszkodzonej binarce to w praktyce oznacza koniec - porzucenie lokalnych zmian i przywrócenie poprzedniej wersji.
--- Koniec cytatu ---
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).
marcinn:
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.
Ra:
--- Cytat: marcinn w 25 Września 2023, 20:49:25 ---Mnie chodzi o to, że proste fixy (oraz review) idzie zrobić właśnie na tekście, plus do tego tekst jest scm-friendly.
--- Koniec cytatu ---
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...
--- Cytat: marcinn w 25 Września 2023, 20:49:25 ---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.
--- Koniec cytatu ---
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.
--- Cytat: marcinn w 25 Września 2023, 20:49:25 ---Ogólnie widać 20 lat długu technicznego.
--- Koniec cytatu ---
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.
marcinn:
--- Cytat: Ra w 26 Września 2023, 00:21:18 ---Kto miałby to robić? Chociaż ja mogę mieć skrzywione postrzeganie, bo patrzę głównie na geometrię torów.
--- Koniec cytatu ---
Nie wiem. Obecnie chyba mało kto cokolwiek robi.
--- Cytuj ---za duży próg wejścia
--- Koniec cytatu ---
Ogólnie jest za duży próg wejścia i mocno specyficzny workflow.
--- Cytuj ---z tych samych niedopracowanych cegiełek, które nie zachowują spójności i są źródłem błędów...
--- Koniec cytatu ---
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).
--- Cytuj ---To jest dopiero początek zamieszania... Dlatego ja mam cały algorytm "heurystyczny", który przy wczytywaniu SCN próbuje zgadywać, co jest czym.
--- Koniec cytatu ---
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.
--- Cytuj ---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ą.
--- Koniec cytatu ---
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:
Nawigacja
[#] Następna strona
Idź do wersji pełnej