Programming, graphics, games, media, C++, Windows, Internet and more...
All blog entries, ordered from most recent. Entry count: 1198.
Pages: 
1 ... 96 97 98 99 100 ... 150 
# Czy może być w pełni dynamiczne oświetlenie Indoor?
Fri
03
Aug 2007
Doszedłem ostatnio do wniosku, że implementacja oświetlenia nie jest taka prosta, jak się spodziewałem. Do przestrzeni otwartych (Outdoor) jedno światło kierunkowe wystarczy, ale nie bardzo wyobrażam sobie, jak można oświetlić wraz z cieniami mapę Indoor - w której jest przecież zawsze wiele świateł - dynamicznie i żeby to nadal działało ze znośną predkością. Nawet jeśli nie dynamicznie (wcale mi na tym nie zależy), to jak? Nie interesowałem się dotychczas dokładnie Lightmapami. Kto może pomóc i udzielić jakiejś odpowiedzi, zapraszam do mojego wątku na forum.
# Mam błąd, ale to nie moja wina!
Thu
02
Aug 2007
Błędy nękają wszystkich programujących. Mówi się, że "nie robi błędów tylko ten, kto nic nie kodzi". Pytaniem zadawanym wciąz przez wszystkich programistów jest "dlaczego to nie działa", a w wersji dla programistów gier często także "dlaczego nic nie widać". Błąd można znaleźć szybciej albo po długich poszukiwaniach i każdemu chyba zdarza się od czasu do czasu oskarżać o złe działanie nawet Bogu ducha winny kompilator.
Ale spotkałem w swoim życiu pewną nieliczną, niezwykłą grupę ludzi, którzy kiedy mają błąd, wcale nie starają się go znaleźć - co najwyżej tylko im się wydaje, że go szukają. W zamian cały swój wysiłek i czas wkładają w udowadnianie sobie i wszystkim naokoło, że jednak swój kod napisali dobrze, wszystko zrobili tak jak trzeba itd. Winę za błąd ponosi zwykle kompilator/środowisko/biblioteka albo w ogóle bliżej niezdefiniowana siła wyższa. Za to oni poszukując go wciąż od nowa analizują właśnie ten fragment kodu, w którym błędu na pewno nie ma, jeszcze bardziej utwierdzając się tym samym w swoim przekonaniu o niewinności. Tylko czy to im coś daje?
Jeśli zwykłe nieradzenie sobie z prostymi błędami i przychodzenie z nimi na forum celem pokazania kodu - aby inni go przeanalizowali - nazywa się lamerstwem, to jak nazwać to osobliwe zjawisko? :)
Comments | #teaching #humor Share
# Inna grafika
Mon
30
Jul 2007
Czasami myślę sobie, że programowanie renderowania grafiki innej niż tradycyjne wyświetlanie geometrii mapy Indoor czy siatki terenu Outdoor z animowanymi postaciami i skyboksem nieba - na przykład kosmicznej jak w grze Eve Online czy jakiejś zupełnie odjechanej, jak w filmie Tron, też byłoby ciekawe, a przy tym dużo prostsze. Cóż... na coś trzeba się zdecydować.
Tron
Eve Online
Comments | #graphics #rendering Share
# Szum perlina
Sat
28
Jul 2007
Fajnie mieć pod ręką proste funkcje takie jak:
float PerlinNoise3(float x, float y, float z);
generujące szum wynaleziony przez Kena Perlina. Wygląda na to, że tak naprawdę formalnie szum perlina to ciągła funkcja pseudolosowa jednej lub wielu zmiennych o "częstotliwości" równej np. 1, a to co nazywamy zazwyczaj szumem perlina - ta funkcja używana m.in. do generowania chmur albo mapy wysokości terenu, posiadająca oktawy - nazywa się Fractional Brownian Motion. Mniejsza o nazwy - ja od dzisiaj w swojej bibliotece mam obie :) Mowa oczywiście o bibliotece CommonLib.
Comments | #rendering #math Share
# Renderowanie ducha
Sat
28
Jul 2007
Przeglądając różne teksty nie mogę oprzeć się pokusie czytania o różnych ciekawych rzeczach, które akurat napotkam. Dzięki jednej z nich wiem już, jak renderować duchy :) Pomocny jest tu tzw. Fresnel Term - prosty wzór, którego jednak nie nauczają razem ze wzorami Lamberta, Phonga czy Blinna na oświetlenie Diffuse i Specular. Chodzi o "podświetlanie" powierzchni tym bardziej, im bardziej są zwrócone prostopadle do kamery. Załatwia to oczywiście iloczyn skalarny z wektorem normalnym. Ten wzór nadaje się jako dodatek do normalnego oświetlenia, ale można go też wykorzystać tak jak tutaj - wyłączyć Backface Culling i zapis do Z-bufora, ustawić addytywny alfa-blending i oto jest skodzony na szybko duch słonia:
# Valve Steam - Survey Results
Fri
27
Jul 2007
SURVEY RESULTS - bardzo ciekawe znalezisko. Prezentuje wyszpiegowane przez mechanizm Steam (aktualne!) dane statystyczne dotyczące sprzętu posiadanego przez korzystających z niego graczy. To dane dotyczące całego świata i niekoniecznie adekwantne do warunków polskich, ale warto zobaczyć ile statystyczny Kowalski czy raczej Smith ma pamięci RAM, jaką ma kartę graficzną, jaki duży dysk i ile wolnego miejsca na nim, jaki procesor, jaką wersję sterowników graficznych, jaki system operacyjny i dużo innych rzeczy.
Comments | #web #hardware Share
# Architektura całej gry
Fri
27
Jul 2007
Architektura całej gry, choć nie o nią mi w obecnej chwili chodzi, przewija się w literaturze którą obecnie analizują i też mnie interesuje. Szczególnie, że ilekroć staję przed tym zadaniem, zawsze mój kod zamienia się w jedną wielką kulę błota, w której wszystko korzysta ze wszystkiego beztrosko rzutując klasy w dół hierarchii dziedziczenia. Ciekawy wątek forum na ten temat jest TUTAJ.
Wyczytałem właśnie, że architekturę gry można podzielić na:
Wprowadzanie takich podziałów wydaje się trochę na siłę, szczególnie że można tu wymyślić jeszcze dużo innych opcji. Gdzieś kiedyś na forum pisali nawet o takiej, w której każdy obiekt gry posiadać ma swoje pod-obiekty odpowiedzialne za grafikę, dźwięk, fizykę itd. Tylko czy coraz większe komplikowanie rozwiązuje ten i tak skomplikowany problem? :)
# Kwestia shaderów
Fri
27
Jul 2007
W kwestii shaderów używanych do rysowania wszelkich obiektów (na czele ze zwykłymi, nieprzezroczystymi powierzchniami o określonych parametrach materiału) można wymyślić trzy rozwiązania różniące się trudnością:
1. Sposób najprostszy to stały, napisany wcześniej zestaw shaderów. Każdy z nich byłby uniwersalny w jakimś zakresie. Dostępny w nowych kartach Static Branching i Dynamic Branching pozwalają włączać i wyłączać poszczególne fragmenty, aczkolwiek mnie i tak szkoda byłoby marnować instrukcje na sprawdzanie warunku zamiast wygenerować osobny shader bez danego fragmentu.
2. Metoda subtraktywna: Można napisać jeden albo kilka wielkich shaderów posiadających wszystkie potrzebne możliwości, w których źródle znajdą się warunki typu if (MAKRO == 1) albo też #if (MAKRO == 1). Taki kod będzie kompilowany na żądanie z odpowiednimi makrami preprocesora jako konkretny shader. Tak mam zrobione obecnie.
3. Metoda addytywna, najtrudniejsza: Przed kompilacją składać kod shadera z fragmentów w postaci definiowanych jakoś w tekstowy albo graficzny sposób bloczków, których wyjścia jednych łączy się z wejściami innych.
Nie wiem, który sposób będzie najlepszy.