•  

    Przez ostatnie 10 miesięcy tworzyłem od zera silnik gier dla Linuxa i Windowsa oparty o Vulkana. Przez ten czas zdążyłem natrzaskać 924 commitów do kodu źródłowego silnika oraz 108 do dedykowanego do niego narzędzia. W tym krótkim wykopkowym wpisie chciałbym się z wami podzielić postępem prac nad jego rozwojem.

    Od ostatniego wpisu zmieniło się sporo, ale nie do końca w samym rdzeniu silnika. Zacznijmy może od tego, co od razu rzuca się w oczy, czyli samochodu. Przez ostatenie dwa miesiące starałem się stworzyć model pojazdu do silnika CLUSEK-RT. Było to zadanie… trudne, ponieważ nie jestem grafikiem i do tej pory robiłem raczej tylko jakieś proste modele. Nie mniej pomyślałem, że trzeba wyjść ze swojej strefy komfortu i wymodelować, a następnie oteksturować samochód. Sama bryła pojazdu to taka trochę wariacja na temat tego jak ludzie w latach ‘80 uważali, że pojazdy będą wyglądać w przyszłości. Model wykonałem w blenderze i łooooooooooooo Panie. Nie było to dla mnie łatwe. Nie to, że Blender jest zły, ależ wprost odwrotnie. Po prostu dla mnie, czyli programisty, który chciał coś wymodelować, stworzenie tak skomplikowanego modelu to był skok na głęboką wodę. Niektóre elementy pojazdu modelowałem wielokrotnie, poniważ ich siatka dziwnie się rozkładała i pojawiały się artefakty. Ogólnie był to niezły sajgon i myślałem, że mi się to nie uda, ale zawsze tłumaczyłem sobie, że to tylko hobby po godzinach i jak się nie uda to w sumie co? Ano nic i skończyłem. Bryła samochodu bez kół ma 68k trójkątów, a każde z kół ma po 8k trójkątów. Nie jest to mało, ale nie potrafiłem zejść niżej. Doszedłem do wniosku jednak, że nie jest to najgorszy wynik jako, że pojazd będzie widoczny przez 90% czasu i będzie zajmował sporą część ekranu. Następnie należało stworzyć tekstury. Tylko… jak?! ¯\_(ツ)_/¯ Jako, że była akurat promocja na Steam na Substance Painter 2022 to kupiłem go. Nie wiedząc o programie KOMPLETNIE nic zacząłem oglądać po pracy codziennie filmy z jego obsługi i jak uznałem, że wiem co i jak to zacząłem teksturowanie. O dziwo, okazało się to nie tak trudne jakby się mogło wydawać. Posiadając zerowe doświadczenie poszło mi to wielokrotnie szybciej, niż modelowanie. Efektem tych wszystkich prac jest samochód, który widzicie na dole tego posta. Chciałbym usłyszeć co myślicie o finalnym renderze, który powstał z użyciem Cycles X w Blenderze. Trochę się obawiam komentarzy od osób, które zajmują się grafiką profesjonalnie, ale krytyka też jest potrzebna (╥﹏╥).

    No dobra dobra, ale dlaczego wrzuciłem render z offline path tracera, a nie ze swojego silnika? Otóż chciałem pokazać jaki model przygotowałem dla mojego silnika bez pokazania obecnego stanu renderera w silniku CLUSEK-RT, gdyż jest on w nie reprezentatywnym stanie (znaczy brzydki jest). Jeżeli ktoś jest zainteresowany jak wygląda obecnie silnik to na końcu tego wpisu jest link do artykułu, gdzie jest zrzut ekranu, a nawet filmik z samego silnika CLUSEK-RT. No dobrze, ale pojawia się naturalnie pytanie - skoro to artykuł o tworzeniu silnika do gier, to czy jego warstwa wizualna nie powinna być najbardziej dopieszczonym elementem? Świetne pytanie, już odpowiadam!

    Stworzenie hybrydowego silnika renderującego na poziomie silników AAA to okazuje się cholernie trudne zadanie. Nie chodzi mi tutaj jednak o poziom trudności porównywalny do nauczenia się obsługi Blendera, czy Substance Paintera. Nie nie nie. Tutaj próg wejścia jest zupełnie inny. Problem główny brzmi: jak to zrobić? Dla osób niezorientowanych, nie można tak po prostu użyć sprzętowego śledzenia promieni (ray tracingu) do uzyskania fotorealistycznego obrazu jak w filmach Pixara. Może tak wynikać z prezentacji Nvidii, ale budżet jaki mamy w 16 ms jest nieludzko ograniczony i możemy co najwyżej rzucić pojedynczy promień dla każdego piksela na ekranie, a to oznacza, że nie możemy użyć słynnej metody “brutal force” jak robią to typowe path tracery jak VRay, czy wspominany już wielokrotnie w tym wpisie Cycles. Jak to zrobić? Po przeczytaniu obu książek od Nvidii na ten temat (Ray Tracing Gems i Ray Tracing Gems II) oraz dużej ilości publikacji naukowych z tej tematyki oraz podejrzeniu jak działają silniki komercyjne gier, odpowiadam: nie wiem. Znaczy mam podejrzenie jak zrobić, ale różne firmy w różnych silnikach stosują różne techniki, które mają zalety oraz wady. Poza tym, jest tam tak trudna matematyka, że momentami po prostu wymiękam. Nie mniej, planuję robić to małymi krokami. Obecnie rasteryzuję scenę i zapisuję do GBuffera masę danych, które zamierzam w następnym kroku użyć do wystrzelenia promieni dla refleksów (1/2 rozdzielczości ekranu). Pomimo wykorzystania tylko połowy rozdzielczości ekranu nadal mogę sobie pozwolić tylko na jeden promień, który będę dobierał losowo (no… prawie losowo, bo użyję importance sampling), a to oznacza straszny szum. Postaram się go rozwiązać za pomocą algorytmu SVGF (Spatiotemporal Variance-Guided Filtering), który w uproszczeniu akumuluje dane, a następnie rozmazuje powierzchnię, aby rozwiązać problem szumu. To oczywiście rozwiązuje tylko refleksy, a co z irradiancją? Nie możemy sobie pozwolić na Global Illumination w prosty sposób, bo nie utrzymamy akceptowalnej liczby klatek na sekundę. Co z wyższymi rozdzielczościami (np. 4k)? Czy stosować jakiś upsampling? Pytań jak widzicie są setki, a ja tutaj postarałem się poruszyć tylko niektóre, aby was nie zanudzić. Ogólnie technika śledzenia promieni jest obecnie w fazie, gdzie każdego miesiąca powstaje jakaś nowa technika, która pcha do przodu postęp w tej technologii. Nie ma obecnie idealnego rozwiązania na te problemy i trzeba bardzo dużo czytać i szukać akceptowalnego rozwiązania, które można zastosować do silnika. Mam nadzieję, że uda mi się znaleźć rozwiązania wszystkich moich problemów i w kolejnych artykułach będę mógł się z wami dzielić detalami implementacyjnymi, a nie tylko bajkami na temat tego, co fajnie by było mieć w silniku, ale jest trudne, bo brzmi to jak typowe narzekanie.

    Także to tyle w tym wpisie. Z tego co widzę powstał niezły potworek. Miało być krótko, bo w sumie rozwój silnika idzie bardzo powoli, a wyszło jak zawsze. Zainteresowanych bardziej detalami implementacyjnymi zapraszam jednak do mojego artykułu po angielsku na platformie Linkedin, gdzie bardziej rzeczowo i szczegółowo opisuje zmiany w silniku CLUSEK-RT oraz opowiadam o narzędziu pomocniczym CLUSEK-TT, które to stworzyłem dla mojego silnika we Flutterze.

    LINK DO ARTYKUŁU NA PLATFORMIE LINKEDIN

    LINK DO PROJEKTU CLUSEK-RT

    LINK DO PROJEKTU CLUSEK-TT

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

    źródło: render5.jpg

  •  

    Panie @wykop jak dodajecie 2FA do kluczy API to powinno być indywidualne 2FA dla klucza, a nie, że ja teraz w 3rdparty aplikacji (albo nawet jakieś 1stparty, której nie ufam) mam podać mój klucz 2FA do logowania pełnego. Po to są klucze API z ograniczonym dostępem, żeby ten dostęp ograniczyć, a nie rozdawać mój 2FA i liczyć, że ktoś się nie będzie próbował nim zalogować do pełnego dostępu.

    Po za tym psucie wszystkich aplikacji korzystających z API i wymaganie nagle 2FA na tym tylko zmusza ludzi do wyłączenia 2FA, co jest najgorszym efektem i nigdy nie powinniście tego zrobić. Już i tak trudno ludzi przekonać dlaczego powinni używać 2FA, a wy jeszcze to utrudniacie.

    Z mojej strony wygląda to tak, że przestane przeglądać wykop na urządzeniu mobilnym, a to też chyba z waszej perspektywy również jest minus.

    #wykop #security #owmbugi
    pokaż całość

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

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