Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Krzysiek K.

Strony: 1 ... 858 859 860 861 [862] 863 864 865
12916
Projekty rozpoczęte / Odp: Programy ułatwiające życie
« dnia: Styczeń 24, 2006, 15:56:44 »
EvalDraw - "kalkulator" napisany przez Kena Silvermana. Ma wbudowany kompilator języka podobnego do C i kompilowanego "w tle". Potrafi rysować wykresy funkcji jednowymiarowych, dwuwymiarowych i trójwymiarowych (jako woksele) z dodatkową możliwością ich animacji. Ponadto, można pisać w tym proste programy i pewnie robić jeszcze jakieś dziwne rzeczy. :)

Na stronie Kena jest także dostępna biblioteka z tym kompilatorem (podajesz tekst funkcji, dostajesz wskaźnik na funkcję), jeśli by ktoś chciał wbudować to w jakiś swój program. :)

12917
Programowanie grafiki / Odp: Widoczność
« dnia: Styczeń 24, 2006, 11:46:54 »
Cytuj
Wole koncepcje - rob level, reszta sie zajmie soft.
To jest argument. :)

Cytuj
ze starego systemu APZ zostal tylko zooning (laczenie w strefy)
U mnie, jak pisałem, to wygląda podobnie, tyle że cała geometria musi być "postrefowana". :)

Cytuj
Obecna wersja (algorytm) nie musi uzywac occ query (ofkoz uzywa zeby dopalac).
Hmm, brzmi ciekawie. Będę musiał poszukać czegoś o takich algorytmach. :)

12918
Programowanie grafiki / Odp: Widoczność
« dnia: Styczeń 24, 2006, 11:14:11 »
Cytuj
jednak nie mam pojęcia jak można automatycznie wyznaczyć portale, a nie w edytorze robić to ręcznie.
Quake'i wyznaczały po prostu widoczność dla każdego liścia BSP, a potem grupowały razem liście o podobnej widoczności (głównie w celu kompresji danych widoczności). Może podczas wyznaczania widoczności gdzieś w środku się portale przewijały, ale w pliku wynikowym już ich nie było - była po prostu skompresowana macierz które clustery (grupy liści BSP) widać z których clusterów. :)

Co do stawiania portali ręcznie, ja tam nie widzę w tym nic złego. I tak grafik sporo czasu będzie siedział nad robieniem mapy, więc wstawienie prostokątów w drzwiach i oknach nie powinno mu przeszkodzić, o ile jest to wygodnie w edytorze zrobione (w moim przypadku po prostu tworzy się na mapie dodatkowe AABB dla obszarów, a portale wyznaczam automatycznie tam, gdzie się te boxy stykają). Pozatym, takie podejście znacząco uprości projekt (ktoś by musiał algorytm wymyślić i zakodować), najprawdopodobniej przełoży się na nieco wyższą ilość FPS (komputerowi może być ciężko stwierdzić, że drzwi to drzwi i może np. postawić portal na środku pomieszczenia), no i kompilacja portali zajmuje dużo mniej czasu. :)

Cytuj
OCC rules Portale ... nie bardzo (IMO ofkoz wiec prosze sie nie obrazac ;) )
Jedno drugiego nie wyklucza (domyślam się, że chodzi Ci o occlusion culling oparty na occlusion query i jakimś drzewku w stylu oct-tree). Mam zamiar dodać kiedyś opcjonalny occlusion query (kombinuję, żeby to w miarę sensownie chodziło na GeForce 2) do swojej implementacji portali. Prawdopodobnie zastanowię się też nad wykorzystaniem tego do outdoor. Na razie jednak skupiam się na indoor, gdzie, moim zdaniem, portale sprawdzają się dosyć nieźle (zwłaszcza podoba mi się to, jak stencil-test ogranicza fill-rate). :)

12919
Programowanie grafiki / Odp: Widoczność
« dnia: Styczeń 24, 2006, 01:12:08 »
Cytuj
Mógłbyś napisać, jaki jest wzrost wydajności przy stosowaniu tej metody z scissor-testem, tzn jaka jest różnica w fps pomiędzy samym frustrum culling a frustrum culling + scissor test  dla różnych plansz(znaczy o różnej ilości wielokątów oraz o różnym układzie pomieszczeń) ?
Nie robiłem takich testów, ale myślę, że może być spora. Na razie geometria jest dodatkowo dzielona do zadanej gęstości podczas ładowania, gdyż wymaga tego oświetlenie (ale mam zamiar to poprawić). Jednym z pomieszczeń na mapie jest coś w stylu katedry, która składa się z dużej ilości trójkątów renderowanych 5 razy. Bez occlusion cullingu, zawsze, kiedy gracz będzie się patrzył w stronę tej katedry, duża ilość trójkątów była by wrzucana do przetworzenia zupełnie bez sensu.


