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

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 25, 2006, 00:02:35
Ja tam się nie znam, ale z tego co czytałem to podobno occlusion culling warto liczyć tylko dla nielicznych wybranych obiektów, które mają duże szanse porządnie coś zasłaniać (np. dla tych dużych), a nie dla wszystkich jedne z drugimi.

Poza tym nieśmiało ponawiam prośbę skalniaka o podanie jakiejś listy technik, które mogą służyć do tego celu i ewentualnych linków. Jasne, że można sobie wygoolać, ale chciałbym wiedzieć, czy istnieje może w tym tamcie jakaś klasyka, pozycja obowiązkowa i najważniejsza.

Offline Mr. Spam

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

Offline Steel_Eagle

  • Użytkownik

# Styczeń 30, 2006, 01:34:20
Ja takze znalazlem w sieci wiele opini mowiacych, ze na obecnym sprzecie nie oplaca sie robic dokladnych testow widocznosci. Zwiazane jest to z tym ze obecne karty graficzna sa w stanie przetwarzac duze ilosci wierzcholkow i czesto koszty obliczen/struktu danych zwiazanych z widocznoscia sa wieksze niz wyrenderowania tych nieszczesnych niewidocznych wierzcholkow...  oczywiscie nie chodzi tutaj o calkowite zakazanie testow widocznosci, co byloby niemadre, a jedynie uzywanie szybkich metod dajacych jedynie przyblizone wyniki.

Takze panuje poglad ze drzewa BSP to juz przezytek i nie powinno sie ich stosowac.  Znowu inne zrodla wychwalaja BSP pod niebiosa... Czuje sie tym wszystkim troche skolowany i prosilbym o pomoc w usttaleniu jednego pogladu :) Ponoc ABT - Adaptive Binary Trees sa znacznie lepsze, ale nie moge znalezc nic o nich konkretnego, wiec bylbym bardzo wdziczny jezeli ktos by mi je wytlumaczyl  :)

[Edit]
Przepraszam jezeli pomylilem pojecie OCC z HSR, ale Regedit czy pytasz o techniki zapisywania geometrii tekie jak OCT, BSP, ABT, ktorych zadaniem jest ograniczenie zbioru widocznych obiektow?

Dodatkowo w OpenGL istnieje cos takiego jak rozszerzenie GL_ARB_occlusion_query, o ktorym niedlugo napisze cos wiecej :)
« Ostatnia zmiana: Styczeń 30, 2006, 01:47:40 wysłana przez Steel_Eagle »

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 30, 2006, 17:08:30
Zaraz zaraz, jak to jest? Z tego co mi wiadomo, drzewa BSP, Octree i inne metody podziału przestrzeni służą raczej do eliminowania geometrii niewidocznej ze względu na to, że jest z tyłu za kamerą, poza stożkiem widzenia kamery itp., a nie do eliminowania elementów zasłoniętych przez inne elementy. Chyba, że czegoś nie wiem?

Offline Majtek

  • Użytkownik

# Styczeń 30, 2006, 17:35:40
Masz rację a do usuwania zasłoniętych elementów jest  occlusion query

Offline Steel_Eagle

  • Użytkownik

# Styczeń 30, 2006, 19:20:20
yhy pomylilem sie
Czy znacie jeszcze jakies inne techniki Occlusion Cullingu? Czy occlusion query jest w zupelnosci wystarczajace?



[OFFTOPIC]
St3tc nie rozumiem Cie... spojrz na godzine pisania mojego posta bylem juz zmeczony. Nie wiem co chciales udowodnic...  Troche wiecej wyrozumialosci i zamiast pisac puste posty skup sie na temacie, bo dalej czekamy na odpwowiedz na postawione pytania...
[/OFFTOPIC]
« Ostatnia zmiana: Styczeń 30, 2006, 19:26:00 wysłana przez Steel_Eagle »

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 30, 2006, 20:00:57
st3tc: ale mozna zrobic occlusion culling bez tego rozszerzenia ARB_occlusion_query ? WIdze ze tutaj sa jeszcze rozne metody tego OCC :/
Ten silnik open source ktory sostal podany jako przyklad w tym temacie u mnie dziala na GF2 i rezultat jest naprawde zadziwiajacy z frustrum do OCC jest skok ok 40 fps :)

Offline biki

  • Użytkownik

# Styczeń 31, 2006, 11:11:41
akurat occlusion query nie jest na razie najlepszym rozwiazaniem, jest powolne.
w praktyce lepiej uzywac rozwiazan programowych (portale/antyportale/occ)
dobrym zrodlem informacji jest dokumentacja DPVSa na stronie hybrid.fi

Offline rtn

  • Użytkownik

# Styczeń 31, 2006, 18:33:07
Zaraz zaraz, jak to jest? Z tego co mi wiadomo, drzewa BSP, Octree i inne metody podziału przestrzeni służą raczej do eliminowania geometrii niewidocznej ze względu na to, że jest z tyłu za kamerą, poza stożkiem widzenia kamery itp., a nie do eliminowania elementów zasłoniętych przez inne elementy. Chyba, że czegoś nie wiem?
algorytm OCC jest (prawie) identyczny jak dla ósemkowych czy bsp. Usuwa te elementy co sa w jakims np. ostroslupie za bryłą przesłaniającą. Wlaśnie poto stosuje się algorytmy na drzewach zeby nie robic testu zasłonięcia dla wszystkich obiektów tylko możliwie ograniczyć ich ilość.

