Autor Wątek: silnik - nie-renderowanie niewidocznych powierzchni  (Przeczytany 7017 razy)

maxest

  • Gość
# Grudzień 29, 2006, 16:29:11
ten temat to wlasciwie krotkie pytanie odnosnie projektowania silnikow. bo cos sobie teraz skrobie i zastanawiam sie czy takie zadanie jak nie-renderowanie niewidocznych na ekranie obiektow powinno byc wbudowane w obsluge silnika czy raczej tym zajmuje sie programista korzystajacy z silnika?

Offline Mr. Spam

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

Offline Majtek

  • Użytkownik

# Grudzień 29, 2006, 16:41:10
raczej wbudowane
 takie coś jak przycinanie do stożka widzenia jest łatwe, gorzej  z obiektami zakrytymi przez inne 

Offline mINA87

  • Użytkownik

# Grudzień 29, 2006, 16:41:52
Zależy co to za silnik :] I zależy od jego specyfikacji. Generalnie jeśli robisz renderer tylko to możesz to olać i ewentualnie opakować tylko Hwd Occlusion Query, a jesli piszesz silnik graficzny to powinieneś podstawowe mechanizmy cullingu zaimplementować. Chociażby dlatego, że jak będziesz chciał używać swojego silnika, to wrzucisz sobie tylko jakieś obiekty i voila, a tak będziesz musiał kopiuj->wklejować/pisać od nowa/poprawiać culling.
Pisz i tyle :]
//edit: co do obiektów zakrytych przez inne to też nie jest taka masakra. Ogólnie warto postawić frustum culling (na boxach i/lub sferach), BSP z portalami do wnętrz, Octree do terenów otwartych i do tego warto pokusić się occlusion query jeśli masz jakiś mechanizm lod'u u siebie i naprawde dużo skomplikowanej geometrii przysłaniającej się często - łatwo w ten sposób eleminować zasłaniające się obiekty.
« Ostatnia zmiana: Grudzień 29, 2006, 16:45:45 wysłana przez mINA87 »

maxest

  • Gość
# Grudzień 29, 2006, 16:50:56
ogolnie to to ma byc engine do takich gier jak gta2 - widok z gory z obiektami 3d. wiec nie potrzebuje tutaj absolutnie jakichs wyszukanych technik optymalizacyjnych :) wystarczy mi sprawdzic czy obiekt znajduje sie w "kwadracie" ktory "od gory" "widzi" kamera. tak wiec mysle ze to od razu na poziomie kodu renderujacego model moge sprawdzic czy obiekt znajduje sie w widzianym obszarze i w zaleznosci od tego renderowac go lub nie.
i jeszcze jedno: jak mam modele 3d - domy, drzewka itp - lepiej jest sprawdzac je jako "calosci" czy sa widoczne czy lepiej kazdy trojkat po kolei? drugie rozwiazanie spowoduje zakrycie wiekszej ilosci obiektow ale z drugiej strony potrwaloby (CHYBA) znaczniej dluzej
« Ostatnia zmiana: Grudzień 29, 2006, 16:52:59 wysłana przez maxest »

Offline mINA87

  • Użytkownik

# Grudzień 29, 2006, 16:59:32
//edit: co do obiektów zakrytych przez inne to też nie jest taka masakra. Ogólnie warto postawić frustum culling (na boxach i/lub sferach), BSP z portalami do wnętrz, Octree do terenów otwartych i do tego warto pokusić się occlusion query jeśli masz jakiś mechanizm lod'u u siebie i naprawde dużo skomplikowanej geometrii przysłaniającej się często - łatwo w ten sposób eleminować zasłaniające się obiekty.

Fantastyczna recepta na kompletne maslo maslane i problemy z utrzymywaniem/rozwijaniem kodu :).
Jakoś w OGRzE wszytsko o czym mówie jest (no Occlusion Query chyba nie chodzi normalnie tylko trzeba ręcznie podpiąć) i kod jest świetnie zorganizowany, utrzymywany i rozwijany :] Jak się potrafi zaprojektować takie coś to spaghetti nie powstanie :P