Moim zdaniem, żadnego silnika przeznaczonego do indoor bez jakiejś formy occlusion cullingu nie można nazwać zaawansowanym, bo jak można tak powiedzieć o silniku, który, gdy gracz patrzy na scianę, renderuje całą mapę za ścianą? :)

12920
Programowanie grafiki / Odp: Widoczność
« dnia: Styczeń 24, 2006, 00:29:15 »
Cytuj
Z drugiej strony jeśli sortujesz wg. z-bufora, to nie sortujesz  wg. tekstury ani deklaracji wierzchołka, co ma ujemny wpływ na wydajność
1. To jest OpenGL, tu nie ma czegoś takiego, jak deklaracja wierzchołka.
2. Nowe karty graficzne są, jak zauważyłem, dosyć odporne na częste zmiany tekstury - i tak większe znaczenie ma ilość osobnych wywołań.
3. O ile się orientuję, to Skalniak u siebie w silniku w pierwszym przebiegu wypełnia tylko Z-bufor, więc sortowanie w późniejszych przebiegach nie da już nic.

Mechanizm wykrywania widoczności jest potrzebny po to, żeby wykluczyć niewidoczną geometrię z kolejnych przebiegów. Metodą, którą stosuję w swoim "silniku" są portale wspomagane scissor-testem.

Screen 1 - widok przez "drzwi" na korytarz
Screen 2 - ten sam widok z zaznaczonymi portalami
Screen 3 - to samo z włączoną przezroczystością

Screen 3 pokazuje działanie systemu w akcji. Dla portalu został wyznaczony prostokąt na ekranie, który go obejmuje, a następnie całe renderowanie obiektów za portalem zostało przycięte do tego niewielkiego fragmentu. Przejście do następnego korytarza nie ma zdefiniowanego własnego portalu, więc następne "drzwi" nie mają takiego przycinania, ale za to cały korytarz renderuje się jako pojedynczy obiekt. Oczywiście podczas zwykłego chodzenia po mapie działanie portali jest dla gracza całkowicie niezauważalne (poza ewentualną zwiększoną ilością FPS). :)

Dodatkowo, portale służą tutaj do wykrywania widoczności. Załóżmy, że gracz stoi w pokoju A i widzi pokój B przez portal 1. Z pokoju B przez portal 2 można zobaczyć pokój C. Stojąc w pokoju A gracz może zobaczyć pokój C tylko przez część wspólną prostokątów portali 1 i 2 (co dodatkowo może ograniczyć prostokąt renderowania dla pokoju C). Może się zdarzyć tak, że prostokąty portali 1 i 2 nie mają części wspólnej, co oznacza, że pokój C jest całkowicie niewidoczny dla gracza i można go nie renderować. Ubocznym skutkiem tego systemu jest to, że mamy od razu zaimplementowany frustrum-culling, więc odpada kodowanie oct-tree, czy czegoś w tym stylu (co prawda mam zaimplementowany podział BSP, ale służy on tylko do szybkiego testowania, których obszarów dotyka dany obiekt). Ten system nadaje się dużo lepiej do zamkniętych przestrzeni, niż do otwartych, ale przy dobrym ułożeniu portali powinien pomóc także w mieście (oczywiście, jeżeli da się wychodzić do budynków, to może pomóc nawet bardzo).

