•  

    Po pierwsze chciałem podziękować za odzew pod moim ostatnim postem dotyczącym silnika do gier CLUSEK. Było tam również wiele wartościowych komentarzy, który skłoniły mnie do refleksji i chciałem was zapytać o radę w sprawie rozwoju tego silnika.

    Otóż kilka osób wskazało mi niedociągnięcia w silniku oraz elementy, które mógłbym zrobić lepiej. W sumie głównym problemem jest brak refleksji oraz brak warstwy abstrakcji w API graficznym (co wskazał mi @mwl4). Dało mi to do myślenia i poczytałem jak robią to takie silniki jak UE4, czy idTech, które są moim zdaniem wiodącymi silnikami w gamedev i oni mają refleksję rozwiązaną za pomocą niestety zewnętrznego narzędzia. Narzędzie takie jest uruchamiane przed samym procesem kompilacji i przeszkukuje kod w poszukiwaniu makr i na ich podstawie generuje kod, który potem można używać w silniku. Ogólnie głowa mała jak skomplikowany jest to mechanizm i jak pod tym względem ograniczony jest C++. Wiedziałem, że sam C++ nie wspiera reflekji, ale myślałem, że mądrzy ludzie wymyślili jakiś łatwy sposób na rozwiązanie tego, ale widzę, że nie. No, ale cóż widocznie to jest jedyna słuszna droga.

    No dobra, fajnie fajnie, że sobie piszę to co napisałem wyżej, ale do czego dążę? Naszła mnie głęboka myśl stworznia silnika od nowa z więdzą, którą już posiadam i chciałem was zapytać, czy to dobry pomysł oraz czy ma to sens. Otóż nie chciałem po prostu napisać go od nowa i tyle, bo to bez sensu, ale napisać silnik od nowa na nowym API (DirectX 12 lub Vulkan) i silnik oprzeć w pełni na RayTracingu (no dobra nie w pełni, bo kilka małych elementów warto zrobić rasteryzacją) z w pełni dynamicznym oświetleniem co właśnie umożliwa śledzenie promienii. Zrobiłem nawet ultra ubogi demko, które wygląda średnio i jest strasznie zaszumione, ale robiłem je na szybko i chciałem sprawdzić swoje umiejętności (zdjęcie w tym wpisie). Oczywiście napisanie tego dobrze zajęło by pewnie wiele miesięcy, ale może warto, bo mało jest (ja nie znam żadnego) silników open-source z pełnym RayTracingiem. Teraz pytanie do was, warto pisać CLUSKA 2, czy tam CLUSKA-RTX, czy może lepiej zostać przy obecnym silniku i rozwijać go dalej?

    No dobra, to jakie mam opcje. Bramka numer jeden, czyli nadal pisać CLUSKA z rasteryzacją i dodawać kolejne fajne elementy do niego. Bramka numer dwa napisać nowy silnik z RayTracingiem na DirectX 12 pod Windowsa i może pod Xbox. Bramka numer trzy napisać nowy silnik z RayTracingiem na Vulkan pod Windowsa oraz Linuxa.

    Pierwszej opcji nie muszę omawiać, bo jest oczywista i prosta. Dwie kolejne są ciekawsze, bo różnią się tylko API. Jak wiadomo jest Vulkan i DirectX 12 przy czym różnią się one dość znacząco i Vulkan jest bardziej skomplikowany, ale silnik można by wtedy odpalić również na Linuxie, ale pytanie brzmi czy warto, bo ile osób tutaj na wykopie gra w gry na Linuxie, a do tego na mocnym sprzęcie, który wspiera śledzenie promienii? Vulkan może być po prostu niszą, a DirectX 12 jest zdecydowanie lepszy i prostszy i to nie są tylko moje wymysły, bo odpalilem sobie na moim kompie z RTX 3080 popularny silnik Unity (w wersji 2020.1.15f1) i framerate na Vulkan był po prostu słaby i co gorsza niestabilny. Wyglądało to tak jak by coś (może jakiś command buffer) co jakiś czas powodował spadek klatek tak o połowę i następowało to regularnie co około pół sekundy. Ja wiem, że może ja się nie znam, jestem głupi i powinienem zbierać cebulę, a nie brać się za pisanie silnika (kolejnego), ale no skoro zespół Unity w którym pracują na prawde eksperci mają problem z napisaniem dobrego wrappera do Vulkana to ja tego nie widzę i nie wiem, czy pisanie na Vulkanie nie jest po prostu sztuką dla sztuki, ale może się mylę i połowa mirków i mirabelek siedzi na Linuxie i ma karty RTX lub najnowsze od AMD, które też wspierają RayTracing.

    TLDR: Nie wiem, czy dalej pisać silnik rasteryzujący na DX11, czy napisać nowy RayTracinowy na VK lub DX12. Co myślicie? Czujecie wewnętrzną potrzebę gier akurat na Vulkanie lub gracie na Linuxie?

    #programowanie #gamedev #gry #directx #grafikakomputerowa #physx #clusek
    pokaż całość

    źródło: wykop_rtx_on_2.png

    Jak żyć?

    • 11 głosów (14.47%)
      Pisz dalej CLUSKA na DirectX 11
    • 26 głosów (34.21%)
      RTX ON!!! Wybierz DirectX 12!
    • 39 głosów (51.32%)
      RTX ON!!! Wybierz Vulkana, bo w Linuxie siła!
    •  

      @evaunit01:
      Pewnie masz rację, ale intersuje mnie najbardziej warstwa wizualna, a więc trzeba by szybko podjąć decyzję wobec API graficznego.

      @qarmin:
      Zgadzam się, ale pisząc silnik pod RayTracing pisze się jednak pod Windowsa/Linuxa. Tworzenie silnika hybrydowego ma wiele wad i ograniczeń.

      @materazzi:
      Mądrze powiedziane. Problem w tym, że wiesz jak jest. Po czasie widzi się wiele rzeczy, które można by zrobić lepiej, ale to też może być droga do nikąd, bo zawsze można coś zrobić lepiej. ( ͡° ͜ʖ ͡°)
      pokaż całość

    •  

      @Damiann19:
      Tak właśnie chciałem dopisać backend do renderów i wiem, że pisałeś, że nie mam abstrakcji, ale jak się na początku z tym zawali to potem trudno to dopisać. ( ͡° ͜ʖ ͡°)

      Co do trudności Vulkana i Unity to ja wiem, że oni mogli to słabo napisać i Vulkan nie jest hiper-trudny, ale mimo to jest przepaść między DX11/OpenGL, a DX12/VK i chodziło mi o to, że bardzo wiele osób uzyskuje bardzo słabe rezultaty na nowym API i strzeliłem w Unity, bo im to działa tragicznie. W sumie to aż sobie screena zrobiłem bo jest o połowę niższa wydajność w niektórych sytuacjach, a to wbija w fotel. Co do Epica i Id Software to zgadzam się i to szczególnie z IdSoftware, bo oni to wymiatają z Vulkanem i w Doomie uzyskują jakieś szalone ilości klatek i to nawet na nienajmocniejszym sprzęcie. Nie mniej samo przekazywanie danych do GPU się strasznie utrudnia i trzeba używać różne tricki, co mam na myśli? Na przykład zamiast jednego prostego Uniform Buffer lub Constant Buffera to trzeba tworzyć jakieś skomplikowane konstrukcje jak Ring Buffery, które mają N buforów i potem się po nich przechodzi lub inne tricki, a to wszystko, żeby wyświetlić obiekty z różnymi parametrami. Można też użyć Push Constant, żeby pchnąć dane, ale jak ich jest za dużo to też dupa blada. Także takie proste rzeczy, a trzeba sporo pomyśleć, żeby to zrobić dobrze architektonicznie. Jeżeli piszę głupty to mnie popraw, bo chciałbym się mylić XD

      @mwl4:
      To rozwiązanie nie jest wcale takie dobre, bo trzeba jeszcze raz powtarzać pola, które definiuje się w samej klasie, a to może prowadzić do błędów. Wiem, że to jest lepsze od tego co mam, ale no lepiej od razu przeskoczyć na coś dużo lepszego, niż trochę lepszego.
      pokaż całość

    • więcej komentarzy (7)

...to tylko najnowsze aktywności użytkownika bilek993

Zobacz wszystkie dodane znaleziska, komentarze i wpisy korzystając z menu powyżej.