Edytor plików scenerii ScnEdit, alpha testy

[SKP]

Ja też nie jestem całkowitym przeciwnikiem zapisu binarnego, ale wydaje mi się, że w obecnych warunkach to jest trudne do wykonania a są rzeczy ważniejsze. Poza tym, niesie to za sobą duże ryzyko, a korzyści widać niewiele. Tak, jak Tolein wspomniał, nie mamy żadnego edytora. Poza tym, ten edytor ma być tym samym co zapis w notatniku, tylko w pięknych tabelkach? Może jak już coś takiego robić, to trzeba pomyśleć o jakimś graficznym zapisie (w stylu języka G w LabView)?

Co do RSF, to Toleinie, możesz mieć rację. Ale chyba jest tylko jeden człowiek, który jednoznacznie jest w stanie stwierdzić, czy RSF można wykorzystać w MaSzynie, czy nie.

Zresztą nasze rozmowy chyba do niczego nie prowadzą, bo jeśli ktoś podejmie się stworzenia zapisu binarnego plików scenerii (na przykład Ra), to raczej nie będzie się sugerował tym wątkiem. Więc możemy sobie tutaj rekreacyjnie coś popisać, to i tak do niczego nie prowadzi...

[Mariusz1970]

Aaa, jeszcze jedno dodam, ogolnie tez bylem i jestem krytycznie nastawiony do formatu e3d i dds. Spodziewalem sie balaganu po wprowadzeniu tych formatow i czesciowo sie to sprawdzilo. Gdyby dodatki byly pozbawione bledow, to ok. Teraz jest takie rozdwojenie jazni. Mamy paczke e3d/dds, a i tak wszyscy grzebacze musza pobierac t3d/tga. O bledach/nieporzumieniach szerzej o e3d, nie chce mi sie rozpisywac. EOT w temacie formatubinarnego z mojej strony.

[HTD]

Co do problemu z edycją plików binarnych - to zniknie, jak będzie komplet narzędzi obsługujących te pliki. Jedno z nich rozwijam. Tyle. Co do tego jaki binarny format - mniejsza o to. Jakikolwiek. Będę miał więcej czasu - po prostu zrobię, dam do testów i się zobaczy. Dostanę dokumentację od RSF, to zrobię obsługę RSF. Będzie ok, przyjmie się, nie będzie ok, to się nie przyjmie i tyle.

Co do TGA, nie widzę powodu, dla którego ktoś musiałby pobierać TGA. Znaczy się jak, w SCN jawne rozszerzenia? To przed wydaniem PC maszynowo wyciąć we wszystkich plikach i po krzyku. Jeśli chodzi o T3D i E3D - to już sam exe robi konwersję. T3D jest z tego co wiem jedynie dla twórców do edycji. Fajnie jak wyjdzie z tym osobna paczka, ale paczka dla użytkowników powinna mieć tylko E3D. Jeśli chodzi o TGA - to powinna być paczka opcjonalna dla użytkowników. Powinno się to nazywać jakoś w stylu "paczka HD".

Ogólnie, zamiast się spierać na temat wymagań symka, lepiej po prostu dać dwie wersje - SD i HD. Roboty z tym praktycznie nie ma żadnej - wystarczy, że jest względy porządek w plikach. Do SD idą tekstury DDS i opcjonalnie byłoby fajnie, jakby też modele miały 2 wersje (z różną ilością poly). Ale czy nie zeszliśmy za bardzo z tematu? Żeby wrócić do tematu - ScnEdit będzie docelowo porządkował pliki (i np usuwał duple), może też robić wszystkie potrzebne konwersje. Oczywiście potrzeba troszkę czasu, żeby wszystko zrobić, ale będzie. I nie ma stresu, finalna wersja pójdzie pod XP.

Ogólnie dostałem sporo dobrych pomysłów na funkcje, wszystko będzie. Zabawa na pół roku, ale cóż, takie życie, niestety cisną mnie w robocie teraz. Będzie trochę luzu czy urlop, to robota znów ruszy z kopyta. A mam trochę zaległego urlopu.