Oczywiście łatwo o tym opowiedzieć, ciężej to napisać. Najwięcej zabawy miałem z wyznaczaniem prostokątów dla portali w szczególnych przypadkach, gdy portal nie jest częściowo poza widokiem kamery (dokładne wyznaczanie prostokąta dla widocznej części wymagało trochę zabawy z płaszczyznami obcinania). Pozatym całą mapę musiałem pociąć na fragmenty odpowiadające obszarom (pokojom) pomiędzy portalami (tu pomógł wcześniej napisany algorytm CSG). Na szczęście wszystko powyższe rekompensuje satysfakcja z naprawdę, moim zdaniem, porządnego systemu widoczności, który dodatkowo drastycznie ogranicza fill-rate (co się przyda, jak będę implementować stencil shadow'y). :)


EDIT:
Cytuj
Nie widziałem nigdzie, jak najlepiej jest to rozwiązać, znaczy jak sortować kolejność renderowania, aby była najwyższa wydajność.
Większa zabawa z kolejnością renderowania nie ma sensu. W oświetleniu per-pixel zwykle każde światło wymaga osobnego przebiegu. Pierwszy przebieg polega wtedy na samym wypełnieniu z-bufora, co jest konieczne do poprawnego sumowania świateł w następnych przebiegach, a przy okazji uniezależnia szybkość od kolejności renderowania (w następnych przebiegach nie zmieniamy już Z-bufora, więc co mogłoby odpaść na Z-teście, na pewno na nim odpadnie). :)

12921
OpenGL / Odp: Transparency na bitmapie
« dnia: Styczeń 23, 2006, 16:30:39 »
Moje rozwiązanie na kanał alpha: trzymać na dysku dwie bitmapy o nazwach "tekstura.bmp" i "tesktura_a.bmp" i połączyć podczas wczytywania. Brak kompresji nie przeszkadza, bo nie powiększy to zbytnio rozmiaru downloadu (i tak wszystko jest pakowane), a zajmie więcej miejsca tylko na dysku, co przy rozmiarach moich projektów nie ma tak wielkiego znaczenia (po wczytaniu i wpakowaniu tekstur od OpenGL/Direct3D zwalniam pamięć, więc tutaj też nic nie tracę). Główną zaletą tego rozwiązania jest to, że mogę te tekstury podejrzeć w IrfanView (czy jakiejkolwiek innej przeglądarce do obrazów), co ułatwia debugowanie. :)

12922
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 22, 2006, 20:20:55 »
Cytuj
Krzysiek K. W jakie dni jesteś na gg? bo jeszcze nigdy nie trafiłem
Codziennie po kilka(naście) godzin (na przykład w tej chwili, ale właśnie wychodzę). Musiałeś mocno kombinować, żeby mnie nie zastać. :)

12923
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 22, 2006, 15:35:46 »
Cytuj
Gdy mam swiatla statyczne to moge w maskach trzymac zanik (diffuse), ale
specular musialbym caly czas liczyc (czyli cube mapa).
Nie musiałbyś, jak to już pisałem powyżej ze dwa razy. Odezwij się do mnie na gg, to będzie mi na pewno łatwiej to wytłumaczyć, niż tu na forum. :)

Cytuj
2 przebiegi wchodza w gre ?
Tak, albo nawet więcej (Doom 3 na przykład wymagał czasem nawet 5 przebiegów do wyrenderowania jednego światła). :)

12924
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 22, 2006, 14:27:09 »
Cytuj
Wlasnie chcialbym to zrobic bez pixel shader na poczatek.
Bez pixel shader albo zabawy z mieszaniem tekstur i kilkoma przebiegami się nie da.

Cytuj
Wydaje mi sie ze mamy roznice w notacji.
czy niejest tak ze ta maska ze wzoru:
  ((L dot N)*diffuse + (H dot N)^exp*specular)*maska
to jest gloss map ?
Gloss map u mnie jest nazwany "specular". Maska to coś w stylu lightmapy dla pojedynczego źródła światła - zapisane są tam cienie i zanik światła z odległością (i nic więcej).

Cytuj
(L dot N)*diffuse w tym podejsciu z mapkami, ale specular tez ma zanik swiatla (punkt2) wiec musze trzymac ten zanik czyli rozklad N dot H per pixel w teksturce.
(N dot H) to nie jest zanik światła. Zanik światła to 1/distance^2 (ew. podobna funkcja zmniejszająca się wraz z odległością).
(N dot H) możesz wyznaczyć per-pixel używając normalmapy dla N i cubemapy dla H.

Cytuj
Wiec jak w takim razie jak nie przy pomocy cube map zrobic zanik na GF 2 Mx ?
Dla świateł statycznych możesz po prostu trzymać zanik razem z cieniami w maskach. Dla świateł dynamicznych można złożyć dwie tekstury następująco:
Przyjmujemy funkcję zaniku: attn = 1-dist^2

