Hejka wykopki! Mamy miesiąc…

Categories Programowanie

Hejka wykopki!

Mamy miesiąc lipiec, a to oznacza, że jak zawsze pora na nowy wpis na wykopie o CLUSKU. Muszę jednak na samym początku przyznać, że był to najcięższy miesiąc do tej pory w rozwoju silnika i nie chodzi tutaj o elementy, które zostały dodane, bo te nie wywołują fajerwerk, ponieważ w poprzednim miesiącu skupiłem się na rozwoju edytora w silniku. To był najcięższy miesiąc dla mnie prywatnie, ponieważ przygotowywałem się do obrony pracy magisterskiej. Było sporo do przygotowania się do samej obrony, a dokładnie do pytań do obrony, których miałem trochę do ogarnięcia, ale nie mniej udało się. Obroniłem się (przez Internet (-‸ლ)) i od dziś jestem magistrem Informatyki. Także teraz będę miał więcej czasu na rozwój silnika i mam nadzieję, że w najbliższym czasie (lipiec, sierpień, wrzesień) wprowadzę duże zmiany. Chciałbym, żeby po kolejnej aktualizacji terenu (dokładnie to natury) wywoływało efekt WOW, a czy mi się to uda? Nie wiem, ale już czytam artykuły naukowe o renderowaniu trawy i drzew.

No dobra mirki i mirabelki to nie jest wpis o moim prywatnym życiu, także nie będę już więcej w tym poście o nim pisał, ale chciałem tylko o tym temacie wspomnieć, żeby nie było pytań dlaczego tak wolno silnik się zmieni, bo ano dlatego. Nie mniej do tematu. W ostatnim czasie uwagę przywiązałem do rozbudowy silnika i nawet się to udało, ponieważ lista zmian jest dość obszerna i prezentuje się tak:
– Dodano edytor encji;
– Dodano edytor komponentów dla każdego z komponentów;
– Encje mogą być wybierane w dedykowanym oknie (widok listy encji);
– Dodano klikanie na obiekty (encje) na scenie;
– Przebudowano cały edytor, aby był bardziej przystosowany do podejścia ECS;
– Dodano edytor materiałów fizycznych w czasie rzeczywistym;
– Naprawiono sypanie się silnika, gdy nie ma żadnego aktora fizycznego na scenie;
– Dodano obliczanie maksymalnej długości promienia;
– Naprawiono błąd z niepoprawną obsługą myszki oraz klawiatury w przypadku korzystania z ImGui;
– Dodano komponent komentarzy;
– Usunięto „TransformManipulateWindow” i przeniesiono jego logikę w inne miejsce;
– Usunięto „TerrainTessellationWindow” i przeniesiono jego logikę w inne miejsce;
– Usunięto „VehicleDetailsWindow” i przeniesiono jego logikę w inne miejsce;
– Dodano więcej informacji do dokumentacji;
– Podpięto brakujące komponenty w „Entity Viewer”;
– Dodano narzędzie do wyszukiwania kamery;
– Dodano zunifikowany komperator liczb zmiennoprzecinkowych;
– Naprawiono dziwne obroty myszki;
– Zaktualizowany komunikaty myszki;
– Poprawiono nazewnictwo macierzy;
– Dodano przetrzymywanie identyfikatora systemu fizyki;
– Dodano zunifikowany sposób obsługi pól tekstowych w edytorze dla std::string.

Jak widać sporo tego jest, ale są to raczej takie małe rzeczy. Oczywiście jest kilka większy i na nich postaram się teraz skupić i je opisać.