Co do zmian w exe, co by pliki binarne wciągał - jak czytam o "niedasiach" to mnie aż ponosi. Wszystko się da, wszelkie przeszkody to wymówki. No bez żartów. Chodzi tylko i wyłącznie o czas. Trzeba będzie nad tym po prostu trochę posiedzieć i podłubać. Wg mnie warto. W porównaniu z czasem powstawania jednej scenerii to robota nad resztą rzeczy idzie szybciutko i generalnie damy radę. Sam się przyłączę. Jeszcze nie, bo raz - mam co robić, dwa, odnosząc się do legendarnego posta Rewizora - nie mam na chwilę obecną wystarczającej ilości czasu. Ale tak tego nie zostawię. Zmieniam robotę i czas na MaSzynę musi się znaleźć. Bo co to za życie jak nie ma czasu na zabawę? :)

[Benek]

Aaa, jeszcze jedno dodam, ogolnie tez bylem i jestem krytycznie nastawiony do formatu e3d i dds.

Na moim dysku paczka DDS/E3D zajmuje 5 GB, repo z TGA/T3D zajmuje niespełna 22 GB. Niewątpliwie czuć tę różnicę. Zauważyłem też, że format E3D ładuje się szybciej niż T3D. W przypadku wielopłaszczyznowego terenu na scenerii MOP zauważyłem znaczny wzrost FPS po eksporcie terenu do E3D. Z drugiej strony nieraz chciałem na szybko edytować wpis w T3D w tej pierwszej paczce i był problem. Mariuszu, to że dostrzegasz pewne minusy tych formatów wynika z tego, że przyczyniają się one do opóźnień w publikacji kolejnych nakładek bądź całych paczek (trzeba dokonać konwersji). Brak jest odpowiednich narzędzi, które masowo dokonają transformacji, ale największym problemem jest to, że nie ma rąk do pracy, a ci co coś robili dają sobie spokój, bo koncepcja rozwoju, o ile słuszna, zaczyna być uciążliwa nawet dla deweloperów ze względu na duży stopień skomplikowania. Świetnym przykładem są niekończące się poprawki kiepskich scenerii z paczki głównej.

[Tolein]

Banita, porównanie do htmla średnio trafione, tak mi się wydaje. Bo jeśli Ty chcesz grać w grę "przytaczanie w dyskursie argumentów ad absurdum", to ja również mogę w tę grę grać, także służę uprzejmie i odpowiadam pytaniem: tekstury też powinniśmy mieć zapisywane w formacie tekstowym, bo chcesz mieć możliwość ich edycji w notatniku? Czy może jednak potrafisz pogodzić się z formatem bitowym i edycją przy pomocy dedykowanych programów?
Nie wiem dlaczego traktujesz mnie z marszu jako wroga. Jak już wspomniałem, nie lobbuję na tym etapie za żadną z opcji, próbuję wprowadzić normalizatorski głos w dyskursie. Masz z tym problem? get real.
A E3D będę bronił, bo format nie jest głupi, stał się natomiast ofiarą tego, że nie ma ŻADNYCH narzędzi do edycji, importu czy eksportu jego plików. Czyja to jest wina? Ry, że nie zrobił wszystkiego (idąc tym tropem, dawno powinien zrobić scenerię CAŁA_POLSKA, skoro już się zabrał za edytor).

[Mariusz1970]

Ja Cie nie traktuje jak wroga. Jesli odniosles takie wrazenie, to sorry. Porownanie z html, nietrafione, zgadza sie, bo tu chodzi o maszyne, a tam o internet. Kazde porownanie jest nietrafione np maszyna quiek. Ogolnie tez mnie denerwuje ten html, bo strony by sie szybiej wczytywaly. No ale kurcze, mial byc EOT :) Zrobicie sobie, co tam bedziecie chcieli. Jesli chodzi o e3d, to nie da sie nich edytowac ponoc, tzn, tam juz jest cos policzone, czego nie da sie odtworzyc stanu pierwotnego.  Wziales to pod uwage?A czy wiedziales o tym? A czy ja mam problem, raczej nie, moze Ty masz? Ja tylko odpowiedzialem Tobie, bo sie do mnie imiennie zwrociles.

[Tolein]

A czy Ty czytałeś specyfikację formatu E3D? Czy opierasz się na domysłach, pogłoskach, plotkach, etc.? Jeśli to drugie, to polecam lekturę.
Podstawowa różnica między T3D i E3D jest prosta: w E3D nie trzeba parsować (wczytujemy bit po bicie i mamy pełną kontrolę nad tym, co w którym bicie jest), a współrzędne wierzchołków zajmują 32 bajty, podczas kiedy jeden znak w T3D zajmuje jeden bajt, także jedna współrzędna zajmuje 1-8 bajtów, a jeden wierzchołek, odpowiednio, 8-64. ;-)

[Mariusz1970]