attn = 1-dist^2 = 1-sqrt(x^2+y^2+z^2)^2 = 1-x^2-y^2-z^2 = (1-x^2-y^2) - (z^2)
W ten sposób z funkcji f(x,y,z), którą zapisuje się na teksturze 3D zrobiliśmy dwie funkcje f(x,y) i g(z), które można zapisać na teksturach 2D i 1D i złożyć już podczas renderowania.

12925
OpenGL / Odp: Cząsteczki w świecie ;-)
« dnia: Styczeń 22, 2006, 10:55:06 »
Cytuj
Czytając lekcje NeHe, robiłem sobie programik który wykorzystywał co ciekawsze, rzeczy i natrafiłem na particle engine.
Czekam na screena. :)

Cytuj
Aby cząsteczki były dobrze wyświetlane trzeba wyłączyć GL_DEPTH_TEST
Nie trzeba. Trzeba wyłączyć zapis do Z-bufora (glDepthMask(false)), ale sam test Z-bufora powinien być nadal wykonywany. W ten sposób cząsteczki będą zasłaniane przez resztę geometrii, ale nie będą same nic zasłaniać (chyba że zamiast dodawania stosujesz alpha-blending - wtedy wypada cząsteczki posortować pod względem głębokości). Cząsteczki renderujesz oczywiście po reszcie geometrii. :)

12926
Design / Odp: Warsztat game
« dnia: Styczeń 22, 2006, 10:50:51 »
Cytuj
On to zrobil w 16 dni !!! No to ladnie
Nie powinno to być trudne, jeżeli się założy od początku, że się robi coś prostego. :)

12927
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 22, 2006, 01:25:06 »
Cytuj
co mam w tej statycznej teksturce dla speculara ?
Trochę fizyki. Promień światła leci od źródła światła do kamery i przeszkodzić mu mogą następujące rzeczy:
1. Jakiś obiekt po drodze (powstaje cień).
2. To, że oświetlany obiekt jest daleko (zanik światła wraz z odległością).
3. To, że promień słabo odbija się w kierunku kamery (diffuse i specular).

Pierwsze dwa elementy są niezależne od położenia kamery i tego, co właściwie dzieje się ze światłem po dotarciu do oświetlanej powierzchni (diffuse/specular), więc intensywność światła w danym punkcie można zapisać na teksturze.

Cytuj
Dla jakiego punktu zatem licze H dot3 N jesli nie licze tego dla roznych punktow sciany?
Liczysz to dla różnych punktów sciany. Dlatego napisałem, że tą operację robi pixel shader.

Cytuj
Ale obsluguje cube mape.
Cubemapy są mało przydatne, jeżeli chodzi o tworzenie map zaniku (co nie znaczy, że cubemapy są niepotrzebne).

12928
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 21, 2006, 22:46:47 »
Cytuj
nie bardzo rozumiem, skoro mam na mapie cienie to dodatkowo jeszcze musze je liczyc dynamicznie ?
Masz na mapie cienie, ale tylko statyczne. Nadal musisz uwzględnić cień poruszających się obiektów.

Cytuj
no isprawa speculara - tutaj zawsze musze luminacje wyliczac dynamicznie
Przy specularze dynamicznie wyznaczasz tylko odbicie ( N dot H ). Takie rzeczy, jak cienie i zanik światła wraz z odległością możesz nadal trzymać na statycznej teksturze nawet dla speculara. :)

Cytuj
Drugie podejscie juz probowalem zrealizowac ale jedynie dla swiatla dot3diffuse wiec nic dynamicznie faktycznie liczyc nie musialem ale jesli chcialbym uwzglednic specular to juz trzeba dynamicznie wyznaczyc zanik luminacji.
Jak już napisałem, nie trzeba.
- na teksturze masz przeliczony zanik światła i cienie (podobnie jak w lightmapach, tyle że nie uwzględniasz kierunku światła i normalnej oświatlanej powierzchni)
- vertex shader wyznacza wektory L i H
- pixel shader pobiera normalną z normalmapy, normalizuje L i H oraz wyznacza: ((L dot N)*diffuse + (H dot N)^exp*specular)*maska


Do normalizacji można wykorzystać cubemap'y, a resztę operacji da się zrobić w kilku przebiegach nawet bez wykorzystania pixel shaderów.


