Nie wiem. Obecnie chyba mało kto cokolwiek robi.
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.
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.
Format RSF jest raczej pośrednim pomiędzy SCN, a tym, co by można było zoptymalizować pod silnik graficzny. Na poziomie edytora RSF obiekty typu "include" są osobnymi obiektami. Wczytując taki RSF do MaSzyny, należałoby nadal parsować pliki INC, z odpowiednimi parametrami (ale pobranymi już z RSF). Jednak można również utworzyć RSF, w którym będą zapisane elementy składowe z plików INC, wtedy dodatkowe parsowanie będzie zbędne (zyskuje się szybkość wczytania kosztem wielkości pliku i uniwersalności) — plus jest też taki, że wtedy wiemy z góry, ile będzie obiektów i ile łącznie zajmą pamięci, co potem upraszcza wyrzucenie tego, gdy przestaje być potrzebne.
Jak mi kolega pisze, że żeby Galicję przetestować / udekorować odpalają scenariusz bitą godzinę, to tylko pozostaje mi podziwiać za wytrwałość.
No to i tak jest po wielu optymalizacjach. Oryginalnie obiekty były wyszukiwane w listach jednokierunkowych. 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ą. Opracowałem format binarny dla modeli, żeby ich nie parsować cyferka po cyferce i nie liczyć potem wektorów normalnych za każdym razem. Przerobiłem algorytmy wyszukiwania, żeby łączenie torów szukało tylko w najbliższej okolicy, a nie po wszystkich wczytanych torach. No i finalnie doszedłem do wniosku, że to parsowanie plików tekstowych oraz każdorazowe wyszukiwanie powiązań to droga donikąd i trzeba to robić inaczej. Na przykład wczytać informację o obiektach binarnie i znać liczbę obiektów z góry, żeby potem móc je usunąć i wczytać obiekty z innego miejsca (dlatego nie chciałem się angażować w robienie pasków postępu wczytywania). No ale pisk się zaczął, że potrzebne są głównie światła i cienie, a nie jakieś tam optymalizacje.
Swoją drogą zrozumiałem, że INC-e z parametrami działają na zasadzie preprocesora.
Tak. Co gorsza, jest to robione na wczesnym etapie parsera, więc w czasie wczytania nie jest nijak wiadomo, że dane obiekty są zgrupowane np. w ramach semafora (chyba że ktoś to jakoś przerobił ostatnio). W efekcie edycja na poziomie MaSzyny nie jest w stanie wyprodukować zestawu danych, który można by zapisać i ponownie wczytać. A przynajmniej format nie jest... jakby to powiedzieć... odwracalny?
Oczyma wyobraźni widzę, jak to mogłoby pchnąć rozwój.
Przede wszystkim musisz wiedzieć, po co to robisz. ;) Mi głównie zależy na tym, żeby moja dotychczasowa praca się nie zmarnowała. Więc mogę się dzielić moim punktem widzenia i opisywać moje rozwiązania. Ale, póki co, nie czuję potrzeby, żeby robić coś więcej (tzn. pisać jakiś kod). Jeśli będą potrzebne zmiany w zakresie formatu RSF, to je opracuję w miarę możliwości. Problem z zaczynaniem od zera jest taki, że może z tego nic użytecznego nie powstać (patrz Nebula, SPT), a ja wolę ulepszać coś, co już działa, bo przynajmniej działa i może zadziała lepiej (chociaż będzie miało dług techniczny).
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)
Popieram. Bazowanie na SCN/INC nie ma sensu, dla mnie to jest jedynie format wstecznej zgodności, ewentualnie przydatny do awaryjnego wykonania pewnych przekształceń wobec braku lepszych narzędzi.
Gdyby udało mi się wyeksportować teren z tego pluginu, to można byłoby fantazjować tak:
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, ale potem z tymi sceneriami fikcyjnymi są same problemy (z obiegami taboru, sensem tras, kilometrażem, alternatywnymi wariantami rzeczywistości po łączeniu z innymi fikcyjnymi itd.). Moim zdaniem trzeba zacząć od przekształcania danych oferowanych przez Geoportal, w załączeniu widok na chmurę punktów ze stacji Zwardoń. W takiej postaci nie nadaje się ona do użycia w symulacji, ze względu na ciężar, dziury na pionowych powierzchniach oraz zbędne odzwierciedlenie infrastruktury. Tutaj punkty mają kolory związane z interpretacją punktu (teren, budynki, zieleń, inne), ale jest też chyba wersja z kolorami "naturalnymi" (aczkolwiek mają tam ewidentny problem z wyrównaniem balansu bieli, więc korekta tego by się przydała w edytorze).
