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.