Cytuj
licze wszystko dynamicznie (glownie chodzi o luminacje) , musze luminacje przechowywac w teksturze,
Błąd. Na teksturze przechowujesz maskę światła, czyli część równania, która się nie zmienia. Zmienianie czegokolwiek na teksturze podczas renderowania jest zwykle bardzo złym pomysłem.

Cytuj
Skoro mapki moga sie zmieniac szczegolnie speculara -za kazdym poruszeniem kamery- to czy warto meczyc sie i grupowac je zeby potem uzyc vertex array/buffer ?
Renderer powinien być napisany tak, żeby nie musiał nic zmieniać na teksturze. Są od tego wyjątki, gdzie renderowanie do tekstury jest częścią zastosowanej metody (np. shadow volume), ale w Twoim przypadku da się to zrobić lepiej bez zmieniania czegokolwiek na teksturach.

Cytuj
No i w koncu mozna jeszcze bardziej sytuacje uogolnic -nie  zalozmy ze jest swiatlo ruchome wiec nie wiadomo do konca na ktora sciane ile pada swiatle i ile takich map luminacji moze byc wiec tym bardziej robi sie skomplikowana sprawa z pakowaniem ich.
Przy światłach ruchomych nie stosuje się zwykle masek/lightmap wogóle. Do wyznaczania zaniku światła stosuje się tekstury 3D (niestety GeForce 2 tego nie obsługuje), albo odpowiednie połączenie tekstury 2D i 1D. Do wyznaczania cieni stosuje się techniki dynamiczne (nawet, jeżeli geometria sama z siebie się nie porusza, to porusza się ona teraz względem światła). Pozatym, jak zwykle, stosuje się normalmapy do wyznaczania rozpraszania się światła odbijanego od powierzchni (diffuse+specular).

Cytuj
- zeby tak dynamicznie zmieniac fragmenty tekstury trzeba duzo obliczen dodatkowych zwiazanych z tym gdzie w wiekszej teksturze znajduje sie konkretna mapka odpowiadajaca jakiemus tam trokatowi
Jak już pisałem, dynamiczne zmienianie fragmentów tekstury wydaje mi się kiepskim pomysłem.

12929
Design / Odp: Fabuła
« dnia: Styczeń 21, 2006, 17:10:33 »
Cytuj
Ciekawy też jestem ile osób w ogóle pisze gę z fabułą, a ile ma podejście, 'najpierw silnik i potem się zobaczy'
Ja mam podejście 'najpierw silnik, a potem... kolejny silnik'. :)

12930
Programowanie grafiki / Odp: Oświetlenie per pixel w teorii
« dnia: Styczeń 21, 2006, 17:09:06 »
Cytuj
Przy oswietleniu statycznym na lightmapkach doradza sie zazwyczaj pakowanie lightmapekw  jedna wieksza teksturke co owocuje potem w mniejszej ilosci wywolan zmiany tekstury.
Nie chodzi głównie o wywołania zmian tekstury, ale o to, że więcej trójkątów korzysta z tego samego zestawu tekstur, więc można je wpakować do jednego vertex buffera i renderować jako całość.

Cytuj
Czy tak warto robic przy oswietleniu per pixel ? Tam dynamicznie oblicza sie luminacje caly czas wiec i dynamicznie trzeba by bylo obliczac polozenie danej teksturki w tej wiekszej - co moze byc na mins co do pakowania mapek luminacji.
Nie wiem, co dokładnie robisz, ale wydaje mi się, że jest to coś dziwnego. :P W oświetleniu per-pixel są dwa główne podejścia:
- liczenie wszystkiego dynamicznie (np. używając tekstury 3D do zaniku oświetlenia, stencil shadow i normalmap)
- przeliczenie maski oświetlenia - podejście dokładnie takie, jak w lightmapach (światło nie może się poruszać względem obiektu), ale w masce są uwzględnione tylko cienie i zanik światła z odległością (nadal używa się tu normalmap i technik do cieni dynamicznych)

W pierwszym przypadku są używane tylko zwykłe tekstury (diffuse, normalmapa, glossmapa, itp.), więc nic nie trzeba dynamicznie obliczać na CPU. W drugim przypadku sytuacja jest podobna do tej przy używaniu lightmap. :)

Strony: 1 ... 858 859 860 861 [862] 863 864 865