Sluchaj, skad wiesz od kogo to wiem? Jesli osoba developer mi mowi, ze sa tam juz policzone wektory i nie da sie w pelni odtworzyc stanu pierwotnego t3d (nie wszystkie parametry), to ja mu wierze. Czyli edycja jest mozliwa, ale niepelna. Mowila to soba, ktora zrobila kiedys edytor do e3d.

[Tolein]

Proszę, nie rozśmieszaj mnie. Po pierwsze, nie patrzysz na sprawę obiektywnie, tylko z punktu widzenia formatu T3D, jakby był on jakimś absolutnym punktem odniesienia. Po drugie, czy mam rozumieć, że chcesz wektory normalnie (cieniowania, bo zapewne o to chodzi) edytować w notatniku? Czy masz problem z ich konwersją na maski cieniowania? Bo z tego co wiem, to zarówno 3DS, jak i każdy inny edytor, przyjmie bez problemu wierzchołki z policzonymi dla nich wektorami normalnymi. A modele się edytuje właśnie w programach do edycji tego, a nie w notatniku.

[youBy]

Na pewno nie da się przeliczyć wektorów kontrolnych na grupy wygładzania?

[Mariusz1970]

To po co edytor? Jest tak format graficzny w jakims programie, t3d, e3d. Tak pozostanie pewno. A, ze format e3d ma swoje zalety, to wiem, ale patrzac na caloksztalt w maszynie, to mnie juz to nie przekonuje. Jesli uwazasz, ze jest cud malina i nie ma z caloksztaltem wprowadzenia problemu, to twoje zdanie, ktore sznuje, ale Ty tez mnie uszanuj.

[Ra]

Co do braku wczytywania RSF przez EU07.EXE, to po prostu nie jest priorytetem. Nie widziałem wielu skarg na prędkość wczytywania, co by było głównym argumentem za użyciem RSF. Druga kwestia jest taka, że RSF nie jest jeszcze "kompletnym pojemnikiem" na scenerie (np. nie da się w nim zapisać eventów). Poza tym, co zrobić z plikami INC? Wczytywać je tekstowo, czy sparsować, podstawić argumenty aktualne pod formalne i dorzucić binarnie do RSF? Jeśli INC miały by iść binarnie, to musiała by być oddzielna wersja RSF do edycji i oddzielna do wczytywania. Jeśli INC jednak tekstowo, to spowolnią wczytywanie (no i trzeba przygotować generowanie argumentów dla INC z wartości binarnych). Za dużo niewiadomych, za mała korzyść praktyczna.

Natomiast przymierzam się też do tego, żeby z EU07.EXE zrobić wizualizację do edytora. Wtedy aktualizacja RSF w edytorze była by wysyłana do symulacji, która by się wtedy uaktualniała. Być może działało by to też w drugą stronę. To też nie jest priorytet, bo ja nie mam wewnętrznej presji na edycję 3D, a do rozwiązania w edytorze pozostaje jeszcze masa problemów topologiczno-geometrycznych, jak wyginanie rozjazdów oraz łuki koszowe.

Alternatywnym formatem binarnym było by zrzucenie wewnętrznych struktur do pliku. Taki plik byłby wczytywalny tylką tą wersją EXE, która go zapisała (być może wyjątkowo by się dało wczytać jakąś poprzednią/następną). Jednak ze względu na częste modyfikacje struktur danych raczej nie będzie zgodności pomiędzy różnymi wersjami. Prędkość wczytywania scenerii była by maksymalna możliwa, jedynie tylko E3D, dźwięki i tekstury musiały by być doczytane z osobnych plików. Również wtórna edycja plików nie miała by sensu.

Przed reorganizacją wczytywania najbardziej powstrzymuje mnie brak kompletnej koncepcji obsługi komórek. Najlepiej by było, jakby każda komórka scenerii była zapisana w osobnym pliku, możliwym do wczytania w trakcie symulacji i wyrzucenia z pamięci, gdy stanie się zbędna. Komórki można by wczytywać zarówno z RSF (ze zbinaryzowaną zawartością INC), jak i z wspomnianego formatu wewnętrznego. Ale zbyt wiele jeszcze kwestii zostaje do uszczegółowienia, priorytety wydają się być inne, poza tym nadal ciągną się podstawowe braki w podstawowych elementach (podsypki rozjazdów, wysięgniki z przesuwalnym uchwytem drutu, sposób teksturowania pól i zapełniania zabudowań, żeby wyglądały realistycznie).

