- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: ShaXbee w 29 Sierpnia 2014, 05:48:45
-
Zrodelka: https://github.com/shaxbee/maszyna-client
Instrukcja kompilacji:
- Pobierz zrodla z repo
- Zainstaluj Microsoft Visual Studio Express 2013 (http://go.microsoft.com/?linkid=9832280&clcid=0x409)
- Zainstaluj CMake (http://www.cmake.org/files/v3.0/cmake-3.0.2-win32-x86.exe)
- Uruchom CMake, ustaw 'source directory' na katalog do ktorego sciagnales repo, a 'build directory' na nowy, czysty katalog
- Kliknij Configure/Generate i wybierz opcje Microsoft Visual Studio 2013
- Otworz wygenerowany projekt visual studio z katalgu ustawionego wczesniej w 'build directory'
- Dobry kompresor/dekompresor tekstur - https://code.google.com/p/crunch/
- Realistyczna przezroczystosc bez sortowania trojkatow - http://jcgt.org/published/0002/02/09/paper.pdf / https://software.intel.com/sites/default/files/m/1/2/a/5/7/37944-adaptive_transparency_hpg11.pdf
- Optymalizacja indeksow wierzcholkow - https://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html
- Nowoczesna biblioteka do konfiguracji okien i opengl - http://www.glfw.org/
- Binarne wiadomosci bez narzutu deserializacji - http://kentonv.github.io/capnproto lub https://github.com/google/flatbuffers
- Komunikacja sieciowa jako kolejki wiadomosci - http://zeromq.org/
- Programowanie w OpenGL 3.2+ - http://www.tomdalling.com/blog/modern-opengl/
- Biblioteka do operacji na macierzach i kwaternionach - https://github.com/g-truc/glm
Build:
- Obsluga zewnetrznych bibliotek w CMake: http://stackoverflow.com/questions/9689183/cmake-googletest
OpenGL:
- Minimalna wersja OpenGL 3.2
- Wyswietlanie tylko GL_TRIANGLE
- Modele w formacie binarnym, optymalizacja modeli offline
- Geometry instancing dla powtarzalnych obiektow
- Frustrum culling / system czasteczkowy na GPU przy uzyciu transform feedback
- glMultiDrawArraysIndirect - renderowanie wielu obiektow przy uzyciu jednego wywolania
- Aliasy do tekstur - binding tekstur dla wielu submodeli jednoczesnie (do 32 jednoczesnie)
-
Na dzien dzisiejszy mam przygotowany szkielet z wymaganymi zaleznosciami na https://github.com/shaxbee/maszyna-client. Poki co kompiluje sie na Macu i Linuxie.
Tworzenie okna i inicjalizacja kontekstu jest robiona przy pomocy GLFW, rozszerzenia OpenGL sa ladowane przy pomocy GLEW, dodatkowo dorzucilem googlemock / googletest do unit testow.
Mam gotowa integracje flatbuffers (binarna serializacja/deserializacja) na osobnym repo wiec niedlugo zaczne pisac prosty loader modeli i renderer.
-
@ShaX jako, że nie znam się na programowaniu zapytam otwarcie, jakich wad i zalet (opis dla laika) można się spodziewać po wykonaniu tej implementacji?
-
To jest poki co tylko zbior luznych pomyslow.
Chcialbym zeby renderer nie mial artefaktow przy renderowaniu przezroczystosci, wprowadzic lepsze oswietlenie i umozliwic szybkie i latwe wyswietlanie duzej ilosci powtarzalnych obiektow (drzewa, trawa, ogrodzenia etc.).
Edit:
@Ra: Dodalem wstepna definicje binarnego formatu modeli: https://github.com/shaxbee/maszyna-client/blob/master/client/schema/model.fbs (https://github.com/shaxbee/maszyna-client/blob/master/client/schema/model.fbs) - masz pomysl co warto tam jeszcze dodac?
@Q: Jakies postepy z kompilacja pod windowsem?
-
Mi to nic nie mówi, poza tym nie mam czasu na takie rzeczy.
-
@Ra: Mozesz zawsze zapytac? Naprawde oczekiwalbym choc odrobine wspolpracy...
Edit: Po drobnych zmianach i aktualizacji sterownikow projekt kompiluje sie i uruchamia u Q
-
Postuluję dodanie do "notatnika" listy kroków prowadzących do przeprowadzenia poprawnej kompilacji (łącznie ze wskazaniem narzędzi). Z tego co widzę na shoutBoxie trochę tam się z tym trzeba pobawić.
-
Ok, wrzuce instrukcje po powrocie z pracy.
Kolejna obserwacja - obecnie w wydaniach MaSzyny umieszczamy modele binarne, ktore sa juz zoptymalizowane konkretna wersja EXE - powoduje to problemy przy zmianie optymalizacji / sposobu wyswietlania / formatu e3d.
Wobec tego proponuje zeby format binarny byl domyslnie niezoptymalizowany, nastepnie optymalizacja powinna byc wykonywana przy pierwszym ladowaniu modelu, a zoptymalizowany model zawieral sume kontrolna, ktora byla by tworzona na podstawie wersji EXE i ewentualnie sum kontrolnych zaleznych plikow (.mmd w YAMLu etc). Dzieki temu jakakolwiek zmiana powyzszych parametrow spowoduje ponowne wygenerowanie zoptymalizowanego modelu.
-
Nie potwierdzam. Format binarny zapisu modeli nie jest "keszem". Optymalizacja polega na wyjedynkowaniu transformów submodeli, które nie mają flagi animacji, i odpowiednim przeliczeniu wierzchołków tych submodeli, oraz ich potomnych. Nie bardzo widzę zakres, w jakim ta optymalizacja miała by być zmieniona. Gdyby wszystkie modele miały wyjedynkowane transformy wszędzie tam, gdzie faktycznie są one zbędne, to optymalizacja w EXE nie była by potrzebna. Ale na poprawienie modeli w tym zakresie można by się i po paru latach nie doczekać.
Jeśli chodzi o zmianę sposobu wyświetlania, to póki co nie padła żadna wiążąca propozycja, która by wymagała modyfikacji plików modeli. Nie widzę specjalnie sensu w robieniu rzeczy dla sztuki samej w sobie.
Zmian formatu E3D nie przewiduję, ponieważ z jednej strony włożyłem dużo pracy w jego optymalne opracowanie, a z drugiej przewidziany jest prosty mechanizmy rozbudowy. Można by ewentualnie zmienić sposób zapisu długości kromki, aby nie zawierała ona 8 bajtów długości nagłówka (dążąc do jakiejś tam zgodności ideologicznej np. z PNG), ale to jest sztuka dla sztuki i żadnych praktycznych korzyści z tego nie będzie.
Niezoptymalizowanym formatem jest T3D, który nie ma policzonych wektorów kontrolnych, wyjedynkowanych zbędnych transformów ani nie ma flag określających sposób wyświetlenie submodelu. Nie widzę korzyści z tworzenia osobnego bytu w postaci niby "niezoptymalizowanego formatu binarnego". Większym problemem są błędy w modelach T3D, w postaci niepotrzebnie namnożonych submodeli, źle ustawionych flagach przezroczystości, braku oznaczenia animowanych submodeli. Ponadto, przeprowadzanie dodatkowych operacji na modelach podczas ich wczytywania jest zbędnym marnowaniem czasu. Jeszcze większym problemem jest brak elastyczności w animacjach — dodanie chociażby nastaw hamulców w wagonach, czy ukrywanie zbędnych submodeli z poziomu MMD jest na razie niewykonalne.
-
Fakt ze uzytkownicy musza usuwac E3D swiadczy ze jakis mechanizm trzeba dostarczyc - chociazby sume kontrolna. T3D sa ciezkie do dystrybucji i parsowania, E3D sa wzbogacane o informacje o chociazby animowanych submodelach.
-
Muszą usuwać, gdy zamiast E3D dostają T3D. W prawie wszystkich przypadkach jest to związane z poprawieniem modelu T3D. Wczytywanie T3D jest niekorzystne przede wszystkim ze względu na konieczność policzenia wektorów normalnych, czego czas rośnie z kwadratem liczby trójkątów w submodelach.
W E3D można by wprowadzać dalsze zmiany, jak wyszukiwanie identycznych wierzchołków i wprowadzenie indeksów, rozpoznawanie zwielokrotnionych kształtów (np. wystarczy jedna kopia osi, a w T3D każda musi mieć osobno siatkę). Jednak z ankiet przeprowadzonych wśród użytkowników wynika, że czas wczytywania ani zagadnienia dotyczące plików modeli nie są kluczowe. Na pierwszy plan wysuwa się zapis stanu symulacji oraz oświetlanie scenerii, niemniej zagadnienia te dotyczą wygody i estetyki, a nie samej symulacji.
Z typowo symulacyjnych rzeczy należałoby uealastycznić zależności w sterowaniu lokomotyw poprzez wyprowadzenie ich z C++ do zewnętrznego języka, co wiąże się również uealstycznieniem definiowania animacji w kabinach. Druga potrzebna sprawa to syntezator nagrań dźwiękowych dla kierownika oraz operacji typu próba hamulca, bo obecnie jest to trochę zbyt sztywno robione. Trzecia rzecz, to synchronizacja w multiplayerze. Jako czwartą dałbym przejrzenie kodu pod kątem zacinania się. Nawet na sprzęcie z 60 FPS w każdym miejscu są zauważalne przycięcia. Podejrzewam, że może to być związane z kompilowaniem obiektów w sektorach, a być może są jakieś pętle/rekurencje w fizyce. Być może coś by się dało wydzielić do osobnego wątku (np. kompilację obiektów), ale z tym trzeba ostrożnie, bo szukanie błędów w wątkach będzie udręką.
-
@ShaXbee Może warto popracować nad skryptami, tzn. przede wszystkim stworzyć skrypty generujące .e3d i przede wszystkim pozwalające twórcom zadbać o optymalizację modelu. Przykład: jeżeli twórca stworzy jedną oś, a pozostałe ustawi w modelu jako klony, to .e3d pozwala na zapis takiej właśnie optymalizacji (siatka osi zapisywana jest jednorazowo, klony to tylko indeksy odnoszące się do oryginalnego submodelu oraz właściwe transformy).
A i użytkownicy Blendera też liczą, że kiedyś ktoś im przygotuje skrypty.
-
Skrypt generujący e3d zrobił jakiś czas temu @ISDR. Zatem nie trzeba nad tym pracować. Do Blenedra owszem by się przydały. Tym bardziej, że to darmowy program.
-
@Ra: Przyjrzalem sie Pythonowi (CPython/PyPy), Javascript (V8) i Lua i szczerze mowiac ten ostatni mi sie najbardziej podoba - banalnie sie inetegruje z C, jest relatywnie niewielki, ma latwa skladnie i jest uzywany w wielu grach. Co do normalnych - dawno, dawno temu wrzucilem patch ktory to robil w O(n)
@Tolein: Tak, pracuje nad supportem Pythona, ale chcialbym zeby modele byly w nieco bardziej elastycznym formacie, ktory nie wymaga recznie pisanych parserow...
-
Mam zrobione okolo 70% Pythonowych bindingow biblioteki flatbuffers, ktora mozna by uzyc do serializacji modeli. Czy ktos podjalby sie napisania skryptu do Blendera?
-
Zmiany - projekt pobiera sobie sam zaleznosci i je kompiluje, zamienilem tez przestarzaly GLEW na glbinding ktore daje nam bezpieczne API do OpenGL.
Edit:
Dodana zaleznosc do GLM, ktory zastepuje operacje macierzowe z OpenGL usuniete w profilu Core OpenGL.