maxest: WTF?..... Co Ty chcesz pisać coś sensownego na glVertex3f? Geometrię wysyłamy DUŻYMI partiami! Więc culling na poziomie geometrii odpada - jedynie na poziomie obiektów jak już. Kwestia tylko optymalnej frgamentacji obiekótw i tyle.

maxest

  • Gość
# Grudzień 29, 2006, 17:06:47
Cytuj
WTF?..... Co Ty chcesz pisać coś sensownego na glVertex3f?
nie boj sie - tablice wierzcholkow ;) ale te STANDARDOWE a nie VBO itp. :P i prosze mnie teraz nie pojezdzaz ze nie bede implementowac VBO :) po prostu jak zobaczylem ze sa one dopiero od wersji 1.5 OGL'a to zrezygnowalem :) engine ma byc przeznaczony na sprzet nizszej klasy - nawet sie po-katuje i swiatla bede robic na blendingu a nie per-pixel :P

zastanawia mnie jeszcze tylko renderowanie sprite'ow - w sumie to dosc "proste" konstrukcje :) i teraz nie wiem do konca jeszcze czy je renderowac na glVertex3f'ach czy zrobic jeden czworokat w oddzielnej tablicy wierzcholkow i ja renderowac tyle razy ile jest obiektow?

Offline mINA87

  • Użytkownik

# Grudzień 29, 2006, 17:12:56
st3tc:No to rozwiń prosze swoją myśl :] Masz na myśli że powstają duże narzuty?
Cała mapka? Ja per screen dochodziłem do kilku setek tysięcy jak testowałem moje herezje ze stateless particle systemem oświetlanym pass-per-light czy jak dosyć dużą scenę oświetlałem też pass-per-light jak robiłem sobie normal_specular mapping i powiem Ci że mój radzio 9550 + Sempcio 2k6 + 512MB RAM dawał sobie radę :)
Poza tym szukajcie a znajdziecie :] Strasznie dużo projektów powstało już na OGRzE, a jeszcze więcej jest w zaawansowanym stadium developingu. Polecam przeczytanie sprawozdanka w newsie na ich stronce.

maxest: nie no spoko, ale stary sprzęt się cholernie zapcha przy takim hardcorowym traktowaniu. Lepiej wysyłać mu sensowne porcje danych. Chyba że ilość vertexów per-screen liczysz w setkach :P Nie jestem mastah OGL'a, ale VertexBuffer wprowadozno już w Dx7 a to obsługuje nawet Riva TNT2 :]

maxest

  • Gość
# Grudzień 29, 2006, 17:25:45
no wiem wiem tyle tylko ze chce sobie zrobic klase opisujaca kazdy sprite i miec w niej funkcje render. przerzucenie tego wszystkiego w jedna tablice zeby wyrenderowac calosc jednym wywolaniem glDrawArrays zaburzyloby moja koncepcje :)
//EDIT: ponadto-> co z teksturami (rozne dla roznych sprite'ow)
« Ostatnia zmiana: Grudzień 29, 2006, 17:29:27 wysłana przez maxest »

Offline Spider100

  • Użytkownik
    • Strona domowa

# Grudzień 29, 2006, 23:36:09
Cytuj
i swiatla bede robic na blendingu a nie per-pixel
Nie chcę cię wyprowadzać z  błędu ale śwaitła na blendingu są też per-pixel przynajmniej tak mi się wydawało do teraz :P

Offline mINA87

  • Użytkownik

# Grudzień 29, 2006, 23:42:05
Tzn moze maxest miał na myśli multi-pass ("blending"), per-vertex("a nie per-pixel") :P Ale to też nie ma sensu :P Bo na low-endowy sprzęt warto się ograniczyć do 8 świateł z T&L.

maxest

  • Gość