[Tolein]

To po co edytor?

Rozdzielmy dwie rzeczy. Zaletą T3D jest to, że można otworzyć go w notatniku, zmienić jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisać i gotowe. Jeśli natomiast chcemy coś zmieniać w samej geometrii modelu, to odpalamy edytor 3DSMax, wczytujemy model z T3D, ewentualnie eksportujemy go do innego edytora, w którym działamy (np. Blender).
Teraz dla E3D nie mamy ani jednej możliwości, ani drugiej. Skrypty dla importu/exportu modelu do 3DSa (czy np. Blendera), dają nam co najmniej taką samą funkcjonalność. Natomiast mogą dawać nam dużo większą funkcjonalność (mogą, bo funkcjonalność trzeba oczywiście uwzględnić w skryptach), taką jak np. indeksowanie submodeli (mniejszy rozmiar pliku), czy inne fajne rzeczy. Same wierzchołki normalnie też można eksportować (jest to w dużym skrócie daleko bardziej rozwinięta forma opisywania cieniowania bryły, niż maski cieniowania (lub, jak to ładnie Zając nazwał, grupy wygładzania). Dodatkowy edytor plików binarnych, o którym pisałem, miałby dawać tę samą funkcjonalność co notatnik w przypadku T3D, tzn. otwieramy plik, zmieniamy jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisujemy i gotowe. Mam nadzieję, że tym razem wyraziłem się jasno.

Na pewno nie da się przeliczyć wektorów kontrolnych na grupy wygładzania?

Należałoby chyba sprawdzić, czy wektory w wierzchołkach wspólnych dla dwóch trójkątów są identyczne, jeśli tak, to stosujemy tę samą maskę.

Jeszcze słowo do @Benka:

[...] największym problemem jest to, że nie ma rąk do pracy, a ci co coś robili dają sobie spokój, bo koncepcja rozwoju, o ile słuszna, zaczyna być uciążliwa nawet dla deweloperów ze względu na duży stopień skomplikowania.

@Benku, może należy pogodzić się z tym, że renesans przeminął, czas Leonardów da Vincich też się skończył i czas działać w bardziej zorganizowanych grupach, ze wskazaniem na specjalizację i zawężeniem pola kompetencji pojedynczego użytkownika? Symulator robi się coraz bardziej skomplikowany, jest to fakt, trudno się z nim nie zgodzić, ale wg mnie jest to zmiana pozytywna. Teraz trzeba podjąć próbę adaptacji społeczności twórców, odnalezienia się w nowej sytuacji. Trzeba znaleźć ludzi zdeterminowanych, chętnych do współpracy, nauczyć ich małego kawałka roboty i być może uda się to wszystko pchnąć do przodu.

[Ra]

Dodatkowy edytor plików binarnych, o którym pisałem, miałby dawać tę samą funkcjonalność co notatnik w przypadku T3D, tzn. otwieramy plik, zmieniamy jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisujemy i gotowe.

Od wielu lat noszę się z pomysłem stworzenia edytora plików binarnych, w którym za pomocą plików tekstowych (np. YAML) można by definiować znaczenie poszczególnych pól oraz zależności (np. że liczbę trzeba potraktować jako długość pola danych). Ale jakoś dotychczas nie było wyraźnego impulsu, by to zrobić. Być może takie edytory już istnieją. Ja potrzebuję takiego edytora również do edycji plików DBF (w celach nie związanych z MaSzyną), bo nagłówki DBF nie zawsze określają typ danych prawidłowo, a do tego potrzebowałbym sobie opisać poszczególne pola bazy danych i skonfigurować zależności.

Co do wygładzania, to obecnie istnieje już możliwość wczytywania T3D, który zamiast grup wygładzania będzie miał jawnie podane wektory normalne. Jest też możliwość zapisywania w E3D masek wygładzania poszczególnych wierzchołków, co zwiększy rozmiar pliku o ok. 3% — dotychczas chyba nikt nie sugerował takiej potrzeby.

[Mariusz1970]

Znalem fachowcow, ktorzy w notatniku robili dosyc zaawansowane modyfikacje modeli, ale to dygresja. Ja mysle, ze raczej akcent stawialbym, nie na to, ze jest brak edytora dla e3d, tylko, na czesta potrzebe modyfikowania czegos w maszynie. Same czeste modyfikacje rodza w sobie problemy, nawet import, ekport z/do maszyny. Dodatkowe zrodla problemow, to generowanie e3d z parametrami przez rozne osoby, niekoniecznie prawidlowo. Pozniej sa problemy typu, scignij dany plik t3d, usun e3d i ponownie wygeneruj e3d. W Kazdym razie, jako, ze dodatki sa w znacznej mierze zabugowane (wymysl temat, a znajde bledy), to potrzeba jest ich nieustannna likwidacja. Na ogol najlatwiej, modyfikuje sie tekstowo i zrodlo i koncowy efekt jest w jednym. No ale, sam juz nie wiem, moze przeadzam z problemami z e3d. Jesli wiekszosc z nas na forum jest grzebaczami, to i tak posluguja sie t3d (a moze sie myle)

[Tolein]

Co do wygładzania, to obecnie istnieje już możliwość wczytywania T3D, który zamiast grup wygładzania będzie miał jawnie podane wektory normalne. Jest też możliwość zapisywania w E3D masek wygładzania poszczególnych wierzchołków, co zwiększy rozmiar pliku o ok. 3% — dotychczas chyba nikt nie sugerował takiej potrzeby.

Na dobrą sprawę, @Banita nie potwierdził nawet, czy moje przypuszczenie było słuszne i czy dobrze zidentyfikowałem problem, do którego się odnosił. Cieniowanie nie wydaje mi się wielkim (popularnym) problemem. Nie wiem, czy mamy aktywnych modelarzy, którzy świadomie zmieniają te wektory, próbując osiągnąć określony efekt, ale zakładam, że raczej nie. Bardziej martwi mnie fakt, że E3D oferuje pewne formy optymalizacji modelu już na etapie jego tworzenia, których nikt nie wykorzystuje (zakładam, że moduł konwersji T3D -> E3D zaimplementowany w "exe" takich funkcjonalności nie oferuje), bo (a) nie wiedzą, że można (b) nie wiedzą jak (c) nie ma narzędzia, więc wszystko i tak leci przez T3D, gdzie taka optymalizacja idzie w diabły.
Przy czym jest to kolejny przykład na to, że symulator się rozwija i (gdybyśmy mieli takie narzędzia to) potrzebna jest (by była) jedna osoba, która opanowałaby temat na wystarczającym poziomie i umiała go przekazać innym modelarzom (na zasadzie jakiegoś wykładu, prezentacji, szkolenia).

[Mariusz1970]

Ja sie wypowiedzialem, co slyszalem pare lat temu. Jesli piszesz mi o narzedziach/edytorach do e3d, ze jest ich brak, to nie wnikalem jak czesto i komu i co bedzie potrzeba zmieniac, czego zmienic sie ponoc nie dalo i o tym napisalem. Ponadto, nie pamietalem dokladnie o co chodzi, tzn, czego sie nie dalo wykonac. Moze z tym e3d za daleko zabrnalem, ale to nie oznacza, ze nie dostrzegam wad i ze stalem sie zwolennikiem formatu bianarnego do scenerii :) No i mozesz miec racje z tymi optymalizacjami.

