Autor Wątek: Widoczność  (Przeczytany 7215 razy)

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 23, 2006, 18:04:13
czesc, zakladajac ze juz quadtree czy octtree czy portale czy cos jeszcze innego okroilo  liste scian ktore nalezy wysietlic, w dodatku sprawdzone sa zwroty sciany i te ktore sa za obserwatorem. Jednak wciaz jest tych scian do wyswietlenia wiecej niz naprawde ich widac. Niektore sa przeslaniane (dosc czesto) przez inne. Znacie jakies algorytmy do eliminacji zaslonietych scian ? Jesli tak to prosilbym o przytoczenie nazw takich algorytmow (o ile takie istnieja jakies juz sprawdzone i popularne :P i dobre:) ). Moze cos oprocz sprawdzania zaslonietych scian ktos zapropnuje ?:)

z gory dziekuje:)
« Ostatnia zmiana: Styczeń 23, 2006, 18:12:28 wysłana przez skalniak »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Sebastian

  • Użytkownik

# Styczeń 23, 2006, 21:06:48
Może już zaimplementowałeś, ale warto przytoczyć: posortuj obiekty przed rysowaniem ze względu na odległość rosnąco i tak je renderuj. Wpływa to korzystnie na wydaność Z-Buffora, szczególnie gdy dość często zdarza się, że obiekty zasłaniają inne.

Offline naleth

  • Użytkownik

# Styczeń 23, 2006, 21:27:54
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ść ;). Nie widziałem nigdzie, jak najlepiej jest to rozwiązać, znaczy jak sortować kolejność renderowania, aby była najwyższa wydajność. Ja mam zamiar renderować kolejne liście drzewa podziału od najbliższego do najdalszego, a w ramach każdego liścia sortować według deklaracji wierzchołka, jednak nigdy nie robiłem testów, jak w praktyce by się to sprawdziło pod względem wydajności, tak na chłopski rozum można by po części upiec dwie pieczenie na jednym ogniu: test Z by często nie przechodził np. w mieście(ogólnie przy jakieś gęstej zabudowie), dzięki czemu odciążyło by się obliczenia per pixel, z drugiej strony deklaracja wierzchołków też nie zmieniała by się tak często.

Jak mówię jednak testów nie robiłem, jak zaliczę wszytko na studiach, to się postaram tym zająć w czasie ferii, ale jak ktoś mający doświadczenie mógłby się wypowiedzieć byłoby miło :).

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# 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). :)
« Ostatnia zmiana: Styczeń 24, 2006, 00:36:09 wysłana przez Krzysiek K. »

Offline naleth

  • Użytkownik

# Styczeń 24, 2006, 00:52:16
Cytuj
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ń.

Faktycznie nie ma czegoś takiego jak deklaracja wierzchołka znana z D3D, jednak sama idea pozostaje: zmienia się sposób, w jaki należy interpretować poszczególne pola w strukturze wierzchołka lub ilość i rodzaj włączonych strumieni.

Co do tekstur to do takiego wniosku też można dość przeglądając listę z szacowanym czasem potrzebnym na wywoływanie poszczególnych metod urządzenia, która to lista jest w dokumentacji d3d. Z tego powodu planowałem sortować według deklaracji(a właściwie wg. OpenGLowskiego odpowiednika, czyli rodzaju włączanych strumieni, bo pod nim piszę) a nie tekstury.

Z drugiej strony wcześniejsze wypełnienie bufora Z faktycznie wydaje się czynnością bardzo prostą i mogącą wiele dać, więc możliwe, że z żadnym sortowaniem nie będę musiał się bawić.

------

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ń) ?

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# 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ą? :)

Offline Demon

  • Użytkownik

# Styczeń 24, 2006, 09:09:33
BSP + portale było w q3, ten system według mnie sprawdza się znakomicie, jednak nie mam pojęcia jak można automatycznie wyznaczyć portale, a nie w edytorze robić to ręcznie.

st3tc

  • Gość
# Styczeń 24, 2006, 09:15:24
BSP + portale było w q3, ten system według mnie sprawdza się znakomicie, jednak nie mam pojęcia jak można automatycznie wyznaczyć portale, a nie w edytorze robić to ręcznie.
Tia ... zwlaszcza liczenie PVS Vis-em ...("czekaj czekaj - zaraz Ci pokaze, jeszcze tylko 9 godzin kompilacji i juz juz bedzie") ;)
OCC rules Portale ... nie bardzo (IMO ofkoz wiec prosze sie nie obrazac ;) )
« Ostatnia zmiana: Styczeń 24, 2006, 09:20:47 wysłana przez st3tc »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# 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). :)

st3tc

  • Gość
# Styczeń 24, 2006, 11:21:28
Wstawianie portali recznie moze i jest dobre. Ale z obserwacji sam widzialem jak userzy byli wrecz zachwyceni, ze silnik zrobi za nich wsztstko :). Wole koncepcje - rob level, reszta sie zajmie soft. Btw - ja juz nie mam ograniczenia outdoor/indoor - zamiast tego istnieje "world" :). Testowalem na najbardziej zakreconych mapkach - i dziala swietnie (na tyle, ze wywalilem portale totalnie - ze starego systemu APZ zostal tylko zooning (laczenie w strefy)). HSR dziala full realtime - odpadaja problemy z rekompilacja danych dla HSR (jak jest np w PVS). Obecna wersja (algorytm) nie musi uzywac occ query (ofkoz uzywa zeby dopalac). OCC ma olbrzymi potencjal i mozna go robic na multum sposobow :).

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# 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. :)

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 24, 2006, 12:09:06
czesc, duzo propozycji az nie wiadomo co wybrac :) (dzieki).Jako ze nie mam edytora zadnego to byl bym za czyms co mozna wyliczyc dla dowolnej mapki. Moglby ktoc cos powiedziec na temat OCC ? (idee) Probowalem cos znalezc i nawet po angielsku ciezko cos wyszukac.. albo jakis tutoraial /link do tutorialu :):)
« Ostatnia zmiana: Styczeń 24, 2006, 12:14:26 wysłana przez skalniak »

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 24, 2006, 12:41:38
cosik znalazlem :)
nawet po polsku ! szkoda ze na warsztat.pac.pl :/
« Ostatnia zmiana: Styczeń 24, 2006, 12:49:59 wysłana przez skalniak »

Offline orzech

  • Użytkownik
    • homepage

# Styczeń 24, 2006, 13:05:08
Nie śmiem się wypowiadać w tym temacie ze względu na dorobek moich przedmówców. :-X Tak czy owak, na mniejszą skalę można użyć rozszerzenia ARB_occlusion_query, skalniak. Służy ono do określenia ile pikseli wpisywanego 'obiektu' będzie widoczne w framebufferze. Wtedy, mając już przeprowadzone wszystkie nadrzędne testy widoczności, w obrębie powiedzmy 'pomieszczenia', można sprawdzić, czy któryś obiekt jest zasłonięty przez inne. Na tym etapie renderuje się uproszczone siatki ograniczające. Teraz, jeśli okaże się, że po wpisaniu do bufora, siatka ograniczająca nie będzie wcale widoczna (0 widocznych pikseli), nie musisz renderować tego obiektu ze szczegółową siatką, włączonymi teksturami i oświetleniem.

Też zawsze to sposób na optymalizację.

Offline biki

  • Użytkownik

# Styczeń 24, 2006, 23:52:13
to jest moj stary projekt dotyczacy OCC
http://sourceforge.net/projects/ooce
moze ci sie na cos przyda.