# Grudzień 29, 2006, 23:55:50
przez "swiatla per-pixel" mialem na mysli swiatla na pixel shader'ach i obliczanie oswietlenia dla kazdego fragmentu :)

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Grudzień 30, 2006, 10:50:58
Skoro piszesz grę w widoku od góry to jedynym sensowym cullingiem będzie, tak jak piszesz, rysowanie tylko tych obiektów które są (przynajmniej teoretcznie i przynajmniej częściowo) widoczne na prostokącie ekranu. Możesz to wyliczyć sprawdzając kolizję tego prostokąta z prostokątem, kwadratem czy okręgiem otaczającym każdy obiekt.

Warto jeszcze, zamiast testować za każdym razem wszystkie obiekty w grze, zastosować jakiś podział przestrzeni, np. quadtree albo zwykłe kafelki (takie duże kwadraty wielkości podobnej do obszaru widocznego na ekranie, które będą miały zapisane listy obiektów leżących na ich obszarze), żeby szybko eliminować większość obiektów, która na pewno nie jest widoczna.

maxest

  • Gość
# Grudzień 30, 2006, 11:51:22
no tak, tylko najpierw musialbym sprawdzac ktore obiekty w ktorym quad'ie sie znajduja... :) ze statycznymi obiektami to w sumie nie byloby zle ale gorzej z obiektami proszujacymi sie

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Grudzień 31, 2006, 13:00:28
Ano owszem, gorzej, ale da się zrobić - trzeba podczas poruszania takiego obiektu (zmiany jego pozycji) sprawdzać, czy nie przeskoczył na sąsiedni kafelek i w razie potrzeby tam go przenieść.

maxest

  • Gość
# Grudzień 31, 2006, 16:55:47
poprobuje z tym jak przyjdzie czas :)
poki co bardziej martwia mnie te sprite'y bo jak na razie renderuje je tak:

                int framesPerRow = GraphicsCore::curTextureWidth/animFrame.widthPerFrame;

                animFrame.curFrame += animFrame.frameSpeed;
                if ((int)animFrame.curFrame == animFrame.endFrame+1)
                {
                    animFrame.curFrame = (float)animFrame.startFrame;
                }

                float vertices[12];
                float texCoords[8];

                vertices[0] = x - width/2.0f;
                vertices[1] = y - height/2.0f;
                vertices[2] = z;
                vertices[3] = x + width/2.0f;
                vertices[4] = y - height/2.0f;
                vertices[5] = z;
                vertices[6] = x - width/2.0f;
                vertices[7] = y + height/2.0f;
                vertices[8] = z;
                vertices[9] = x + width/2.0f;
                vertices[10] = y + height/2.0f;
                vertices[11] = z;

                texCoords[0] = (float)((int)(animFrame.curFrame-1))/(float)framesPerRow;
                texCoords[1] = 0.0f;
                texCoords[2] = (float)((int)(animFrame.curFrame))/(float)framesPerRow;
                texCoords[3] = 0.0f;
                texCoords[4] = (float)((int)(animFrame.curFrame-1))/(float)framesPerRow;
                texCoords[5] = 1.0f;
                texCoords[6] = (float)((int)(animFrame.curFrame))/(float)framesPerRow;
                texCoords[7] = 1.0f;

                glVertexPointer(3, GL_FLOAT, 0, vertices);
                glTexCoordPointer(2, GL_FLOAT, 0, texCoords);

                glPushMatrix();
                    glTranslatef(x, y, z);
                    glRotatef(angle, 0.0f, 0.0f, 1.0f);
                    glTranslatef(-x, -y, -z);
                    glTranslatef(deviation, 0.0f, 0.0f);
                    glColor4f(r, g, b, a);
                    glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
                glPopMatrix();

chcialem zrobic to tak ze wszystkie sprite'y renderowalbym jednym glDrawArrays'em, ale przez glTranslate i glRotate zmuszony jestem renderowac je oddzielnie, zeby wykonac przeksztalcenia. jakis pomysl jak to mozna obejsc?