[Ra]

Format E3D jest obecnie problematyczny o tyle, że mało kto potrafi coś z nim zrobić (np. poprawić maksymalną widoczność submodeli). Drugim problemem są błędy w T3D, z których E3D powstał. Np. jeśli w T3D nie jest zaznaczona animacja submodelu, to podczas zapisu do E3D zostanie wykonana optymalizacja, która uniemożliwi łatwe przywrócenie animacji (bo zostaną przeliczone wierzchołki). Dzięki optymalizacji mamy trochę lepszy FPS. Problemu tego by nie było, gdyby w T3D były prawidłowo oznaczone animacje oraz zresetowane transformy tam, gdzie animacje potrzebne nie są. Ale tak nie jest, a oczekiwanie od twórców, że będą robić optymalny T3D, jest zbyt dużym wymaganiem. W związku z tym po każdej takiej poprawce w T3D trzeba wygenerować E3D.

Innym problemem z E3D jest to, że zawiera on dodatkowe informacje, nieobecne w T3D. Jest to np. rozdzielenie submodeli na fazy przezroczystych i nieprzezroczystych, które zależne jest od przezroczystości w użytych teksturach. Również animacje są oznaczane na podstawie MMD i rozpoznanych nazw submodeli, aby zachować zgodność ze starymi T3D, które wszędzie miały brak animacji. Konwertując E3D na T3D gubimy część tych informacji, a z kolei E3D nie zrobi się prawidłowo bez dostępu do nich.

