Silnik gier 3D w C++

9

Cześć!

Z góry ostrzegam, że ten mój post będzie bardzo długi. Nie mniej mam nadzieję, że nie będzie to nudne i uda mi się złapać czyjąś uwagę i kogoś to zainteresuje. Każda opinia jest dla mnie cenna i postaram się odpowiedzieć, jeżeli tylko będę potrafił udzielić merytorycznej odpowiedzi.

Jakieś 9 miesięcy temu wpadłem na pomysł, że muszę sobie napisać jakiś projekcik po godzinach. Chciałem, żeby było to coś ambitnego i wyróżniającego się, a nie kolejnego CRUDa, chociaż ja nic nie mam do CRUDów. Także w mojej głowie zrodził się pomysł stworzenia własnego silnika do gier od zera. Zawsze lubiłem zabawę silnikami do gier takimi jak Unity, czy Unreal Engine (kiedyś UDK, a teraz UE4). Pomyślałem jednak, że warto po godzinach sobie zgłębić jak te silniki działają i napisać własny taki silnik. Tak właśnie zrodził się projekt "CLUSEK".

CLUSEK to mój autorski silnik do gier, który napisałem od zera z wykorzystaniem DirectX 11 oraz PhysX (dokładne informacje na temat zależności znajdują się w dokumentacji). Silnik ma zaimplementowane na tyle dużo rzeczy, że pomyślałem, że pochwalę się nim tutaj na forum. Trochę boję się krytyki, ale kto nie ryzykuje ten nic nie ma.

No dobra, ale co ma w sobie ten CLUSEK? Cała architektura oparta o ECS (Entity Component System), który umożliwia mi dość szybko dodawać nowe elementy do silnika bez modyfikowania dużych kawałków kodu. Po prostu dodaje nowy system, który coś robi z encjami, które to składają się z komponentów. Kolejna sprawa to dość zaawansowany na tą chwilę renderer w DirectX 11, który ma sporo elementów, którymi mogę się pochwalić. Cienie, renderowanie oparte na fizyce (PBR), teren z teselacją to tylko kilka rzeczy, które ma ten renderer, a jest ich o wiele więcej. Fizyka oparta o bibliotekę Nvidia PhysX w wersji 4.1, która pozwala mi symulować bryły sztywne w dość realistyczny i wydajny sposób. Do tego niesamowicie zaawansowana symulacja pojazdów czterokołowych, która obejmuje takie podstawowe rzeczy jak skrzynia biegów, czy sprzęgło ale też bardziej zaawnsowane jak na przykład stabilizator poprzeczny. No i oczywiście edytor, który pozwala zarówno modyfikować wszystko z poziomu UI silnik po wciśnięciu "~", jak i z poziomu plików JSON oraz własnego formatu danych. Jest też logger, który pozwala na zapis do konsoli lub pliku oraz posiada różne poziomy loggowania (debug, warning oraz error).

Także troszkę tych elementów już mam i dlatego gotowy jestem pokazać jak to wszystko pospawane ze sobą razem wygląda. Poniżej kilka zdjęć z silnika. Starałem się wybrać jakieś fajne ujęcia, które pokazują mocne strony silnika.
CLUSEK 0

CLUSEK 1

CLUSEK 2

CLUSEK 3

Także to tyle w tym temacie. Na koniec jeszcze chciałem wam podrzucić link do repozytorium kodu, który jest tutaj. Z góry ostrzegam, że repozytorium jest ogromne. Także polecam kod przeglądać bezpośrednio na GitHub. Jeżeli chcecie sobie to potestować, ale nie chcecie tracić czasu na długą budowę kodu to polecam pobrać wersję wykonywalną projektu. Jest to skompilowana wersja ze wszystkimi wymaganymi plikami. Poza tym pobieranie tego projektu z repozytorium przez dużą liczę osób może być problematyczne przez dość restrykcyjną politykę GitHub dla projektów korzystających z LFS. Cóż... może kiedyś zmigruje ten projekt na Bitbucket lub na GitLab.

0

Czy uda mi się znaleźć kogoś z gamedev, kto rzuci okiem na kod źródłowy i udzieli jakichś rad?

0

Fajna sprawa. Nie znam się na tym, ale też pewnie w miarę upływu czasu zmierzę się z tym tematem. Mam pytanie trochę może z innej beczki. A jak taki silnik 3D ma współpracować z okularami VR i czy coś będziesz próbował robić w kierunku rzeczywistości rozszerzonej z tym silnikiem i pracy ze sprzętem VR. Masz jakieś wnioski na ten temat?

0
shab napisał(a):

Fajna sprawa. Nie znam się na tym, ale też pewnie w miarę upływu czasu zmierzę się z tym tematem. Mam pytanie trochę może z innej beczki. A jak taki silnik 3D ma współpracować z okularami VR i czy coś będziesz próbował robić w kierunku rzeczywistości rozszerzonej z tym silnikiem i pracy ze sprzętem VR. Masz jakieś wnioski na ten temat?

Nie zagłębiałem się w ten temat, ale myślę, że będzie to kupa pracy. Po pierwsze na pewno trzeba będzie zaimplementować SDK do obsługi gogli, czyli np. Oculus Rift SDK. Jeżeli ktoś by chciał mieć kilka rodzajów gogli to myślę, że trzeba zaimplementować kilka SDK. Potem trzeba dostosować renderer do tego. Nie jestem pewien jak i nie chciałbym Cię wprowadzić w błąd, ale pewnie trzeba renderować do wielu render targetów dla prawego i lewego oka, następnie do przekształcić tak, żeby obraz wyglądał poprawnie w soczewkach, a następnie połączyć w jeden render target za pomocą jakiegoś comput shadera. Także to może być niewyobrażalna ilość pracy. Także w 99% zastosowań lepiej będzie użyć Unity lub UE4 moim zdaniem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1