•  

    Cześć wykopki,

    Chciałem wam podrzucić kolejny artykuł na temat matematyki w gamedevie. Tym razem najważniejsza rzecz przy tworzeniu gier, czyli iloczyn skalarny. Ten operator matematyczny jest wykorzystywany praktycznie przy każdym elemencie. W moim artykule opisałem go słownie oraz pokazałem obrazowo jak on się zmienia, bo o dziwo nie zmienia się on liniowo. Także zapraszam do lektury. Jak kogoś zainteresuje to możnać dać like na Linkedin, nie obrażę się.

    LINK DO ARTYKUŁU

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

    źródło: 0.png

  •  

    Hej mirki i mirabelki!

    Wektory jednostkowe oraz długość wektorów to nie brzmi jak temat o którym by się chciało czytać po pracy/uczelni. Ja wiem, ale spróbujcie! Oto link do mojego kolejnego artykułu na Linkedin o tworzeniu silników do gier.

    Tak jak pisałem tematyka dotyczy długości wektorów oraz wektorów jednostkowych. Staram się wytłumaczyć co to jest i jak tego użyć. Ograniczam taką suchą teorię i raczej staram się na przykładach wszystko pokazać. Przeprowadzam również krok po kroku z czego wynikają wzory, żeby nie uczyć się ich na pamięc, bo to bez sens. Należy zrozumieć, a nie wykuć. Na to właśnie stawiam, także zapraszam do lektury.

    Jeżeli komuś się spodoba to może dać łapkę w górę na Linkedin lub skomentować. Dzięki temu artykuł może dotrzeć do większej liczby osób, a co za tym idzie więcej osób może się czegoś fajnego i przydanego nauczyć. Piszę te artykuły non-profit, więc bez obaw. Nic na tym nie zarabiam i robię to, żeby dzielić się po prostu wiedzą.

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

    źródło: Cover.png

  •  

    Hej!

    Kiedyś obiecałem, że będę poza moim silnikiem CLUSEK, będę też wrzucał wiedzę na temat różnych tematów dotycznących gamedev. Jako, że nie rzucam słów na wiatr to zapraszam do przeczytania mojego artykułu na linkedin TUTAJ. Jest to mój pierwszy taki poważny artykuł na matematyczno/programistyczne tematy, a więc proszę o wyrozumiałość, szczególnie, że jest to po angielsku, a to nie jest mój natywny język. Nie mniej mam nadzieję, że znajdzie się chociaż jeden wykopek, któremu pomogę zrozumieć podstawy tego, czym są wektory.

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

    źródło: Cover.png

    •  

      Komentarz usunięty przez autora

    •  

      @cppguy: I tak i nie. Olimpiada to specyficzne miejsce, tam idą ludzie, którzy uczą się bardzo dużo, a więc bez predyspozycji będzie się po prostu od nich odstawać. Nie mniej taką matematykę wyższą to myślę, że mógłby się nauczyć każdy, gdyby tylko chciał, a algebrę liniową to już na 100%. Tam idą proste operacje, które każdy powinien ogaraniać i jest to tylko obudowane w specyficzne struktury matematyczne.

    • więcej komentarzy (6)

  •  

    Szybkie info z silnika CLUSEK.

    Zapraszam do mojego wpisu na Linkedin, gdzie możecie sobie poczytać to co ostatnio, ale po angielsku. Poza tym będę też wrzucał tam artykuły na temat podstaw game devu, czyli algebra liniowa (wektory, macierze, itp.), renderer, fizyka, AI (może jakieś sieci neuronowe i/lub algorytmy ewolucyjne). Wszystko w prostej postaci. Chcę, aby każdy mógł to zrozumieć i to bez tego uczelnianego podejścia z ogromną teorią. Tak więc zapraszam!

    Aaaaaaaa! Link, to TUTAJ. Dobrze, bo bym zapomniał. (╭☞σ ͜ʖσ)╭☞

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

  •  

    Hej mirki i mirabelki!

    Wracam do was z kolejnym wpisem na temat silnika gier CLUSEK. Ostatni wpis był już dość dawno temu. Nie mniej nie chciałem zasypywać wykopu silnikiem w kompletnie niestabilnej wersji i dlatego dzisiaj wrzucam kolejny obszerny wpis na temat tego silnika gier, a co ciekawe dzisiaj mija prawie 5 miesięcy od pierwszego commita do tego repozytorium. Można powiedzieć, że dość sporo czasu to powstawało, ale… jestem z tego w pewien sposób dumny. Pisanie tego silnika oraz tych wpisów na jego temat kosztowało mnie wiele poświęceń, ponieważ robię to w wolnym czasie i za darmo, ale myślę, że warto. Warto, żeby uczynić wykop lepszym miejscem i żeby można było z tego miejsca wynieść też trochę wiedzy na temat takiej dość trudnej gałęzi IT. Myślałem też o tym, żeby tłumaczyć moje artykuły na język angielski i wrzucać na blog na Linkedin, ale nie wiem jakie by to miało zasięgi… Cóż, muszę o tym kiedyś pomyśleć.

    Pod moim poprzednim wpisem, dostałem komentarz od @FEAofTruss, żebym pisał coś więcej. Trochę wtedy marudziłem, że nie, bo coś tam coś tam. No… tak naprawdę jestem trochę leniwy ( ͡° ʖ̯ ͡°). Nie mniej postanowiłem przezwyciężyć moje lekkie lenistwo i napisać ten wpis. Ostrzegam z góry, że będzie on bardzo bardzo długi, ale mam nadzieję, że nie nudy, ale wypchany wartościową wiedzą. Jednakże! Zanim przejdziemy do części merytorycznej mam małą prośbę, która was nic nie kosztuje, a mnie pokazuje, że ktoś to jednak czyta i moja praca nie idzie do śmietnika. Proszę o plusowanie tego wpisu, jeżeli komuś się spodoba i/lub uzna go za przydatny oraz dawanie gwiazdek repo tego silnika na Github. Szczególnie gwiazdki są dla mnie ważne, bo potem można pochwalić się takim repo z dużą liczbą gwiazdek.

    To tyle ogłoszeń parafialnych i teraz pora na mięsko, czyli informacje o silniku. Od ostatniego czasu przez 90% czasu skupiałem się na fizyce. Był to temat, który chcąc nie chcąc dość mocno mnie pochłonął. Pozostały czas poświęciłem na inne rzeczy, które też z mojej perspektywy są dość ważne. Oto pełna lista tego co zostało zrobione przez ten czas:
    * Dodano obsługę pojazdów czterokołowych;
    * Dodano możliwość sterowania pojazdem za pomocą klawiatury oraz kontrolera do gier;
    * Zmieniono sterowanie kamerą dla kontrolera gier;
    * Dodano debugowe UI do wizualizacji fizyki pojazdu;
    * Dodano nowy model (sześcian ścięty na połowie swojej wysokości) z teksturami oraz materiałami;
    * Przebudowano mapę świata;
    * Dodano wsparcie dla kwaternionów przy rotacji;
    * Dodano tryb wymuszonej macierzy, który umożliwia bezpośrednie ustawienie macierzy dla zadanej encji;
    * Rozbudowano dokumentację (plik README.md);
    * Dodano generowanie siatki walca oraz sześcianu dla systemu fizyki;
    * Dodano dwa komponenty fizyczne komponenty - statyczny oraz dynamiczny walec;
    * Dodano logowanie większej ilości informacji w systemie fizyki;
    * Zmieniono obsługę błędów biblioteki PhysX;
    * Dodano informację w loggerze na temat czasu ładowania silnika;
    * Wprowadzono lepszą obsługę błędów w loggera;

    Fizyka, fizyczka, fizyniusia, fizyniusiunia…. Fajna dziedzina nauk ścisłych, ale bardzo ciężka. Powiem szczerze, że dopóki nie zacząłem dopisywać fizyki pojazdów opartą o PhysX oraz Vehicle SDK to nie wiedziałem jak trudna dziedzina to jest. Naprawdę czapki z głów dla fizyków, bo ich praca oraz wiedza jest potrzebna. Fajnie jednak, gdyby biblioteka fizyczna zapewniła wystarczające obudowanie tego w taki sposób, żeby programista, który tworzy silnik mógł w łatwy sposób korzystać z dobrodziejstw fizyków bez bycia taką osobą. Jednocześnie fajnie, gdyby kod takiej biblioteki był pisany przez świetnych programistów C/C++. Fajnie gdyby tak był, ale w przypadku biblioteki PhysX od Nvidii tak nie ma. Jeżeli korzystacie z nowego kodu, który jest tworzony przez Nvidię to jest źle, ale nie tragicznie. Jest to nawet logiczne, ale jeżeli traficie na kod tworzony przez firmię Ageia to katastrofa. Po prostu płacz i łzy. Gdyby ktoś nie wiedział co to za firma Ageia to w skrócie taka firma, która opracowywała bibliotekę fizyczną, która następnie została pochłonięta przez Nvidię i wcielona jako flagowy produkt o nazwie Nvidia PhysX. Niech was jednak nazwa nie zwiedzie, oni kupili ten kod od innej firmy. Teoretycznie ten kod został cały przepisany i praktycznie nie powinno się na niego natrafić w najnowszej wersji, ale… No gorzej kiedy teoria spotyka się z praktyką i dostajemy sieczkę, którą trzeba analizować, ponieważ dokumentacja jest katastrofalnie wprost zła. Żeby nie być gołosłownym i nie mówić ogólnikami to wejdźmy do przykładów z życia. Przez sporą część czasu implementowałem fizykę pojazdów czterokołowych. Oczywiście zacząłem od dokumentancji do której link macie tutaj. Wszystko super, jest tam opisane jak ustawić najmniejsze detale, takie jak np. siła sprzęgła, które jest wyrażona w prawdziwych jednostkach, bo w kg m^2 s^-1, czy też ustawić zużycie opony. Po prostu GENIALNE. Każdy taki szczegół z symulacji fizyki kół jest opisany. Gorzej z pobraniem potem pozycji takiego koła. Zapytacie, o co chodzi? Zasymulowaliście to wszystko i teraz fajnie by taką pozycję koła było pobrać. No, ale to są takie banały, że nie ma tego w dokumentacji. Hmmmm, no ale jest stackoverflow, na pewno ktoś miał problem z pobraniem tej pozycji koła. Prawda? Nieprawda. Nikt o takie coś nie zapytał. W takim przypadku można po prostu zadać pytanie i dostać odpowiedź. Napisać można, ale niestety nikt nie zna odpowiedzi na to pytanie. Skąd ja to wszystko wiem? Bo szukałem kilka dni, a potem sam zadałem pytanie i nikt mi nawet nie odpisał. Po prostu genialnie, ale po długich przemyśleniach udało mi się to zrobić i teraz dla przyszłych pokoleń opiszę jak to zrobić. Musicie pobrać globalną transformację (pozycję i rotację) rdzenie pojazdu (prostym językiem podwozia) i uczynić z niej macierz. Nazwijmy tą macierz M1. Następnie musicie utworzyć drugą macierz M2, która to jest lokalną trasformacją danego koła. Teraz musimy dla dwóch kół (tych po prawej stronie) wykonać rotację o 90 stopni względem osi Y. Ten krok jest wymagany, aby koła były poprawną stroną na zewnątrz pojazdu. Teraz jako, że jest to lokalna trasformacja to nie możemy bezpośrednio przenieść tego obiektu do naszego świata 3D, żeby to zrobić to potrzebujemy wiedzy z algebry liniowej. Dzięki tej wiedzy, wykonujemy operację mnożenia w taki sposób, że M3 = M1 * M2. Teraz nasza macierz M3 to jest macierz, która przedstawia dokładnie opis naszego koła w przestrzeni 3D. Metoda, która odpowiada za całą tą logikę w moim kodzie znajduje się w metodzie UpdateVehicles w klasie PhysicsSystem. W moim przypadku trzeba było jeszcze przebudować TransformComponent oraz cały proces obsługi tego komponentu, ponieważ nie przewidziałem podczas projektowania architektury tego silnika, że będzie potrzeba przekazywać bezpośrednio macierze i myślałem, że będzie się pracować na samej rotacji oraz translacji jako takich, ponieważ kto by z palca macierze przekazywał. Takie rzeczy powinny być moim zdaniem ukryte przez programistami gameplayu. Pomyliłem się jednak bardzo mocno. I teraz pytanie, czy to nie jest chore? Inne silniki fizyki mają możliwość pobrania globalnej pozycji bez całej tej otoczki. To jest dla mnie nienormalne, jeżeli istnieje inny sposób to jeszcze większa porażka, że nie udało mi się tego znaleźć. Ale nie można na tym skończyć. Przykłady (snippets), które Nvidia dostarcza do swojej biblioteki PhysX są jeszcze gorsze. Są pisane w sposób, który po prostu jest tragiczny i niezgodny z żadnymi zasadami programowania w C++. Ja nie jestem genialnym programistą C++, ale to co się dzieje w tym kodzie przekracza moje najgorsze koszmary. Przykład? Proszę was bardzo! Przeglądając te przykłady, które są dostarczone bardzo szybko natraficie, że non stop pojawia się wmieszany w resztę kodu, nawet nie oddzielony pustymi liniami kod, który wygląda plus minus tak PxQueryHitType::Enum(*sceneQueryPreFilter)(PxFilterData, PxFilterData, const void*, PxU32, PxHitFlags&);. Ci co programują w C++ od razu mi wytkną, że to banalne, a ja jestem głupi i nie umiem programować, bo to jest bardzo prosty wskaźnik na funkcję. Może i jestem głupi i nie umiem programować, ale wmieszanie tego w kod powoduje, że ja się muszę kilkanaście sekund zastanowić co to robi. Ale dobra, to był wstęp, teraz coś lepszego. Takie coś const PxU32 raycastResultSize = ((sizeof(PxRaycastQueryResult)*maxNumWheels + 15) & ~15);. Co to robi i dlaczego? Ja wiem, że to są operacje na bitach, że tylda oznacza negację, a ampersand oznacza AND (koniunkcję biów). Mnie bardziej ciekawi dlaczego to musi być tak zrobione? Dokumentacja Nvidii o tym milczy, co ponownie moim zdaniem jest patologią programowania. Jest wiele tego typu przykładów, które można tam takich znaleźć, jak statyczne alokatory do tworzenia obiektów, czy architektonicznie tak mocne połączenie ze sobą obiektów, że nie mogą bez siebie istnieć.

    Myślę, że nie jestem pierwszą osobą, która na to wpadła. Myślę, że nie jest tak, że zacząłem pisać silnik i tylko ja się natknąłem na takie problemy. Dawno temu, już teraz nawet nie pamiętam gdzie czytałem, że wiele firm AAA narzeka na biblioteki od Nvidii. Chodziło o to, że technologia GameWorks jest tragiczna w implementacji, co potem powoduje poważne obniżenie wydajności przy niepoprawnym zaimplementowaniu. Jak wiedzieć z mojego ogromnego wywodu ciężko jest to poprawnie zaimplementować i dlatego prawdopodobnie jest duża fala przepływu ludzi do Bullet Physics oraz Havok. Szczególnie ta druga biblioteka podobno jest genialna i studia AAA w nią idą, ale nie wypowiem się, ponieważ jest płatna, a mnie na takie szaleństwa nie stać.

    Skończę jednak narzekanie, ponieważ dość mocno się nakręciłem jak widać. Koniec końców udało się zaimplementować działanie pojazdu w sposób, który moim zdaniem dość wiernie odwzorowuje nasz realny świat. Efekt powinniście ocenić sami na gifie. Ta animacja przedstawia tylko niewielki wycinek możliwości tego co da się zrobić w silniku CLUSEK od teraz z samochodami. Istnieje ogromna ilość parametrów, które możecie modyfikować w dowolny sposób. Żeby w tym wszystkim się jednak nie zgubić przygotowałem prostą dokumentację w markdown z którą możecie zapoznać się w pliku README.md w rozdziale Vehicles. Jeżeli chcecie to możecie pobrać sobie najnowszą wykonywalną wersję projektu, podmienić model na jakiś własny, następnie ustawić odpowiednią pozycję kół, zawieszenia oraz innych tego typu parametrów i mieć własny pojazd jaki tylko chcecie, które zachowuje się podobnie jak taki pojazd w prawdziwym świecie i to bez różnicy czy to będzie autobus miejski, czy buggy z napędem 4x4 oraz otwartym mechanizmem różnicowym. Ja muszę jeszcze posiedzieć sam nad parametrami, bo zmiana biegów przez automat jest dość nieprzewidywalny. Następują często zmiany w stylu 1->2->1->2->3->3.

    Przy okazji przechodzą przez wiele iteracji TransformComponenta dodałem też coś przydatnego, mianowicie obsługę kwaternionów obok obsługi kątów Eulera. Uważam, że jest to bardzo przydatna funkcjonalność w silniku, ponieważ dzięki temu można się pozbyć problemu, który nazywa się Gimbal Lock. Wikipedia opisuje to całkiem dobrze, ale w skrócie chodzi o to, że jeżeli osie nałożą się na siebie nawzajem to utracimy możliwość obracania naszym obiektem w trzech osiach. Świetnie oddaje to zjawisko ten rysunek. Zresztą problem Gimbal Locka był znany ludziom od dawna, zresztą, o tym problemie było dość głośno w związku z misją Apollo, ale o tym możecie poczytać sami, bo samo to mogłoby być osobnym wpisem na wykop.

    Co poza tym? Raczej małe rzeczy, które są taką drobnicą, że nie ma co o nich mówić. Jedyna wartościowa rzecz to lepsza obsługa loggera, która po zbudowaniu silnika CLUSEK w trybie Release nie powoduje już wysypania się go z powodu próby operowania na nullptr. Mała rzecz, ale poprawia odczucia dla użytkownika końcowego, jeżeli deweloper zostawi taki kawałek kodu. Zresztą, podstawową zasadą loggera powinno być to, żeby w żadnym wypadku nie powodował wysypania się programu. Teraz raczej zostało to już zapewnione.

    I to tyle (。◕‿‿◕。)! Na koniec przypominam jeszcze raz o dawaniu gwiazdek repo CLUSEK na platformie Github oraz bezpośrednio na naszym lokalnym Wykopie o plusy. Jak zawsze zapraszam do przeglądania kodu i kompilowania go samodzielnie, dla tych, którzy by chcieli przetestować bez kompilowania oraz całego środowiska zapraszam do pobrania wersji release w najnowszej dostępnej wersji, która jest dostępna tutaj. Gorąco zapraszam też do komentowania, ponieważ wy się czegoś dowiecie i ja. Staram się w miarę na wszystkie komentarze odpowiadać w taki sposób, żeby nawiązał się jakiś dialog z którego zarówno wy coś wyniesiecie jak i ja.

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

    GIF

    źródło: wykop_pojazd_physx.gif (8.27MB)

    •  

      @bilek993: Powinienem uściślić, że pisałem o wersji 2.x bulleta, obecnie sytuacja może być zupełnie inna, bo silnik jest fajnie rozwijany. Ale nawet dokumentacja w 2.x, mimo że nie idealna, była znacznie lepsza niż np. w ODE :)

      Transform w Unity udostępnia do odczytu macierze LocalToWorld i WorldToLocal i oferuje kilka metod do transformacji. Praktycznie zawsze informacje o położeniu obiektu przekazuje się w formie macierzy. Jest to intuicyjny format i ułatwia wiele spraw, takich jak wspomniana przez Ciebie fizyka, oświetlenie, vfx, czy przenoszenie obiektu do przestrzeni drugiego. Przekazywanie danych w innej formie i tak najczęściej skończy się potrzebą zbudowania macierzy do dalszych obliczeń. pokaż całość

    •  

      @devml: Hmmmm, mocny argument. Mnie przekonałeś z tymi macierzami ;)

      +: devml
    • więcej komentarzy (24)

Ładuję kolejną stronę...

Powiązane z #physx

Archiwum tagów