Pytanie moje jest, czy coś by to ułatwiło, gdyby istniał konwerter formatu E3D na odpowiadający mu w pełni format tekstowy?

[szogun]

Byloby to spore ulatwienie. Teraz zdarza sie ze model nie chce sie wczytac z e3d. Poszukwanie bledu w zrodlowym t3d jest chyba prawie niemozliwe.

[muri]

Dostanę dokumentację od RSF, to zrobię obsługę RSF.

Nie wiem czy takowa istnieje w formie jakiej byś oczekiwał - ale popaczaj tutaj: http://rainsted.com/wiki/index.php?title=Specjalna:Szukaj&search=rsf

[HTD]

To się jeszcze dogadamy odnośnie tego. Może wspólnie coś zrobimy, ale póki co odkładam to na później, jak skończę podstawową funkcjonalność, czyli pełne wyszukiwanie obiektów na mapie i automatyczne przypisywanie. To będzie można nazwać wersją 1.0, po ukończeniu pomyślimy, czy dodawać kolejne funkcje, czy może dodać obsługę RSF najpierw.

Nie mam tylko pewności, czy zmiana parsera plików tekstowych nie powinna pójść jako priorytetowa, jeśli na niektórych sceneriach to się sypie teraz, albo działa zbyt wolno. Tym bardziej, że na razie mam tylko parser torów zrobiony, a będzie potrzebny jeszcze od trakcji i sygnalizacji. Jak implementacja lexera FSM będzie dużo szybsza i pewniejsza (a zgaduję, że będzie) - to może szkoda czasu robić 2 razy to samo i od razu zrobić ten lexer. Pliki tekstowe nie zostaną pewnie szybko zastąpione innym formatem, a nawet gdyby miały być, to i tak będzie potrzebny konwerter z obecnego formatu.

[Krzysiek626]

Przy czym jest to kolejny przykład na to, że symulator się rozwija i (gdybyśmy mieli takie narzędzia to) potrzebna jest (by była) jedna osoba, która opanowałaby temat na wystarczającym poziomie i umiała go przekazać innym modelarzom (na zasadzie jakiegoś wykładu, prezentacji, szkolenia).

Oceniam to teraz, jako najważniejsze zadanie. Może nie jestem dość pilny w nauce, ale teraz trudno o naukę w tak zorganizowanym forum. Widzę też pewien dystans do lamerskich pytań, co nie ułatwia współpracy. Z drugiej strony wyobrażałem sobie, że projekt symulatora, będzie do ogarnięcia dla każdego, kto zechce stworzyć dodatki, mapy i tym podobne rzeczy. Być może problem tkwi w niechęci do nieznanego, a możliwości poznawcze są z różnych względów ograniczone. Takie jest moje zdanie, może nie odosobnione.

[HTD]

(...) Z drugiej strony wyobrażałem sobie, że projekt symulatora, będzie do ogarnięcia dla każdego, kto zechce stworzyć dodatki, mapy i tym podobne rzeczy.

Ja widzę inny problem - symulator się zmienia. Trudno to opisać i udokumentować. To jakby 2 osobne rzeczy - obecna forma, i to co jest planowane i w tej chwili powstaje. Można to rozbić ten problem na 2 części:
1. Pełna, wyczerpująca dokumentacja struktur danych symulatora (wydana wersja bieżąca)
2. Pełna, wyczerpująca dokumentacja planowanej nowej wersji, włącznie z rzeczami do zrobienia, których jeszcze nie ma, z rozpisaniem zadań i zależności

Co do punktu 1 - pewnie zdania będą podzielone, czy jest potrzeba zrobienia tego i kto miałby to zrobić.

Co do punktu 2 - warto o tym pomyśleć chociaż i zastanowić się. Zamiast rozwijać nowe rzeczy "na żywioł" można by wprowadzić jakąś organizację. Żeby nie męczyć się później z formatami, w których coś brakuje, coś łamie kompatybilność itd. Można wziąć pod uwagę wszystkie rzeczy, które wyniknęły podczas rozwoju dotychczasowych wersji. Można zaprojektować przyszłą wersję tak, żeby była bardziej odporna na przyszłe zmiany i nowości. Właściwy projekt (a właściwie metody tworzenia projektu) mógłby zaoszczędzić mnóstwo czasu i umożliwić łatwiejszą współpracę większego zespołu ludzi. API i modularna konstrukcja pozwoliłyby pracować nad różnymi rzeczami równolegle. Mało tego, szkicowa dokumentacja projektu, zanim jeszcze zacznie być realizowany pozwoliłaby wszystkim zainteresowanym zgłaszać swoje uwagi, może byłby doskonalszy i bardziej kompletny. Z doświadczenia wiem też, że tworzenie rzeczy zgodnie z dokumentacją jest bez porównania szybsze i prostsze. Tu nawet nie trzeba nauki, po prostu bierzesz dokumentację i zaczynasz tworzyć. Nie musisz się co chwila pytać jak działa to czy tamto, bo masz to opisane. Osoba, która stworzyła jakąś funkcjonalność też nie musi tego co chwila komuś tłumaczyć - robi dokumentację i cześć.

