Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "rendering", ordered from most recent. Entry count: 187.
Pages: 
1 ... 11 12 13 14 15 ... 24 
# D3DPTEXTURECAPS_NONPOW2CONDITIONAL
Tue
13
May 2008
Jak wiadomo, tekstury nie muszą być kwadratowe, ale generalnie powinny mieć boki będące potęgami dwójki - tj. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 itd. Ograniczenie to znoszą jedynie układy firmy nVidia z SM3 (od GF6), ale karty ATI z SM3 nadal je mają. Odpowiada za to flaga D3DPTEXTURECAPS_POW2 pola TextureCaps struktury D3DCAPS9.
Jest jednak taka sytuacja, kiedy to ograniczenie jest bardzo uciążliwe. Chodzi o użycie tekstury jako Render Target. Wówczas, jeśli powinna mieć co najmniej rozmiar ekranu, przykładowo dla rozdzielczości 1280 x 1024 musiałaby mieć rozmiar 2048 x 1024 i dużo miejsca by się marnowało.
Dlatego jakby specjalnie w tym celu, praktycznie wszystkie układy graficzne posiadają flagę D3DPTEXTURECAPS_NONPOW2CONDITIONAL, która pozwala na używanie tekstur o dowolnych rozmiarach pod pewnymi warunkami (opisanymi w DX SDK pod hasłem "D3DCAPS9"):
Comments | #directx #rendering Share
# Deferred Shading - pakowanie pozycji i normalnej
Sun
04
May 2008
Piszemy Deferred Shading... Pierwsze co przychodzi do głowy, to zapisywanie do G-buforów pozycji i wektora normalnego w przestrzeni kamery jako pełne (x,y,z). Żeby oszczędzić komponentów, można je spakować. Zakładając, że wszystkie widoczne ścianki są zwrócone przodem do kamery, jako wektor normalny wystarczy zapisać tylko (x,y), a trzecią składową odzyskać ze wzoru:
Normal.z = - sqrt(1 - Normal.x*Normal.x - Normal.y*Normal.y);
Długo szukałem działającego wzoru na kodowanie pozycji jako pojedyncza odległość/głębokość, więc tym chętniej się nim podzielę. Są tutaj różne szkoły. Można zapisywać głębokość z/w, można odległość od kamery, można też odległość od bliskiej płaszczyzny przycinania. U mnie sprawdziło się takie rozwiązanie:
// Kodowanie - VS: Out.ViewPos = mul(float4(In.Pos, 1), (float4x3)WorldView); // Kodowanie - PS: G1.b = length(In.ViewPos); // Dekodowanie - VS: Out.EyeVec = float3(In.Pos.x * AspectRatio, In.Pos.y, TanFovY); // Dekodowanie - PS: Pos = normalize(In.EyeVec) * G1.b;
Gdzie podczas dekodowania: Pos.xy to pozycja wierzchołków fullscreen quada w przestrzeni rzutowania -1..1, TanFovY to tangens kąta widzenia pionowego w radianach używanego w macierzy rzutowania tan(FovY), AspectRatio to stosunek szerokości do wysokości widoku.
Trzeba jeszcze pamiętać, że jeśli tekstura G-bufora nie jest w formacie zmiennoprzecinkowym (jak u mnie A16B16G16R16F), to zapisywane wartości trzeba jakoś skalować do przedziału 0..1.
Comments | #algorithms #rendering Share
# Zrobiłem Deferred Shading
Sat
03
May 2008
Zrobiłem Deferred Shading. To fajna technika, bo miło jest dodawać oświetlenie sceny kolejnym światłem tylko przez narysowanie następnego fullscreen quada (albo mniejszego obszaru ograniczonego przez Scissor Test, jeśli udałoby się zaimplementować algorytm Lengyela). Używam dwóch render-targetów (nazywanych tu G-buforami) w formacie A16B16G16R16F, wypełnianych na raz dzięki MRT, zbudowanych tak:
Wszystkie obliczenia odbywają się w przestrzeni kamery (View). Ciekawym pomysłem jest zakodowanie właściwości materiałów w specjalnej teksturze, której pionową współrzędną adresuje numer materiału zapisany w G-buforze. U mnie to jest tekstura w formacie A32B32G32R32F o szerokości 1px, w której: RGB = SpecularColor, A = SpecularPower.
Z czego warto się uczyć Deferred Shading? Referat Riddlemastera z IGK 2008 może zainteresować tematem, ale zawiera niewiele konkretów. Deferred Shading Tutorial autorstwa Fabio Policarpo i Francisco Fonseca jest bardzo dobry, ale zniknął z Sieci. Na szczęście jest jego kopia w Internet Archive. Jest też długa dyskusja na forum GameDev.net. Z materiałów papierowych polecam Game Programming Gems tom 6 rozdz. 5.7 o enigmatycznym tytule "Fast Per-Pixel Lighting with Many Lights" (Frank Puig Placeres), a także GPU Gems 2 rozdz. 9 - "Deferred Shading in STALKER" (Oles Shishkovtsov).
# Policzone tangenty do mapy
Thu
01
May 2008
Wieści z pierwszej linii frontu: Chyba udało mi się policzyć normalne i tangenty dla mapy Indoor, z wygładzeniem zależnie od kąta krawędzi. Wzory na tangenty wziąłem z tego artykułu. Ciekawy patent wymyśliłem, żeby w poszukiwaniu wierzchołków leżacych w pobliżu nie działać ze złożnością kwadratową. Otóż posortowałem wierzchołki w każdej grupie (rysowane danym materiałem) wg współrzędnej X. Potem dla każdego wierzchołka przeglądam tylko kilka następnych, tak długo jak (v2.x - v1.x) < EPSILON_DIST. Czyż to nie dużo prostsze, niż jakieś Octree czy k-d tree? :D
Comments | #rendering #math Share
# Cząsteczki stanowe i bezstanowe
Fri
14
Mar 2008
Wrócę jeszcze do tematu efektów cząsteczkowych, żeby opisać coś, co dla wielu jest oczywiste, ale dla każdego przecież kiedyś nie było. Mnie do końca rozjaśnił tą sprawę referat mINA87 z ubiegłorocznej IGK pt. "Zaawansowane i efektywne systemy cząsteczkowe w grach komputerowych". Otóż efekty cząsteczkowe mogą być stanowe lub bezstanowe.
Efekty cząsteczkowe bezstanowe to takie, w których wszystkie parametry cząstki (pozycja, rozmiar, kolor, przezroczystość, orientacja) mogą być w dowolnej chwili wyliczone wg określonego, stałego wzoru w funkcji czasu (np. wg funkcji liniowej, kwadratowej, jakiejś z sinusem czy interpolacji między podanymi punktami). Ich zaletą jest łatwość zarządzania i przeliczania, także całkowicie za pomocą Vertex Shadera na GPU.
Efekty cząsteczkowe stanowe to takie, w których zapamiętane są bieżace parametry każdej cząsteczki. Są one aktualizowane wg pewnych zależności na podstawie parametrów poprzednich i delty czasu. Każda cząsteczka ma też czas życia, a nowe są tworzone przez tzw. emiter. To podejście pozwala sterować cząsteczkami w sposób interaktywny, np. zostawiać dym za latającą w dowolny sposób rakietą albo liczyć kolizje iskier odbijających się od ścian i podłogi.
Efekt cząsteczkowy napisałem już bardzo dużo razy - ostatnio wczoraj :) Może kiedyś opiszę w jakimś małym artykule, jak dokładnie to robię.
# D3DFVFCAPS_PSIZE
Wed
12
Mar 2008
Wiem, że mechanizm Point Sprites jest przestarzały i ma wielu przeciwników, ale czasem jest dobrym rozwiązaniem. Ta notka będzie dla tych, którzy go stosują. Mogą się oni nieprzyjemnie zdziwić (tak jak ja ostatnio), że na niektórych kartach graficznych cząsteczki mają złą wielkość (np. są ogromne zamiast takich jakie mają być albo nie widać ich w ogóle).
Winny jest D3DFVFCAPS_PSIZE. Ten Caps mówi, czy rozmiar cząsteczki może być brany ze struktury wierzchołka o semantyce D3DFVF_PSIZE. Co ciekawe, legitymują się nim wszystkie, nawet stare karty firmy ATI, ale z kart firmy NVIDIA tylko te należące do generacji GeForce 6 i nowszych.
Co wobec tego zrobić? Kiedy rozmiar punktu nie może być brany z wierzchołka, jest odczytywany z ustawienia D3DRS_POINTSIZE. Na szczęście nawet wtedy wierzchołek może zawierać element D3DFVF_PSIZE, tylko on po prostu nie działa. Tak więc prawidłowym rozwiązaniem jest używać D3DFVF_PSIZE jeśli jest taka potrzeba, ale na wszelki wypadek wyliczyć też jakiś średni rozmiar cząsteczki i wpisać go do D3DRS_POINTSIZE.
Comments | #rendering #directx Share
# Shadow Mapping i jego odmiany
Sun
09
Mar 2008
Shadow Mapping, jako technika renderowania cieni najlepsza i najpopularniejsza (albo jedna z dwóch takich, obok Shadow Volume), a równocześnie trudna i stwarzająca wiele problemów, doczekała się licznych ulepszeń. Jednym z nich jest próba zapisywania zamiast głębokości czegoś bardziej zaawansowanego - np. VSM (Variance Shadow Maps), CSM (Convolution Shadow Maps), ESM (Exponential Shadow Maps).
Dla mnie, jako miłośnika przestrzeni otwartych, szczególnie ciekawe są techniki reparametryzacji pozwalające rzucać cień kierunkowy na duże obszary. Tutaj pierwszy był PSM (Perspective Shadow Maps), potem LiSPSM (Light Space Perspective Shadow Maps), TSM (Trapezoidal Shadow Mapping), a ostatnio trafiłem na wynaleziony zaledwie w ubiegłym roku przez Vladislava Guseva XPSM (Extended Perspective Shadow Maps).
# Optymalizacja rulez
Fri
15
Feb 2008
Optymalizację można różnie rozumieć. Może znaczyć nietworzenie wielu obiektów tymczasowych, nieużywanie wielu alokacji pamięci i inne takie podstawowe rzeczy (o których każdy wiedzieć powinien). Może znaczyć używanie takich algorytmów i struktur danych, które zapewnią najlepszą złożoność obliczeniową (to już wymaga więcej myślenia, ale jest bardzo ważne). Może oznaczać przepisanie newralgicznych pętli do asemblera (jeśli ktoś zna ten język). Abstrahując od tego wszystkiego, do celów programowania gier można ułożyć takie zasady optymalizacji:
Poza tym często trzeba znaleźć kompromis typu czas-pamięć. W programowaniu gier jest to o tyle proste, że czasu zawsze jest za mało, a pamięci niekoniecznie - gra ma prawo zająć kilkadziesiąt czy nawet kilkaset MB.
Korzystając z tych zasad zwiększyłem właśnie dwukrotnie liczbę FPS-ów w swoim kodzie :D W stwierdzeniu który fragment wymaga optymalizacji pomógł mi profiler - AMD CodeAnalyst.