Pierwsza ogromna zmiana to możliwość klikania na obiekty. Ja wiem, że to brzmi żałośnie, ale wcześniej tego po prostu nie było. Teraz to jest i jest wykorzystywane w edytorze do wybierania obiektów, którymi chcemy manipulować. Mimo, że ta funkcjonalność brzmi banalnie do napisania to taka nie jest. Bardzo inspirowałem się książką „Essential Mathematics for Games and Interactive Applications: A Programmer’s Guide, Second Edition” autorstwa James M. Van Verth oraz Lars M. Bishop, którą każdemu polecam. Książka ogólnie dotyka wiele elementów matematyki w grach i aplikacjach związanych z grafiką/fizyką. Nie jest to tania książka, ale warto kupić, bo przynajmniej autorom coś wpadnie do kieszeni za ich ciężką pracę. Wracając jednak do tematu to zaimplementowałem wykrywanie przecięcia pomiędzy promieniem rzuconym z kamery, który jest modyfikowany przez pozycję kliknięcia na ekranie z wygenerowanymi bryłami OBB dla obiektów na scenie. Kod za to odpowiedzialny znajdziecie tutaj. Jest to algorytm bardzo szybki, ale jednocześnie nie zbyt dokładny. Powoduje to, że w niektórych sytuacjach klikanie na obiekty może być utrudnione. Rozważam w przyszłości dodanie drugiego algorytmu, który wykrywa przecięcie pomiędzy promieniem, a trójkątami siatki, które budują obiekt. Jest to bardzo wolna metoda, ale w połączeniu z obecną będzie to myślę akceptowalne czasowo.

Drugą ogromną zmianą jest edytor encji, który pozwala na modyfikowanie każdego z komponentów w locie. Jest to ogromna sprawa, ponieważ wreszcie nie trzeba restartować edytora i wykonywać zmian w pliku json, aby zobaczyć zmiany. Teraz zmiany można zobaczyć natychmiast po zmianie parametru i sprawdzić jak się zachowuje dana encja w takim przypadku. Nie potrafię wyrazić chyba słowami jak bardzo to oszczędza czas w przypadku tworzeniu ogromnej sceny, a w takie sceny ten silnik celuje.

Jako, że silnik się rozrasta postanowiłem dodać nowy rozdział do dokumentacji i dotyczy on architektury silnika. Tą nową część dokumentacji znajdziecie tutaj i jest ona dość spora. Znajduje się w niej wprowadzenie teoretyczne razem z fajnym grafem obrazującym jak to działa oraz następnie opis jak dodać nowe encje, komponenty oraz systemy. Jest to moim zdaniem opisane w prostym sposób, który za rączkę prowadzi krok po kroku razem z przykładowym kodem, aby dodać ten element, który chcemy. Wiem, że obsługa tego silnika nie jest prosta i dlatego staram się ją upraszczać i dokumentować. Tak nawiasem mówiąc śmiałem się kiedyś z UE4, że ukrywa sporo magii pod makrami, a teraz robię to samo. Także chyba taki z natury jest C++ i nic z tym nie można zrobić.

Kolejny element, który chciałem wam opisać to edytor fizycznych materiałów. Od teraz można modyfikować materiały w locie za pomocą nowego okna, które zostało dodane. Dzięki temu nie trzeba restartować silnika, a jak wszyscy wiemy dobranie parametrów fizycznych nie jest proste, także taki ukłon w stronę designerów.

Ostatni element na którym się chciał tutaj skupić to nowy komponent – „Comment Component”. Programiści C++ (i innych języków programowania) mają komentarze. Chciałem, żeby nie tylko w kodzie można było tworzyć komentarze dla potomnych, ale również w samym edytorze. Jak mapa się rozrasta to czasem chciało by się napisać dlaczego to drzewo zostało tutaj postawione lub dlaczego ten samochód ma takie parametry. Dzięki temu komponentowy można to łatwo zrobić. Komponent ten jest widoczny w pliku JSON dla mapy oraz w samym edytorze w silniku CLUSEK. Komponent ten nie jest używany przez żadne systemy, więc raczej nie wpływa na optymalizację.

Także to tyle moi drodzy z wykopu. Mam nadzieję, że udało mi się zainteresować was na tyle, że dostanę od was plusika tutaj na mirkoblogu oraz gwiazdkę na samym GitHub. Zapraszam również do pobrania wersji wykonywalnej silnika oraz przeglądania kodu źródłowego. Zaznaczam jednak, że repo jest dość duże i korzysta z Git LFS także jego sklonowanie może potrwać wieki, a jego fork może wam pochłonąć cały dostępny transfer na GitHub. Także pamiętajcie o tym! Poza tym zapraszam jak zawsze do mojego artykułu na Linkedin, gdzie opisuje to samo tylko, że w języku angielskim.

Kod źródłowy
Wersja wykonywalna
Artykuł po angielsku

#programowanie #gamedev #gry #directx #grafikakomputerowa #physx #clusek