[muri]

a może by Ci chłopaki wystawili kawałek źródeł, który w obecnym exe odpowiada za parsowanie plików scenerii? W sumie to chyba najlepiej by było zrobić z tego jakąś bibliotekę - której mogłyby używać zarówno exe symulatora, jak i wszelkiej maści edytory itp.

[ryba825]

Nie widzę problemu z używaniem plików tekstowych i binarnych. W paczce całościowej powinny być binarki, żeby symulator lepiej działał, a pliki do modyfikacji powinny być dostępne jako osobne paczki. Programiści zwykle pracują z plikami tekstowymi, a użytkownicy aplikacji z gotowymi plikami wykonywalnymi, więc może być analogicznie w przypadku scenerii, modeli i tak dalej. Na pewno w takim przypadku ułatwieniem byłby program z przyciskiem "kompiluj", żeby wyprodukować plik binarny. I tu mechanizm aktualizacji stworzony przez Ra miałby co robić, a mianowicie do repo wrzucałoby się opisaną paczkę (obiekt + nr wersji obiektu + na której wersji EXE działa), klik "aktualizuj" i działa. Potrzebny jest imperatyw, który to ruszy. Nie trzeba od razu porzucać jednego formatu pliku i używać drugiego, tylko wydzielić środowisko deweloperskie (tworzenie obiektów) od produkcyjnego (gotowa MaSzyna do symulowania).

[HTD]

Wracam po dłuższej przerwie spowodowanej złym stanem zdrowia, mam nadzieję, że na dobre. Wrzuciłem na GIT-a nową wersję z użyciem lexera FSM.

Co to daje?
Ano jest ze 100x szybsze i pewniejsze od przetwarzania plików scenerii za pomocą wyrażeń regularnych. Lexer (od Lexical Analyser) FSM (od Finite State Machine) to komponent używany przez wszystkie profesjonalne narzędzia korzystające z plików tekstowych napisanych wg składni jakiegoś języka.
Na wejściu przyjmuje plik tekstowy, na wyjściu zbiór binarnych tokenów, które jednoznacznie odwzorowują dane zawarte w pliku.
Gdyby MaSzyna używała podobnie zbudowanego lexera FSM, scenerie ładowałyby się kilka sekund, zamiast kilku minut ;)
Oczywiście ScnEdit nie ładuje scenerii w całości, ani nie optymalizuje procesu ładowania i przetwarzania do końca. Pozostawiłem pewien kompromis pomiędzy wydajnością programu a czytelnością kodu. Wewnątrz struktury są przetwarzane do różnych postaci, co można by ewentualnie skrócić dla jeszcze większego przyśpieszenia, ale przy czasach ładowania danych rzędu pojedynczych sekund nie jest to krytyczne.

Przetestowane na wszystkich mapach z najnowszej paczki developerskiej ;) Wszystkie mapy ładują się poprawnie i szybko.

UWAGA: Nazywanie i sortowanie torów NIE BĘDZIE DZIAŁAĆ W TEJ WERSJI! Proszę nie używać tej funkcji, bo może ona uszkodzić pliki scenerii! Problem zostanie rozwiązany razem z następną wersją.

Do poprawienia zostały jeszcze 2 pomniejsze bugi: skrzyżowania na mapie wyświetlane są innym kolorem niż drogi (nie mam pojęcia czemu), siatka mapy ma niewłaściwe przesunięcie.
Do zrobienia zostało zaznaczanie torów na mapie i wyświetlanie wskaźników.

Niestety popsuł mi się komp, więc siłą rzeczy prace pójdą opornie, bo w między czasie będę musiał oddać do do serwisu i skonfigurować nowe środowisko do pracy na starym kompie.

[guest23269]

