Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "rendering", ordered from most recent. Entry count: 187.
Pages: 
1 ... 16 17 18 19 20 ... 24 
# Efekty cząsteczkowe
Fri
07
Sep 2007
Wczoraj porządnie przemyślałem, a po wymyśleniu kilku sprytnych rozwiązań całkiem szybko napisałem ostatni z rodzajów specjalnych encji - efekt cząsteczkowy. Efekt opisuje zestaw 108 liczb, które trzeba ręcznie wypełnić (na szczęście większość z nich to zwykle zera). Liczony jest w pełni na GPU. Bufor wierzchołków wypełniam tylko raz. Wierzchołek zajmuje 24 bajty. Jako stałe do shadera przekazuję tablicę 25 wektorów, z których co klatkę zmienia się tylko jedna liczba - czas. Potem do dzieła wkracza liczący 70 instrukcji Vertex Shader (na którym przy próbie wygenerowania kodu asemblerowego do pliku wysypuje się kompilator HLSL :) i oto efekt, a właściwie pięć przykładowych efektów:
Tym samym za zakończoną uważam część mojego silnika odpowiedzialną za wnętrza (Indoor). Strzelankę mógłbym już pisać :) Nie chcę jednak na tym poprzestać. Na razie zajmę się trochę skryptami strony www.gamedev.pl, a potem zabieram się za przestrzenie otwarte (Outdoor), czyli teren, niebo, drzewa, trawę itp.
Comments | #gallery #productions #rendering #engine Share
# Encje specjalne
Wed
05
Sep 2007
Ciąg dalszy prac nad silnikiem: Napisałem kilka rodzajów encji specjalnych, czyli innych niż model wczytywany z pliku.
Pierwszy z nich to Quad, czyli oteksturowany prostokąt. Pośród ustawień ma liczbę stopni swobody - 0, 1, 2. Te dwa ostatnie tryby czynią z niego Billboard, czyli obiekt zwrócony zawsze w pewnym sensie przodem do kamery.
Drugi to obiekt tekstowy. Ten również ma liczbę stopni swobody, a ponadto alignację, automatyczne dzielenie na wiersze, podkreślenia i wszystko to, co mój zwyczajny tekst 2D. Do tego oczywiście kolor i półprzezroczystość.
Trzeci to pasek - wąski, podłużny, pokryty teksturą (opcjonalnie animowaną) i rysowany tak, żeby rozciągając się wzdłuż ścieżki wyznaczonej przez ciąg punktów wyglądał możliwie dobrze z punktu widzenia kamery. Klasy pochodne implementują różne widoczne poniżej kształty: łamana, elipsa, funkcja parametryczna oraz krzywa (dostępne są krzywe kwadratowe, Beziera i B-spline).
Zostały jeszcze efekty cząsteczkowe i cała część Indoor będzie gotowa :D
Comments | #rendering #productions #engine #gallery Share
# The Final Quest 7 - Co napisałem
Mon
03
Sep 2007
Zapomniałem informować o postępach w pracy, a ta idzie całkiem nieźle. 5.5 tygodnia temu z powodu "zamotania się" kodu postanowiłem napisać TFQ od nowa. Na szczęście nie wszystko - jedynie najwyższą warstwę, sam silnik.
W telegraficznym skrócie: Napisałem od nowa światła, cienie (Shadow Mapping) i materiały. Z nowych rzeczy, pojawił się podział przestrzeni (swobodne drzewo ósemkowe - Octree), pełne cienie dla świateł punktowych (na teksturze sześciennej - Cube) czy materiały półprzezroczyste (wprawdzie nie podlegają oświetleniu, ale grunt że są). Odkomentowałem też postprocessing (efekty dokładnie te same co wcześniej), a także zintegrowałem z tym wszystkim animację szkieletową. Udało się ukończyć serce silnika (czyli to miejsce, gdzie spotykają się i łączą dane od silnika, obiektu, materiału, światła, kamery i inne) zanim kod zbytnio się zamotał. Mam też własny format modeli (QMSH) i map (QMAP). Mój eksporter w Blenderze zapisuje siatkę do tekstowego formatu pośredniego, a specjalne konsolowe narzędzie (Tools) przetwarza ją do formatu docelowego, wyliczając przy tym normalne i tangenty (w tym pomaga mi NvMeshMender).
(Prawa autorskie do modelu kury posiada Krzysiek K. :)
Comments | #rendering #gallery #engine #productions Share
# Równomierne losowanie punktów z okręgu
Sun
26
Aug 2007
Jak losować punkty należące do okręgu, rozłożone równomiernie? W programowaniu mamy najczęściej dostępny generator liczb o rozkładzie równomiernym. Losowanie punktów z kwadratu jest z jego użyciem napisać prosto. Jak losować punkty z okregu?
Pierwszy pomysł polega na normalnym losowaniu punktów we współrzędnych kartezjańskich z kwadratu opisanego na tym okręgu i odrzucaniu tych, które leżą poza okręgiem. To niefajny pomysł - za dużo niepotrzebnego liczenia.
Drugi pomysł polega na losowaniu punktów we współrzędnych biegunowych - odległości od środka i kąta. To lepsze, ale pojawia się tu jeden kruczek. Losowane w ten sposób punkty mają tendencję do skupiania się w środku, bo dla małych wartości promienia punkty leżą blisko siebie niezależnie, jaki wylosował się kąt - tym bliżej, im mniejszy promień. Jak temu zaradzić?
Prawdopodobieństwo wylosowania danego promienia powinno być nie równomierne, ale propocjonalne do pola koła, które on wyznacza. Ponieważ pole jest zależne od promienia kwadratowo, wystarczy wylosowany promień (w zakresie 0..1, jeszcze przed przeskalowaniem) SPIERWIASTKOWAĆ.
Dla punktów 3D należących do kuli powinno być analogicznie.
Comments | #math #algorithms #rendering Share
# Processing
Thu
23
Aug 2007
Processing 1.0 (BETA) - pod tą dziwną nazwą kryje się ciekawa zabawka - prosty język programowania oraz proste IDE, w którym można eksperymentować z grafiką 2D i 3D pisząc efekty, animacje i proste gry. Jest napisane jest w Javie i do Javy kompiluje napisany kod. Sam język też jest podobny do Javy. Pozwala na eksport swojego dzieła do apletu lub aplikacji Java. W porównaniu z Evaldraw wypada moim zdaniem na plus, bo choć wydajność jest dużo gorsza, to całe środowisko jest wygodniejsze w obsłudze, prostsze w użyciu, lepiej dopracowane i lepiej udokumentowane. Oto co udało mi się stworzyć:
Comments | #tools #rendering #java Share
# Shadery a sprawa preprocesora
Sun
19
Aug 2007
Fakt nr 1 - shadery warto pisać w HLSL albo innym tego typu języku. Kompilatory generują dobry kod, więc nie ma sensu babrać się w czystym asemblerze. Fakt nr 2 - shaderów potrzeba wiele. Najlepiej, żeby można było generować nowe shadery z różnych kombinacji jakiś swoich ustawień. Niektórzy radzą sobie bez tego, ale ja nie wyobrażam sobie jak. Shadery zastępują przecież niektóre ustawienia renderowania z dawnego nieprogramowalnego potoku i tak też na nie patrzę - jak na własny potok sterowany ustawieniami. Mają przy tym tą zaskakującą na początku nauki cechę, że nie można ich łączyć - na raz może być ustawiony jeden shader, który musi zawierać wszystko, co jest do zrobienia na wierzchołku albo pikselu.
Rozwiązaniem jest dołączenie do gry źródła shadera (np. pliku FX) i jego kompilacja w czasie ładowania albo w czasie samej gry, w razie potrzeby, z odpowiednimi ustawieniami. Jak odwzorować to w kodzie shadera? Opcje są dwie, a nawet trzy.
Ta, która dla mnie odpada natychmiast to skorzystanie z instrukcji warunkowych Static Branching. Po co marnować cenny czas na instrukcje sprawdzania warunku, który zawsze będzie niespełniony, jeśli można wygenerować osobny shader, który danego kodu po prostu nie zawiera?
Opcja pierwsza to wstawienie do kodu dyrektyw warunkowych preprocesora typu #ifdef (OPCJA == 1), gdzie OPCJA będzie makrem przekazywanym jako parametr podczas kompilacji shadera.
Opcja druga to wstawienie do kodu warunków typu if (OPCJA == 1), gdzie OPCJA również będzie makrem. Obydwa rozwiązania wygenerują równie dobry kod. To drugie wydaje się przy tym bardzie eleganckie.
Niestety ma jedną wadę. O ile fragmenty kodu można objąć w if (OPCJA == 1), o tyle czegoś takiego nie można napisać dla pól struktury definiującej dane przekazywane z VS do PS. Tam natomiast muszą występować różne pola, niektóre nieużywane, zależnie od parametrów kompilacji danego shadera. Każde takie pole natomiast, nawet jeśli nieużywane, musi być wypełniane przez VS, choćby samymi zerami (swoją drogą - cóż za bzdura! - to powinno generować ostrzeżenie a nie błąd kompilacji), a to kosztuje dodatkową, niepotrzebną instrukcję w VS.
Toteż pozostaje objąć te nie zawsze wykorzystywane pola struktury w dyrektywy #ifdef. Skoro przy niektórych wartościach makr w ogóle ich nie będzie, to nie można też ich wtedy używać w kodzie. Tak więc warunki w kodzie też trzeba wtedy objąć w #ifdef zamiast w if. Co Należało Dowieść :) Tak też mam zrobione u siebie.
Comments | #rendering #directx Share
# Kultowe książki
Wed
15
Aug 2007
Książki można podzielić na grube i cienkie tudzież dobre i kiepskie. Pośród książek z interesującej nas dziedziny dodatkowo można wyróżnić takie kategorie jak książki na jeden konkretny temat (np. matematyka, fizyka) oraz takie, których autor próbuje kompleksowo i od podstaw nauczyć programowania gier (niektórym nawet się to udaje dzięki dostatecznie dużej objętości książki).
Jest jeszcze kategoria książek - tym ze słowem "Gems" w tytule, które stanowią tak naprawdę zbiór krótkich i niezależnych, ale bardzo wartościowych i na wysokim poziomie artykułów na dany temat. Większość z nich jest wprawdzie niedostępna w Polsce, ich kupowanie za granicą jest drogie, a ściąganie z eMule nielegalne, ale wypada przynajmniej znać kultowe serie takie jak:
Comments | #literature #rendering Share
# Obrysowanie modelu
Sun
12
Aug 2007
Drobiazg przydatny do zaznaczania - efekt obrysowania modelu. Do wykonania potrzebny jest model oraz dodatkowy przebieg renderowania przed tym właściwym. W dodatkowym przebiegu kolejno:
To drugie przesunięcie najlepiej chyba wpleść pomiędzy przekształcenie widoku a projekcji.
Ten efekt jest pewnie gdzieś opisany i jakoś mądrze się nazywa, ale ja wymyśliłem go wczoraj i napisałem w RenderMonkey tylko tak na szybko, przy okazji.