Offline Majtek

  • Użytkownik

# Luty 01, 2006, 17:43:23
to jest mój stary projekt dotyczacy OCC
http://sourceforge.net/projects/ooce
moze ci sie na cos przyda.

Kompilował może ktoś ten projekt pod VC2005 + PSDK
bo mi się nie chce kompilować wywala w pliku omap.cpp
ma coś do wstawek asm a ja ich nie umię
 dokładnie to do
asm ("movl %%eax,%%edx\n\
shll $16,%%eax\n\ sarl $16,%%edx\n\ idivl %%ebx"
:"=a"(dxi):"0"(vs[j][0]-vs[i][0]),"b"(vs[j][1]-vs[i][1]):"%edx");
błąd
Cytuj
..\ooce\occmap\omap.cpp(224) : warning C4129: ' ' : unrecognized character escape sequence
..\ooce\occmap\omap.cpp(224) : warning C4129: ' ' : unrecognized character escape sequence
..\ooce\occmap\omap.cpp(224) : warning C4129: ' ' : unrecognized character escape sequence
..\ooce\occmap\omap.cpp(224) : error C2143: syntax error : missing ')' before ':'
..\ooce\occmap\omap.cpp(224) : error C2290: C++ 'asm' syntax ignored. Use __asm.
..\ooce\occmap\omap.cpp(224) : error C2059: syntax error : ')'

zrobiłem tak
__asm ("movl %%eax,%%edx\n\
        shll $16,%%eax\n\
        sarl $16,%%edx\n\
        idivl %%ebx"
  :"=a"(dxi):"0"(vs[j][0]-vs[i][0]),"b"(vs[j][1]-vs[i][1]):"%edx");
ale dostałem
Cytuj
..\ooce\occmap\omap.cpp(223) : error C2400: inline assembler syntax error in 'opcode'; found '('
..\ooce\occmap\omap.cpp(227) : error C2143: syntax error : missing ';' before ':'
..\ooce\occmap\omap.cpp(227) : error C2059: syntax error : ')'

a pod C::B i gcc kompiluje bez problemu
« Ostatnia zmiana: Luty 01, 2006, 17:45:44 wysłana przez Majtek »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Luty 01, 2006, 18:20:27
Cytuj
ma coś do wstawek asm a ja ich nie umię
Cytuj
a pod C::B i gcc kompiluje bez problemu
VC++ też nie zna się na wstawkach przeznaczonych pod gcc. :)

Offline Majtek

  • Użytkownik

# Luty 01, 2006, 23:45:34
a może ktoś przetumaczyć na kod zrozumiały dla VC
bo mi to nie idzie mam tak
__asm{ mov eax,edx
        shl $16,eax
        sar $16,edx
        idiv ebx
mov dxi, eax
        mov regs[0], eax
mov regs[1], esi
mov regs[2], ecx
mov regs[3], edx
}
ale niedziała
« Ostatnia zmiana: Luty 01, 2006, 23:54:20 wysłana przez Majtek »

Offline HIUAUA

  • Użytkownik

# Luty 04, 2006, 13:06:13
Tak sie zastanawiam - po co stosowac tyle metod, skoro mozna sie ograniczyc tylko do 2, a nawet do jednej? Np. OCT moim zdaniem (mowie od razu, ze jeszcze nic nie progrqamowalem z drzewami :P)  powinno wystarczyc, bo ta geometria, ktora pozostanie w stozku widocznosci to juz jej jest chyba nieduzo? Bo przeciez im wiecej technik to tym dluzej procek musi wykonywac obliczenia. Wiec moze to jest rowne? Tzn. skromnosc i szybkosc == dokladnosc i powolnosc? 

nadult

  • Gość
# Luty 04, 2006, 13:33:04
Np. OCT moim zdaniem (mowie od razu, ze jeszcze nic nie progrqamowalem z drzewami :P)  powinno wystarczyc, bo ta geometria, ktora pozostanie w stozku widocznosci to juz jej jest chyba nieduzo?
Uruchom sobie ten program do OCC:
http://sourceforge.net/projects/ooce
i włącz frustum culling, to sie przekonasz czy to niedużo  ;D

Offline HIUAUA

  • Użytkownik

# Luty 04, 2006, 14:19:48
Hmm. Faktycznie....  :P
To znaczy ze jeszcze malo wiem. Ale czlowiek uczy sie cale zycie, nie ?  ;D

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Luty 05, 2006, 13:17:41
Tak sobie myślę (to tylko moje przemyślenia), że z jednej strony może nie warto robić czasochłonnego ograniczania geometrii, bo i tak współczesne karty są nastawione na renderowanie buforów z wieloma tysiącami trójkątów na raz, ale z drugiej strony jeśli w grę wchodzi nierysowanie kilku złożonych obiektów (np. potwory), które jednak renderują się długo, to jednak warto walczyć o dobre wykrywanie zasłonięcia.