Ja również zetknąłem się ostatnio z problemem wydajności wczytywania scenerii. Na potrzeby modernizacji Krewetkowa piszę niewielki program, pomagający mi w wielu sprawach podczas edycji scenerii. Podczas uruchamiania program wczytuje do tablicy obiektów prawie całą zawartość plików scn i scm (oprócz pociągów). Jakoś nie zauważyłem, żeby ten program uruchamiał się znacznie wolniej niż inne moje aplikacje, niewczytujące żadnych plików. Rozumiem, że symulator musi jeszcze wczytać modele, tekstury itd., ale bez przesady. Symulator Krewetkowo wczytuje w pół minuty. Najbardziej niezrozumiałe jest dla mnie kilkusekundowe zawieszenie się Maszyny po wypisaniu "Loading - texture: textures/grassgreen1". Ile może zajmować wczytanie wierzchołków trójkątów z pliku tekstowego... Jak dla mnie, nie trzeba wprowadzać binarnego formatu scenerii, wystarczy zoptymalizować wczytywanie plików tekstowych. Dodam, że nie korzystam z żadnych nowoczesnych technologii. Pliki wczytuję w pętli, Double.Parse [metoda z. NET] konwertuję na liczbę, za pomocą switch sprawdzam z jakim typem obiektu mam do czynienia (tor, trójkąt itd). Proste i szybkie.

[Maciej]

Ja również zetknąłem się ostatnio z problemem wydajności wczytywania scenerii.

Używasz paczki DDS (08.13 + ewentualne patche) czy najnowszej, tj. 15.02, która jest w wersji TGA? Wersja TGA wczytuje się dłużej, a na niektórych sceneriach długość ładowania pliku jest o wiele większa w porównaniu do tekstur w formacie DDS. Tekstury TGA ważą więcej od DDSów, więc czas ich ładowania wzrasta.

Symulator Krewetkowo wczytuje w pół minuty. Najbardziej niezrozumiałe jest dla mnie kilkusekundowe zawieszenie się Maszyny po wypisaniu "Loading - texture: textures/grassgreen1".

Pytanie, ile na tej scenerii jest elementów czy obiektów i jaka ta sceneria jest duża? Ja przykładowo kiedyś zacząłem coś grzebać przy jakiejś starej scenerii, która ładowała się dosłownie w 10 sekund. Tylko, że na tej scenerii nic nie było, a poza tym była bardzo krótka i dlatego tak szybko się ładowała. A co do tekstury trawy - wczytuje się dłużej, bo zajmuje większość (albo nawet całość) terenu, więc siłą rzeczy musi się dłużej ładować. To nie jest np. model, który jest ustawiony tylko w niektórych punktach na scenerii.

[guest23269]

Paczka DDS 8.13. Sceneria jest niewielka, jest na niej kilkanaście rodzajów budynków, 3 tekstury drzewek, ściany lasu oraz teren [trawa]. Tory są zelektryfikowane. Rozumiem, że TGA zajmuje więcej miejsca. Jeśli jednak Maszyna wczytuje plik,w którym są tylko i wyłącznie trójkąty i tylko z jedną teksturą, gdzie nie trzeba tracić czasu na wczytywanie innych plików i jedyne, co trzeba zrobić to konwersja liczb ze String na Double oraz zapisanie tych liczb w pamięci, i to zajmuje kilka sekund, to z optymalizacją jest chyba coś nie tak. 10 sekund na scenerię, na której nic nie ma - trochę długo...

[HTD]

Prędkość ładowania plików (dysku) nie ma nawet nic do rzeczy. Scenerie ładują się dokładnie identycznie wolno ze starego i wolnego dysku talerzowego jak i SSD.
Co ciekawe jeśli chodzi o FPS - to też paradoksalnie nie zależy od karty graficznej. Testowałem na 3 kartach graficznych. W miejscach gdzie jest 60FPS - jest na wszystkich kartach, nawet na najwolniejszym zintegrowanym Intelu, tam gdzie przycina do 30 tam przycina też na wszystkich 3 kartach, jakby to nie była w ogóle kwestia wydajności karty graficznej. MaSzyna ma problemy wydajnościowe, które wydają się w pewnych miejscach prawie niezależne od wydajności sprzętu. Dziwne to trochę. Poprzednia paczka chodziła dużo szybciej. Nie wiem czy to tylko kwestia TGA. Podgrałem sobie DDS-y ze starej paczki i przełączyłem w Rainsted. Nie ma większej różnicy. Może troszkę mniej tnie w krytycznych miejscach, ale tylko odrobinę.