Modele 3D, rendering w grach - wydajność

[Temat]

Witam

 

Zajmuje się programowaniem gier w jezyku C# z wykorzystaniem technologi Microsoft XNA Framework 4.0. Znam przelotnie obsluge programów do modelowania 3D (blender ,3D Studio MAX). Uzywam gotowych modeli zapisanych/konwerowanych w pliki *.FBX i uzywajac silnika programowania XNA aplikacji (DirectX Managment) wykorzystuje je w grach. Do momentu rozwijania swoich aplikacji pod platformy Windows PC i XBOX 360 nie mialem zadnego problemu z wydajnoscia ,tzn. wyswietlaniem odpowiedniej ilosci klatek na sekunde ,zarówno PC jak i XBOX 360 przyjmowaly praktycznie wszystkie modele .W wiekszosci korzystam z darmowych modeli znalezionych w internecie ,jak pisalem gdy sprzęt był mocny bez problemu wyswietlalem skomplikowane modele 3D zlozone z duzej ilosci Meshes (siatek?,czesci calego modelu?) oparte o bardzo duza ilosc wierzcholkow. Jednak obecnie piszę gry dla urządzeń mobilnych opartych o system Windows Phone 7 ,no i o tyle o ile softwaerowo system jest calkiem fajny (tj. efekty Direct.X 9 ) o tyle sprzętowo urządzenia wysiadają .

Sam system jest stosunkowo nową platformą wiec obecnie mamy na rynku pierwsza generacje urządzeń dedykowanych w wiekszości opartych o procesor QSD 8250 taktowany 1Ghz oraz GPU Adreno 200 (200Mhz) (Telefony HTC ,Samsung ,Dell itp...) Co prawda postęp przez ostatni rok w sprzecie ukladach ARM dla windws phone 7 byl ogromny i są juz duzo szybsze uklady (2 rdzenie,duzo szybsze gpu) ,jednak tych urzadzen oparych o nowe uklady nie ma jeszcze a rynku a zaim staną sie tak populare jak obecne potrwa napewno ponad rok. A problem jest taki ze obecne urządzenia są bardzo bardzo wolne w porównaniu do mozliwosci programowych. Tam gdzie PC i XBOX bez problemu wyswietlal skomplikowane modele w wielkosci *.FBX ~8mb przy 60fps to urzadzenie mobilne np HTC HD 7 ma bardzo duzy problem z plynnoscia wyswietlania przy modelach nawet bez textur zajmujacych 0.5mb *.FBX .

Dobra plynnosc tak naprawde uzyskuje dopiero wyswietlajac proste modele ktore sam swtorze w blenderze oparte o 4 wierzcholkowe Boxy i inne elementy "bez wierzcholkow". Problem jest taki ze bardzo malo jest takich modeli w internecie ,w ogóle praktycznie takich modeli nie jestem w stanie znalesc nigdzie. Wydaje mi się ze dobrym rozwiazaniem bylo by wlasnie modelowanie prostego pojdedynczego Mesh'a i otexturowanie go calego?. Takie modele byly stosowane w dawniej w pierwszych grach 3D.

Ma ktoś moze jakis pomysł ,podpowiedzi? porady? jakich modeli uzywac najlepiej w którą strone isc ,jak tworzyc modele aby uzyskac jak najlepsza wydajnosc?. Nie korzystalem z tego forum poniewaz tak jak napisalem wczesniej sam etap tworzenia modelu do gier mógł być mi obcy do obecnego momentu ,gdzie jestem na 100% pewny że wydajność moich gier spada nawet kilkunastukrotnie w zaleznosci od modelow ktore uzywam. Proszę o jakies porady skad wziasc takie modele ewentualnie jaka jest najlepsza (i najszybsza) technika tworzenia ich? .Również jeżeli bylby ktos z jakiś powodów zainteresowny tworzeniem modeli do gier proszę pisać.

[PAINbringer]

Obciążenie jakie generuje model 3d nie liczy się w MB, tylko w kilku równolegle wpływających na wydajność jego parametrach. Takich jak np.: ilość poligonów, wierzchołków, draw calli (*shader), czasami fill rate, itp

 

Jeżeli chcesz zrobić coś działającego na dzisiejsze platformy mobilne to nie możesz spodziewać się, że będą działać na nich modele z GOW3 które mają po 16.000 trójkątów. Wszakże niewiele jest GOW'ów na komórki...

Także przede wszystkim do zrozumienia tematu polecam autopsję powstałych już tytułów na te sprzęty. Można się z nich bardzo wiele dowiedzieć. Bo pierwsze co się rzuca na nich w oczy to to, że budżety poligonów (per frame) są niewielkie (strzelam: kilka k max?), textury są również niewielkie (tekstura 256/256 pixeli w DXT5 to 85kB), a liczba draw calli i fill rate są zawsze troskliwie optymalizowane

 

Pozdr

[JacekCichy]

@PAINbringer - za to ile jest drawcall'i odpowiada programista a nie model, fill rate z tego co mi wiadomo to po prostu wspolczynnik wydajnosci karty wiec tez nie ma to z modelem wiele wspolnego. To tak w celu sprostowania :)

 

@Temat - Ja zajmuje się programowanie w C/C++ i Java w obu z wykorzystaniem OpenGL. Co do urzadzen mobilnych to niestety nie mam zadnego doswiadczenia bo zajmuje się czystym PC natomiast z tych parametrów które podajesz to na moim starym komputerze: Duron - 750Mhz, GeForce 3 (200-230Mhz) Czyli sprzęt o podobnych parametrach, to jak sięgam pamięcią wstecz to dobrze chodziły takie tytułu jak: Quake 3, Jedi Academy, Call of Duty 2, Need for speed 5. Jeśli włączysz sobie gry-online.pl lub inna stronę o grach to znajdziesz trochę screenów po których można zobaczyć ile polygonów przypada na postać, teren, samolot/samochód itd. I w jakiej mniej więcej rozdzielczości są tekstury. Z tego co mi wiadomo to na główne modele w tych grach nie przypada więcej niż 2-3k trójkątów a co do tekstur to raczej nie przekracza się 512^2. Teren jest najczęściej uproszczony i takie bajery jak np trawa na całym terenie w postaci billboardów nie wchodzi w grę. Natomiast to co jest bardzo ważne to poczytaj coś więcej o specyfikacji tej karty i o tym czy ma wsparcie sprzętowe do directx albo opengl bo wydaje mi się że powinno być ;) I słowo zakańczające to zarówno aplikacje Java i C# na nowych procesorach PC chodzą porównywalnie do aplikacji pisanych w językach natywnych natomiast np na moim starym komputerze (duron 750mhz) widać dużą przepaść wydajności. Dodatkowo to to co pisze kolega wyżej: ważne jak napiszesz swój kod, czy będziesz używał optymalizacji (system LOD, drzewa binarne ósemkowe lub inne, oszczędność drawcalli, zoptymalizowany prosty silnik fizyki (raycasting)), jeżeli tak to może uda Ci się stworzyć coś porównywalnego do wyżej wypisanych tytułów lub troszke nawet lepsze, jeżeli nie no to może być problem z paroma oteksturowanymi boxami. Pozdrawiam i powodzenia!

[PAINbringer]

@JacekCichy

W kwestiach technicznych/naukowych opinie nie mają żadnego znaczenia

Wprowadzasz niepotrzebny zamęt mate. Weź pod uwagę to, że ktoś może potraktować to nie-sprostowanie poważnie...

 

Mianowicie sugerujesz innym kolegom, że ilość draw calli na ramce nie zależy od liczby i budowy modeli. Sprawdzałeś to? Odp: Nie...

 

Fill rate - tu masz do połowy rację. Tak - to parametr karty graficznej.

Co do reszty nie masz, bo nie wiesz co oznacza ten parametr i dlaczego takowy w ogóle jest, więc nie rozumiem dlaczego w ogóle się udzielasz w tym temacie nie robiąc nawet podstawowego google-searcha...

 

Peace

[JacekCichy]

@PAINbringer - Piszesz w dość prowokacyjnym stylu ale spokojnie nie dam się sprowokować :) Mam do Ciebie kilka pytań:

 

Pierwsze: czemu twierdzisz że to co napisałem jest opinią wyssaną z palca i że wprowadzam zamęt plus że nie wiem o czym piszę?

 

Drugie: Zacznijmy od drawcalli. A więc twierdzisz że to zależy od liczby i budowy modelu. Jeżeli założymy że programista nie ma zielonego pojęcia jak to wpływa na wydajność i że nie ma się ograniczać to owszem.. tak, bo w prosty i przyjemny sposób część rzeczy sobie załatwi. Natomiast jeżeli programista jest dobry i chce napisać dobry program to o tym fakcie wie. A więc załóżmy że ma model samolotu z podwoziem o ilości 10k tris, znając wpływ ilości drawcalli nie będzie rysował osobno samolotu, klapki od podwozia, siłowniczka, kółeczka itd. Tylko wrzuci sobie do VBO wszystkie wierzchołki owego modelu po czym jak będzie chciał aby kółeczko się schowało to wywoła jeden drawcall z tym że wcześniej odpowiednie wierzchołki przemnoży przez odpowiednią macierz. Owszem utrudni mu to sprawę bo będzie musiał stworzyć czy to klase czy jakis system odpowiadający za animację szkieletową itd. Zamiast wywołać po prostu kolejnego drawcalla i narysować sobie kółeczko. Idźmy dalej, weźmy drzewo, weźmy trawę, chcemy to animować, owszem możemy użyć osobnych drawcalli do każdej gałęzi czy do każdej kępki trawy, ale jeżeli wiemy że nie jest to dobry pomysł to będziemy używać pojedynczych drawcali i będziemy używać dynamicznego VBO. Tak więc nie skomplikowanie modelu wpływa na ilość drawcalli a jedynie to to że jeżeli chcemy mieć w grze 20 samolotów osobno sterowanych przez AI to raczej musimy zrobić 20 osobnych drawcalli bo one nie bardzo od siebie zależą, natomiast skomplikowanie modelu według mnie spokojnie można pominąć i jest to jak najbardziej prawidłowe podejście. Zapomniałem o pytaniu :P proszę napisz mi jak to według Ciebie skomplikowanie modelu ma wpływać na ilość drawcalli :)

 

Trzecie: Fill-rate. Co oznacza parametr dobrze wiem. I znowu masz rację zakładając że programista po prostu sobie wyświetlił skomplikowany model i się bardzo cieszy że szczęśliwie mu się on pokazał i na tym zakończył swoją ambitną pracę. Natomiast jeżeli wysilił swoje szare komórki to doszedł do wniosku że rysowanie tylnich ścianek i brak sortowania obiektów zje mu bardzo dużo rzeczonego fillrate bo będzie go tracił na rysowanie czegoś czego nie widać bo jest "nadpisywane". Ten nasz programista po dojściu do tego wniosku zrobi sortowanie obiektów, nie będzie rysował tylnich ścianek i postara się na taką optymalizację aby fillrate praktycznie uniezależnić od skomplikowania modelu. Zapytasz pewnie hmm no fajnie to dlaczego nie mogę sobie wyświetlić 1miliona trójkątów na urządzeniu mobilnym? Odpowiedź jest taka że wpływa na to przepustowość (częstotliwość) taktowania rdzeni procesorów shaderów, ilość tych rdzeni, bo coś musi przetwarzać ten 1m trójkątów(wierzchołków), dodatkowo algorytmy sortowania itp. też troche zżerają mocy więc jeżeli będą miały sortować 1m trójkątów to procesor najprawdopodobniej może mieć w pewnym momencie problem. Reasumując fillrate pewnie trochę będzie miał wpływ jeżeli będziemy stosować uproszczone algorytmy sortowania w zamian za zachowanie trochę wolnej mocy procesora. (mówimy tu o jedno rdzeniowym raczej wolnym procesorze) Natomiast Czy jest to główny wskaźnik którym należy się przejmować i ograniczać z jego powodu budowę modelu... według mnie nie. Ma on tak znikomy wpływ w zoptymalizowanym programie(silniku) że można go pominąć.

 

Słowo końcowe: Też jestem programistą i wiem że można zrobić coś szybciutko co jest w miare funkcjonalne i założyć że użytkownik kupi sobie najnowszy komputer bo przecież działa, po co się będę wysilał itd. Natomiast powiem szczerze że denerwuje mnie takie podejście bo wbrew pozorom bardzo dużo gier i nie tylko mogło by być uruchomionych na dużo słabszym sprzęcie tylko programistom się niechce albo firma ma terminy i tak naprawdę ma ona w głębokim poważaniu użytkownika. Piszę tą opinię trochę z doświadczenia bo pracowałem w firmie wtedy jeszcze jako grafik i główny programista dość leniwy i wygodnicki po ukończeniu przeze mnie wszystkich modeli które były zoptymalizowane i spokojnie mogły być wyświetlone w grze na ówczesnych komputerach stwierdził że 1k-2k trójkątów to stanowczo za dużo bo jego silnik nie daje rady.. i nie wyświetli sceny składającej się z 20k trójkątów na komputerach z kartą lepszą niż GF3, nie wspominając o tym że nie było tam zabardzo fizyki, a AI było bardzo uproszczone. Co więcej przekonał szefa (mało znającego się w temacie) i musiałem grzecznie starać się zrobić świetnie wyglądające modele z ograniczeniem do 128 trójkątów... (MISSION IMPOSSIBLE) Cóż wtedy wydawało mi się bardzo dziwne bo różne ówczesne gry ładnie wyglądały trójkątów było więcej niż 1k na całą scenę, miały dobrą wydajność a u nas w firmie się nie dało. No ale mało znałem temat w dodatkowo jak ma się polecenie od szefa to można porozmawiać ale nieraz to mało wnosi. Tak więc jakoś podjąłem wyzwanie no i wyszło też jakoś. Tak więc grafik musi się starać ale programista również, wtedy to ma sens a produkt łączy w sobie cechy ładnie wyglądającego i wydajnego.

 

Pozdrawiam!

[PAINbringer]

Ej, wcale nie piszę w prowokacyjnym stylu... no dobra piszę ;) Sorry że to tak zabrzmiało, ale mnie czasami krew zalewa jak czytam, że wydajność draw calli nie zależy od grafików tylko od samych programistów. Wierz mi, że chciałbym żeby tak Nie było, ale niestety jest.

 

(...) Pierwsze: czemu twierdzisz że to co napisałem jest opinią wyssaną z palca i że wprowadzam zamęt plus że nie wiem o czym piszę?

W porządku - przyznaję że wiesz o czym piszesz. Ale to nie zmienia faktu, że to co napisałeś może kogoś bardzo poważnie wprowadzić w błąd

 

(...) napisz mi jak to według Ciebie skomplikowanie modelu ma wpływać na ilość drawcalli :)

W bardzo prosty sposób - niedoświadczeni graficy robią modele które mają za dużo (np 3+) sub-materiałów lub sub-meshy. Jeżeli ten model jest na ramce raz, to nie ma problemu, ale jeżeli jest mały i powtarza się wielokrotnie - to zaczynają się tu już problemy. Dlaczego? (tu odpowiedź na Twoje pytanie) Bo każdy z nich, na złość programistom, jednak produkuje nowe draw calle

Dobrze wiem, że każdą funkcję shadera i renderera da się zoptymalizować, meshe łączyć, wyłączać... itd, ale prawdziwa rzeczywistość pracy nad grą jest taka, że nie da się zamknąć dobrze działającej gry, jeżeli assety graficzne do niej nie są optymalnie przez grafików robione (m.in.) pod kątem draw calli/materiałów

 

Trzecie: Fill-rate. (...)Czy jest to główny wskaźnik którym należy się przejmować i ograniczać z jego powodu budowę modelu... według mnie nie. Ma on tak znikomy wpływ w zoptymalizowanym programie(silniku) że można go pominąć.

Dopóki nie używasz shaderów translucent to faktycznie nie ma. Ale tych shaderów się jednak używa i to często. Zwłaszcza przy fx'ach - a to śmierć dla wydajności (sprawdzałem na PC i XBoxie)

Druga sytuacja to np. pojedynczy duży mesh, z wieloma overlapami na ramce. No pewnie ze cudownie by było, gdyby jedyne silniki na których ludzie na co dzień pracują, to te super zoptymalizowane UE3, Crytech, IDtech etc ale to tylko połowa. Bo bardzo często trzeba pracować w firmie na autorskich silnikach, które tego nie mają jeszcze napisanego

To prawda, że nie trzeba się w 99% przypadków przejmować fillrate'm. Ale ten 1% to właśnie sytuacja, w której dana osoba nie wie co to fillrate (bo przeczytała Twój post ;)) i zrobi model który go zabije ;D

 

 

Słowo końcowe: Też jestem programistą (...)

nie jestem programistą u_u'

 

(...)Tak więc grafik musi się starać ale programista również, wtedy to ma sens a produkt łączy w sobie cechy ładnie wyglądającego i wydajnego.

I właśnie dlatego się oburzyłem, bo to co napisałeś sugerowało wszystkim początkującym grafikom, że mogą się nie przejmować ilością shaderów na ich meshach, czy typami tych shaderów

Dokładnie o to mi chodziło, przynajmniej pod tym względem mamy concensus

 

Pozdrawiam

[Chico]

Damn - 3 posty bodaj a ile wiedzmey - panowie, nie przestawajcie :D

[JacekCichy]

@Chico - Ciesze że Ci się podoba :) :P

 

@PAINbringer - Tak na wstępie to mam nadzieję że Cię nie obrażam, dla mnie to dyskusja techniczna lub ewentualnie mały spór techniczny :P :) Dlaczego ważny to jeszcze wrócę do tego tematu ale najpierw chciałbym się odnieść do tego co piszesz.

 

Wracając do nieszczęsnych DrawCalli.. Jeżeli się całkiem w to wgłębić to masz częściowo rację, np. VBO jest tworem stosunkowo nowym, a zanim wszedł do użycia to w zasadzie jeżeli chciało się mieć jakiś obiekt animowany (czy to postać czy to robocik z siłowniczkami i innymi szpejami) to DrawCalle było ciężko wepchnąc do jednego. Natomiast w obecnej erze tak jak już pisałem, model który utworzył grafik i składa się choćby z 50 submeshy, z których każdy jest niezależnie animowany, można wepchnąć do jednego Drawcalla. Jak? No w bardzo prosty sposób, po prostu dodać informację do każdego wierzchołka w tablicy pod którą kość podlega lub pod którą macierz(w zasadzie to to samo :)), w przebiegu pętli pomnożyć każdy wierzchołek przez macierz która się do niego odnosi po czym całą tablicę wyświetlić w jednym drawcallu. Co do wielu tekstur zamiast jednej, też coś się da zrobić. Wiadomo że fajnie jeżeli i graficy i programiści mają pracę rozłożoną w miarę po równo a wynikiem jest fajna gra, silnik lub aplikacja. A celowe zażnięcie programisty tylko dlatego że jest programistą i sobie poradzi jakoś jest równie bez sensu jak zrobienie tego samego z grafikiem. Jednak wiele rzeczy można zrobić. Co do wielkości renderowanego obiektu to jeżeli jest skomplikowany i daleko to powinien być stosowany system LOD ewentualnie Siatka adaptacyjna i to rozwiązuje problem, jeżeli natomiast jest blisko i jest mały i bardzo skomplikowany no to cóż... nie będe się spierał że to jest sensowne, ale to ma niewiele chyba z DrawCallami wspolnego :).

 

Co do fillrate to muszę przyznać że jak na kogoś kto nie jest programistą to albo jesteś bystrzacha albo po prostu dużo wiesz :) Tutaj Cię trochę zaskoczę bo przyznałeś mi słuczność, a i ja ją Tobie również przyznam. Fakt obiekty przeźroczyste mi trochę umknęły. W tym przypadku masz rację :) Co prawda w grach raczej nie stosuje się dużej ilości obiektów przeźroczystych, a jeżeli są to rzadko są one skomplikowane, natomiast jeżeli Pan Temat zechce zrobić grę pod tytułem żelkowe misie w żelkowej krainie to w przypadku urządzeń mobilnych faktycznie fillrate może odgrywać ważną rolę :)

 

Chciałem jeszcze napisać dlaczego uważam że szczegóły są ważne, otóż w swojej programistycznej karierze (nie jest ona taka długa więc bodajże 2 lata temu) miałem śmieszno-straszną historię. A mianowicie gdzieś wyczytałem i ktoś kto nie napisał żadnego programu mi tę złą informację potwierdził jakoby mnożenie, dodawanie i odejmowanie zajmowało procesorowi podobną ilość taktów a dzielenie było ponad sto razy wolniejsze i że dzielenia należy wystrzegać się jak ognia. Jako iż wtedy doszedłem do etapu detekcji kolizji a dokładnie do najtrudniejszego i najbardziej zasobożernego przypadku czyli kolizji trójkąt-trójkąt więc chciałem ten problem rozwiązać jak najlepiej. W sieci natrafiłem na jeden bodajże z dwóch dokumentów oczywiście po ang. opisującego jak to też ten temat matematycznie ugryźć, niestety pomimo języka ang. na jako takim poziomie, opis matematyczny mnie dobił i stwierdziłem że trzeba się samemu zastanowić. Na szczęście mam jednego kumpla którego matematyka fascynuje, ot tak hobby. Nie jest kujonem ani nikim kto by się niechciał podzielić wiedzą więc telefon, mówię jaki problem i jakie założenia (0 dzieleń za wszelką cenę) no i na pewien czas temat ucichł. Kolega myślał intensywnie tydzień w końcu po tygodniu siedząc "za przeproszeniem" kiblu doznał olśnienia i wymyślił :P Ponieważ oczywiście kolizje miały zachodzić w 3D i spełnione miały być wszystkie przypadki więc rozwiązanie też nie było takie proste. Podczas demonstracji rozwiązania tego problemu potrzebny był dodatkowy kolega żeby to wszystko w "przestrzeni" zobrazować :P W szczegóły nie będę się wgłębiał natomiast występowało dużo iloczynów skalarnych, wektorowych, "obudowywań" trójkątów w ostrosłupy itp. Szczerze mówiąc byłem pod wrażeniem, natomiast to co okazało się smutne to to że dzielenie wcale nie jest takie straszne i że owszem dodawanie i odejmowanie są podobne jeżeli chodzi o czas procesora natomiast mnożenie jest dużo wolniejsze a dzielenie ok. dwa razy wolniejsze od mnożenia. Tak więc najprawdopodobniej lepiej by było zastosować dwa dzielenia zamiast 40 mnożeń :P wiadomo wiedza i doświadczenie zostało natomiast jak się okazało mały szczegół a cały wysiłek trochę bez sensu :P

 

EDIT: Spieramy się o szczegóły bo definicje znamy te same, tylko ja uważam że DrawCalli powinien pilnować programista, Ty że grafik :)

 

Pozdrawiam!

Edytowane 7 Czerwiec 2011 przez JacekCichy

[Chico]

Nie mozna sie pogodzic i powiedziec ze Grafik z programista wspolnie powinni pilnowac i siebie i drawcalii ? :P

[Por@szek]

Nie mozna sie pogodzic i powiedziec ze Grafik z programista wspolnie powinni pilnowac i siebie i drawcalii ? :P

Tia tylko jak sie w miare dogaduja i kazdy zna sie na swojej robocie ... inaczej sie zabija ... zakladajac ze wczesniej nie zabija designera ktory to wymyslil :)

[Chico]

Panowie spejcalisci - mozecie zebrac wnioski i deifnicje z waszej rozmowy ? :) tak dla ulatwienia i uporzadkowania wiedzy w nich zawartych.

[PAINbringer]

(...) Wracając do nieszczęsnych DrawCalli.. Jeżeli się całkiem w to wgłębić to masz częściowo rację, np. VBO jest tworem stosunkowo nowym, a zanim wszedł do użycia to w zasadzie jeżeli chciało się mieć jakiś obiekt animowany (czy to postać czy to robocik z siłowniczkami i innymi szpejami) to DrawCalle było ciężko wepchnąc do jednego. Natomiast w obecnej erze tak jak już pisałem, model który utworzył grafik i składa się choćby z 50 submeshy, z których każdy jest niezależnie animowany, można wepchnąć do jednego Drawcalla. (...) Co do wielu tekstur zamiast jednej, też coś się da zrobić. Wiadomo że fajnie jeżeli i graficy i programiści mają pracę rozłożoną w miarę po równo a wynikiem jest fajna gra, silnik lub aplikacja. A celowe zażnięcie programisty tylko dlatego że jest programistą i sobie poradzi jakoś jest równie bez sensu jak zrobienie tego samego z grafikiem. Jednak wiele rzeczy można zrobić. Co do wielkości renderowanego obiektu to jeżeli jest skomplikowany i daleko to powinien być stosowany system LOD ewentualnie Siatka adaptacyjna i to rozwiązuje problem, jeżeli natomiast jest blisko i jest mały i bardzo skomplikowany no to cóż... nie będe się spierał że to jest sensowne, ale to ma niewiele chyba z DrawCallami wspolnego :).

(...)

Tak jak napisałeś łączenie meshy w VBO działa świetnie, lecz trzeba tu wiedzieć iż można w ten sposób zoptymalizować jedynie część obiektów - wiele meshy dynamicznych/skryptowanych pozostawia się jako renderowane oddzielnie. A w praktyce - w grach takich obiektów chce się mieć często wiele

Obiekty LOD wbrew pozorom są dobrym przykładem jak grafik może zarżnąć klatki drawcallami. Wystarczy że wszędzie dalej niż lod#2 pozostawia na meshu więcej niż jeden materiał. Piszę o tym dlatego, iż wiem z doświadczenia, że bardzo wielu grafików o tym nie wie, że wraz z kolejnym lod'em powinna spadać nie tylko ilość trójkątów, ale i materiałów (co łatwo przeliczyć właśnie na drawcalle)

 

(...)Jak? No w bardzo prosty sposób, po prostu dodać informację do każdego wierzchołka w tablicy pod którą kość podlega lub pod którą macierz(w zasadzie to to samo :)), w przebiegu pętli pomnożyć każdy wierzchołek przez macierz która się do niego odnosi po czym całą tablicę wyświetlić w jednym drawcallu.(...)

Wybacz, ale to forum wbrew pozorom nadal odwiedzają jeszcze ludzie a nie maszyny - i chcą usłyszeć coś w swoim języku

*Tłumaczenie dla humanoidów: Kolega pisze o prostym merge'owaniu meshy :D

(W Unity znajdziesz to w: Component>Mesh>Merge Children)

 

(...) Co prawda w grach raczej nie stosuje się dużej ilości obiektów przeźroczystych, a jeżeli są to rzadko są one skomplikowane (...)

Wręcz przeciwnie - obiektów przezroczystych jest bardzo wiele w grach. Efekty specjalne są tutaj dobrym przykładem - w takim COD czy GOW jest ich ogromna ilość. Ostatnio w demo Rage widziałem fx'y wody na alpha test, powodem tego (poza sortowaniem) jest przede wszystkim właśnie wydajność fx'ów na konsolach, które słabo znoszą translucenty

Trzeba też pamiętać, iż wymienione przez Ciebie 'skomplikowanie obiektów przezroczystych' liczy się nie tyle w ilości poligonów, tyle co w % powierzchni frame'a którą mogą zająć (...czyli chodzi o fillrate)

 

(...) Spieramy się o szczegóły bo definicje znamy te same (...)

Szczerze mówiąc to niewiele znam definicji z poruszanych tematów, większość tego co mogę powiedzieć na ten temat to tylko lekcje z brutalnej praktyki

 

(...)ja uważam że DrawCalli powinien pilnować programista, Ty że grafik :)(...)

To chyba dobre podsumowanie naszej dyskusji :)

 

Osobiście uważam tak dlatego, iż często graficy muszą pracować bez programisty silnika/renderera obok. A w takich sytuacjach sami dobrze muszą wiedzieć co robią. Sytuacja taka ma np. miejsce, gdy pracuje się na licencjonowanym silniku

 

Pozdrawiam

 

 

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

EDIT:

(W Unity znajdziesz to w: Component>Mesh>Merge Children

Taka opcja jest w 3ds maxie?

W maxie nazywa się to Attach (yup) i klikasz na meshe z tym samym materiałem. Efekt jest ten sam.

Edytowane 17 Lipiec 2011 przez PAINbringer

[JacekCichy]

...Obiekty LOD wbrew pozorom są dobrym przykładem jak grafik może zarżnąć klatki drawcallami. Wystarczy że wszędzie dalej niż lod#2 pozostawia na meshu więcej niż jeden materiał. Piszę o tym dlatego, iż wiem z doświadczenia, że bardzo wielu grafików o tym nie wie, że wraz z kolejnym lod'em powinna spadać nie tylko ilość trójkątów, ale i materiałów (co łatwo przeliczyć właśnie na drawcalle)

Ok zgadzam się z Tobą tylko czy w lod#2 którego słabo widać jest to dużym utrudnieniem dla grafika nie wiedzącego o tym o czym piszesz połączyć wszystkie submeshe w całość i z 3 podtekstur zrobić jedną teksturę? Ja swoje teorie piszę odnośnie modelu bazowego oraz o jego optymalizacjach(duzej odpowiedzialności programisty, małej grafika). Co do obiektów dynamicznych/skryptowanych to chyba zależy od silnika :) Ale w tych przysłowiowych ferrari (Idtech, Cryengine, UE) myślę że dbają o takie rzeczy :)

 

Wybacz, ale to forum wbrew pozorom nadal odwiedzają jeszcze ludzie a nie maszyny - i chcą usłyszeć coś w swoim języku

*Tłumaczenie dla humanoidów: Kolega pisze o prostym merge'owaniu meshy :D

(W Unity znajdziesz to w: Component>Mesh>Merge Children)

A żeś się przyczepił :) tylko nie wiem czy objaśnienia czy budowy zdań :P Chodziło mi ni mniej ni więcej o animację szkieletową i o to że obiekt podlegający jej może być jednym meshem. Dodatkowo animację szkieletową można z dużym powodzeniem wykorzystać nie tylko do animacji postaci gdzie pojedynczy wierzchołek modelu może mieć przypisane więcej niż jedną kość (przez co powstaje np. deformacja skóry) ale np. w animacji skomplikowanego podwozia samolotu które też będzie pojedynczym meshem (w tym przypadku pojedynczy wierzchołek będzie podlegał pod jedną i tylko jedną kość). Wcześniej napisałem to bardziej pseudo-kodem programistycznym :) Jeżeli ktoś nie rozumie dalej niech pyta, zdaję sobie sprawę ze swoich ułomności humanistycznych :)

 

.. obiektów przezroczystych jest bardzo wiele w grach...

Ok w przypadku wody masz 100% racji :) Ale czy np. w COD było jej tak dużo? W przypadku Silent Huntera na morzu to faktycznie stanowi ona 90 procent ramki ale nie jest to kategoria gier które są popularne wśród graczy, choć może to zły argument :P :) Co do liczenia ilości polygonow to myślę że też są istotne a dodatkowo dochodzi czynnik zwany fillrate który poza wymienionymi przypadkami jest pomijalny. (Pisze o PC bo o urządzeniach mobilny mam małe pojęcie i zero doświadczenia więc niechce kogoś w błąd wprowadzać)

 

BTW. Bardzo fajne rysunki koncepcyjne tworzysz :) Dopiero teraz mi się udało kilka znaleźć.

 

Pozdrawiam :)

[Temat]

Jezeli DrawCallem ,nazywacie wywolanie metody Draw() z klasy omawianego Modelu ,to nie wiem w czym problem skoro istnieje w C# cos takiego jak petla foreach ,ktora wywola sobie tyle razy metode Draw() ile elementow bedzie zawierala kolekcja klasy modelu na ktorej bedziemy wkonywac petle. Jezeli chodzi o "starsze" kody ANSI C pochodne identyczny zabieg mozna wykonac za pomocą zwyklej petli for w której ilosc przebiegow w drugim agumencie musi byc rowna ilosci elementów w kolekcji (tablicy) ,taka ilosc zwracana jest np przez metode .Count danej kolekcji.

 

Jezeli chodzi o praktyczna wydajnosc to wyeksportowny model *.fbx z blendera jako 40 Meshes (czyli w wypadku foreach petla bedzie miala 40 cykli) wyswietla sie srednio o 2-3fps wolniej niz ten sam model w ktorym wszystkie siatki zostaly polaczone i wyeksportowane do *.fbx jako jeden Mesh. Tylko ze w tym wypadku nie bedzie roznicy czy odwolam sie bezposrednio do pojedynczego wywolania metody Draw dla obiektu Mesh[0] (kolekcja zawiera jeden element) ,czy tez wykonam zautomatyzowana petle foreach (lub tez dobrze zrobionego for) poniewaz z racji tego ze moja kolekcja siatek mojego modelu (tak wyeksportowana w blenderze) zawiera tylko jeden element petla wykona pojedynczy cykl. Dalej idac tropem wydajnosci przy technologi XNA Framework 4.0 (Managment DirectX 9.0C PS 3.0) i sprzecie klasy CPU 1x1400Mhz GPU 350Mhz/200Mhz 128mb DDR zredukowanie wywolan metod Draw() Modeli bioracych udzial w renderingu z 250 do 10 ,owocuje juz zyskaniem kilkunastu FPS. Na XBOXie 360 roznicy nie ma zadnej roznicy w FPS ,ale to tylko dlatego ze jest sprzetowy overkill ,gdyby sama animacje wzbogacic tak aby dodatkowo obciazyla konsole mysle ze przyrost bylby porownywalny. Wszystkie dane w oparciu o standartowe oswietlenie kazdego mesha EnableDefaultLight = true;

 

A moj problem tytulowy zostal rozwiazany polegal na tym ze modele nie byly lowpoly a dokladnie to posiadaly za duza ilosc vertexow ,po znalezneiniu wlascwych gotowych modeli lowpoly z texturami i wyeksportowaniu i podmianie ich ,cala aplikacja dostala niesamowitego kopa nawet na dychawym sprzecie mobilnym z architektura Arm.

 

Osobiscie wydaje mi się ze jednak najwieksza wplyw na wydajnosc ma wlasnie skomplikowanie wykonania modelu przez modelujacego ,tzn przykladowo Ja majac slabe pojecie o modelowaniu gdybym chcial zrobic podobnie wygladajace lowpoly sam musialbym przy moim stadium zaawansowania uzyc kilkakrotnie wiecej wierzcholkow niz autor moich modeli aby oteksturowany model wygladal rownie atrakcyjnie

[Skoti]

Sorry, że odkopuję po kilkunastu dniach, ale dopiero teraz zobaczyłem wątek i chciałem kilka rzeczy sprostować.

 

Obciążenie jakie generuje model 3d nie liczy się w MB, tylko w kilku równolegle wpływających na wydajność jego parametrach. Takich jak np.: ilość poligonów, wierzchołków, draw calli (*shader), czasami fill rate, itp

Ilość wierzchołków i poligonów jest ściśle od siebie zależna i bez sensu jest pisać jako osobne rzeczy, ilość drawcalli jest ważna (tym bardziej w Dx który na ich ilość jest szczególnie uczulony, ze względu na duże narzuty funkcji) i zależy równie bardzo od grafika jak i programisty, jednak fillrate niewiele ma tu do powiedzenia - nawet jeśli mamy olbrzymie ilości geometrii i są one wrzucane wszystkie do GPU jako double side, to i tak powycina je test głębokości, więc fillrate nie będzie zagrożony - fillrate powinien przejmować się raczej programista, bo tu problemem są już piksele, a nie wierzchołki, więc rozdzielczość, AA, shadery postprocess czy nawet shadowmapping - sam model nie ma wielkiego znaczenia dla fillrate.

 

Tylko wrzuci sobie do VBO wszystkie wierzchołki owego modelu po czym jak będzie chciał aby kółeczko się schowało to wywoła jeden drawcall z tym że wcześniej odpowiednie wierzchołki przemnoży przez odpowiednią macierz. Owszem utrudni mu to sprawę bo będzie musiał stworzyć czy to klase czy jakis system odpowiadający za animację szkieletową itd. Zamiast wywołać po prostu kolejnego drawcalla i narysować sobie kółeczko.

Nie ładnie używać terminów OpenGL (VBO) przy mówiąc do programisty DirectX (tam po prostu jest VB) ;p. Poza tym nie do końca tak łatwo możesz sobie połączyć wszystko, bo jeśli siatka jest w osobnych obiektach to zapewne i tekstur jest kilka - więc musisz dodatkowo dodać kolejne atrybuty dla siatki z indeksami i przesyłać do GPU tablice tekstur, co też nie jest takie proste na sprzęcie Dx9, bo np. w OpenGL Texture arrays pojawiły się w wersji 3.0 na sprzęcie Dx10+. Dodatkowo to z tym morzeniem przez macierz transformacji, żeby coś ukryć jest trochę bez sensu - lepiej po prostu wtedy rozwalić rysowanie na 2 drawcalle za pomocą glDrawRangeElements.

 

Idźmy dalej, weźmy drzewo, weźmy trawę, chcemy to animować, owszem możemy użyć osobnych drawcalli do każdej gałęzi czy do każdej kępki trawy, ale jeżeli wiemy że nie jest to dobry pomysł to będziemy używać pojedynczych drawcali i będziemy używać dynamicznego VBO.

Po pierwsze dynamiczne VBO to zło - robi Ci z VBO zwykłe stare VA, i co klatkę musiałbyś mapować dane, modyfikować i przesyłać do karty tonę wierzchołków. Dla trawy lepiej przesyłać punkty, robić bilbordy w GS, a animacje obliczać na GPU z np. wektora wiatru + tekstury szumu lub w jakiś inny sposób (jak np. w Fifa gdzie jest po prostu robione kika shelli boiska w GS i powstaje ładny shader futra udający trawe ;p)... dla całej reszty animacja szkieletowa na GPU.

 

Wracając do nieszczęsnych DrawCalli.. Jeżeli się całkiem w to wgłębić to masz częściowo rację, np. VBO jest tworem stosunkowo nowym, a zanim wszedł do użycia to w zasadzie jeżeli chciało się mieć jakiś obiekt animowany (czy to postać czy to robocik z siłowniczkami i innymi szpejami) to DrawCalle było ciężko wepchnąc do jednego.

VBO nowe? Przecierz to jest staroć. W standardzie OpenGL 1.5 od 2003 roku, a wcześniej jeszcze jako rozszerzenie funkcjonowały. W tej chwili masz nowości w postacji VAO (tablica z kilkoma VBO rysowana jednym drawcallem (ale jeszcze sterowniki są słabe i jest dzięki temu spadek wydajności zamiast wzrostu)), UBO czy Bindless Graphics od Nvidii (tylko u nich puki co jako rozszerzenie OpenGL http://developer.nvidia.com/content/bindless-graphics).

Nie wiem co w tym trudnego przed VBO - wrzucić wszystko do jednej tablicy/listy wyświetlania i zrobić jeden Draw Call (VA działają jak VBO dynamiczne, a listy wyświetlania są szybsze)?

 

Jak? No w bardzo prosty sposób, po prostu dodać informację do każdego wierzchołka w tablicy pod którą kość podlega lub pod którą macierz(w zasadzie to to samo :)), w przebiegu pętli pomnożyć każdy wierzchołek przez macierz która się do niego odnosi po czym całą tablicę wyświetlić w jednym drawcallu.

Ja wiem, że można nie lubić przesyłać danych na kartę graficzną, ale żeby tak od razu zabijać procesor ;p?

Przy dużej liczbie animowanych obiektów to zabije procesor (bo przemnorzenie milionów wierzchołków przez macierze (każdy przez kilka macierzy) to dla procka nie jest sekunda roboty ;p).

W dzisiejszych grach animacja szkieletowa jest robiona na CPU, ale przemnażanie siatki odbywa się już na GPU. Po prostu dodajesz do siatki dwa nowe atrybuty vec4 i jeden to 4x kości wpływające na wierzchołek, drugi to wagi dla tych kości. Macierze transformacji kości obliczasz na CPU dla danej klatki (i masz np. kilkanaście macierzy 4x4 lub 3x3 jeśli chcesz mieć tylko rotacje) - te macierze przesyłasz jako Uniform do karty graficznej, a przemarzaniem wierzchołków przez kości zajmujesz się już w VS (ofc cała siatka jest przesyłana raz bo wystarczy statyczne VBO, bo siatka zmienia się dopiero na karcie, a nie na CPU).

 

 

Jezeli DrawCallem ,nazywacie wywolanie metody Draw() z klasy omawianego Modelu ,to nie wiem w czym problem skoro istnieje w C# cos takiego jak petla foreach ,ktora wywola sobie tyle razy metode Draw() ile elementow bedzie zawierala kolekcja klasy modelu na ktorej bedziemy wkonywac petle.

Nie - chodzi o wywołanie metody rysującej w Api (np DirectX/OpenGL), która przygotowuje dane i przesyła do command buffora - DrawCalle zabijają procek, bo funkcje rysujące mają spory narzut w Dx (w OpenGL jest znacznie mniejszy narzut, w Dx9 jest większy, ale dopuszczalny, w Dx10 tak im się rozrosły funkcje, że ilość DrawCalli dla tego Api jest kluczowa, a w Dx11 starają się naprawić problem z Dx10 i jest możliwość wielowątkowego przetwarzania drawcalli i dostarczania do command buffora (przez co jest mniej wrażliwy na DC, bo podczas gdy jeden rdzeń czeka na powrót do kodu z DC, inny już robi kolejnego DC)).

Pętle nic tu nie zmieniają - w draw callach chodzi o czas jaki procesor spędzi w metodzie Draw, a spędzi go mniej jeśli wykona się tylko raz, niż jeśli w pętli po kolei wykonasz np. 40x razy. Metoda Draw którą ty wykonujesz na obiekcie to tylko interface, a ile jest podczas wywołania takiej metody faktycznych DrawCalli dowiesz się tylko czytając implementacji klasy (bo z Twoich słów wynika, że używasz jakiejś gotowej implementacji FBX dla .NET i nie masz bezpośredniego wpływu na DC)

 

 

A moj problem tytulowy zostal rozwiazany polegal na tym ze modele nie byly lowpoly a dokladnie to posiadaly za duza ilosc vertexow ,po znalezneiniu wlascwych gotowych modeli lowpoly z texturami i wyeksportowaniu i podmianie ich ,cala aplikacja dostala niesamowitego kopa nawet na dychawym sprzecie mobilnym z architektura Arm.

Sprzęt mobilny wcale nie jest taki zły i wiele procków mobilnych pozwala na rendering około 40 milionów polygonów na sekundę (co przy FPS 30 daje 1.3 MPoly na klatkę co jest niezłym osiągnięciem) - ofc jeśli się optymalnie wykorzysta sprzęt i nie będzie się nadużywać DrawCalli (co nawet przy dużych staraniach nie jest łatwe).

 

Osobiscie wydaje mi się ze jednak najwieksza wplyw na wydajnosc ma wlasnie skomplikowanie wykonania modelu przez modelujacego ,tzn przykladowo Ja majac slabe pojecie o modelowaniu gdybym chcial zrobic podobnie wygladajace lowpoly sam musialbym przy moim stadium zaawansowania uzyc kilkakrotnie wiecej wierzcholkow niz autor moich modeli aby oteksturowany model wygladal rownie atrakcyjnie

Największy wpływ na mobilne gpu mają operację na teksturach - przez co za wielu efektów postprocess (DoF/HDR/SSAO/Deferred shading/AA/MB/... i innych, które zabiją fillrate) nie użyjesz.

[JacekCichy]

Sprostuje tylko kilka rzeczy Skoti :)

 

A mianowicie:

- mówiąc że VBO jest dosyć nowe miałem na myśli że zostało dołączone do OpenGL w wersji 3.0 (już nie jako rozszerzenie) ale to kwestia sporna jak kto postrzega czas więc myślę że nie ma co dyskutować (tak jak z gustami :))

- to że trawę czy ludka lepiej animować poprzez VertexShader (VS) to jest jak najbardziej oczywiste :) Ja w swoich rozważaniach zatrzymałem się epokę wcześniej (pominąłem operacje na shaderach :)) ale w 100% masz rację, ich użycie jest tak powszechne aktualnie że to głupota z mojej strony :)

- Co do rzekomej lepszej wydajności DisplayList się nie zgodzę, z moich testów wynikało że oba są tak samo szybkie natomiast jak podają legendy VBO powinno być dużo szybsze. Skąd te legendy? Ano najprawdopodobniej driver karty optymalizuje displaylisty i przetwarza je na VBO :)

- To że VA działa jak VBO to też wiadomo natomiast VA jest wolniejsze od VBO :) stąd pisałem o trudnościach bo miałem na myśli wydajność a nie że się nie dało zrobić :)

- Poza tym dobrze że włączyłeś się do dyskusji, bo to zawsze powiew świeżości :) o UBO i VAO nie słyszałem jeszcze wogóle więc fajnie że o tym wspomniałeś to sobie zaraz poczytam :)

[Skoti]

- mówiąc że VBO jest dosyć nowe miałem na myśli że zostało dołączone do OpenGL w wersji 3.0 (już nie jako rozszerzenie) ale to kwestia sporna jak kto postrzega czas więc myślę że nie ma co dyskutować (tak jak z gustami :))

Vertex Buffer Objects (VBO) są w OpenGL Core od 1.5 (2003 - już jako nie rozszerzenie, a część specyfikacji) - rozszerzeniem VBO było, ale przed OpenGL 1.5. Teraz VBO to dalej świetne rozwiązanie (chociażby (pomijając względy wydajnościowe) ze względu na powszechność i dostępność od telefonów z OpenGL ES 1.0, 1.1, 2.0 przez OpenGL 1.5+ na PC, po WebGL w grafice 3d w przeglądarkach), dopóki bindless graphics nie będzie tylko rozszerzeniem jednego producenta, ale nowinką to tego nazwać nie można. Co do wersji 3.0 to od tej wersji w specyfikacji mamy VAO (w OpenGL 2.1 jest jako rozszerzenie), a w OpenGL 3.1 mamy UBO (jako rozszerzenie od 2.1). W 3.x też jeszcze jedna fajna rzecz doszła - wywalenie wszystkiego co nie jest związane z VBO (bezpośrednie dostarczanie wierzchołków, czy displacelisty) co ujednoliciło trochę tą sprawę (zostało tylko VA, które jest wykorzystywane przy VBO, które znowu jest wykorzystywane przy VAO... ;p).

 

- Co do rzekomej lepszej wydajności DisplayList się nie zgodzę, z moich testów wynikało że oba są tak samo szybkie natomiast jak podają legendy VBO powinno być dużo szybsze. Skąd te legendy? Ano najprawdopodobniej driver karty optymalizuje displaylisty i przetwarza je na VBO :)

To już zależy od tego na jakiej karcie testowałeś i od tego jak displayliste optymalizowały sterowniki - w najgorszym wypadku powinny być tak wolne jak VA (dynamiczne VBO).

 

natomiast VA jest wolniejsze od VBO :)

W teorii tak, w praktyce dynamiczne VBO działają tak samo wolno jak VA (przez dynamiczne mówię o streamach, bo nie widzę wielkiego zastosowania dla VBO dynamicznych (czyli aktualizowanych raz na N klatek, a nie co klatkę (stosuje się jeszcze, chociaż jest to rzadkość np. do systemów cząsteczkowych) lub statyczne z animacja szkieletową).

Ogólnie dziś mało kto robi VBO dynamiczne lub stream, bo po co tracić czas CPU i przesyłać dane skoro, na karcie graficznej będzie szybciej i nie trzeba przesyłać prawie nic.

Edytowane 26 Czerwiec 2011 przez Skoti

[plutko]

Ilość wierzchołków i poligonów jest ściśle od siebie zależna i bez sensu jest pisać jako osobne rzeczy...

Tak nie jest (przynajmniej nie dla grafika). Ilosc vertexow zalezy od smoothing grup, podziale UV-ki, przydzielonych materialow. Obiekty o tej samej ilosci poligonow moga miec do 3 raz wiecej wierzcholkow.

Jeden koles u nas lockowal normale na niezsmoothowanym obiektcie, potem je usrednial skryptem. Ale w eksporcie te usrednione traktowane byly jako osobne wierzcholki (poprzez zlockowanie). I byl zonk, iles obiektow musial poprawiac.

[Skoti]

Tak nie jest (przynajmniej nie dla grafika). Ilosc vertexow zalezy od smoothing grup, podziale UV-ki, przydzielonych materialow. Obiekty o tej samej ilosci poligonow moga miec do 3 raz wiecej wierzcholkow.

Jeden koles u nas lockowal normale na niezsmoothowanym obiektcie, potem je usrednial skryptem. Ale w eksporcie te usrednione traktowane byly jako osobne wierzcholki (poprzez zlockowanie). I byl zonk, iles obiektow musial poprawiac.

Myślę, ze kazdy grafik robiacy modele do gamedev wie, ze nie sa wazne poly/wierzcholki jakie mu pokazuje max, tylko to co dostaje karta, a ta przy rasteryzacji przetwarza n poly po 3 wierzcholki - co najwyzej mozna zaoszczedzic na przesyle danych (przy statychnych vbo w praktyce zyskujesz czas ladowania modeli tylko) i wysylać mniej wiercholków, jesli na kilku face wierzcholek ma takie same normalne, uv, pozycje... ale to nie zmienia tego, ze karta bedzie przetwarzać n triangle i 3*n vertexow - po prostu zaleznie od tego na ilu poly bedziesz mial dokladnie takie same wiercholki, tyle zaoszczedzisz na przesyle.

[plutko]

Programista moze, tak, ale na pewno nie kazdy grafik to wie ;)

Poczatkujacy grafik nie wie nic, potem wie malo, jak sie czegos nauczy to zmienia sie technologia i cos co bylo zakazane, okazuje sie byc pozadane ;) Uczcie nas!! ;)

 

Po drugie nie jest problemem przesyl, ale samo zajecie pamieci. Moze na PC czy w silnikach z porzadnym streamingiem ma to mniejsze znaczenie, ale dla konsol z ukochanym Wii czele juz tak. Jesli w paczce, o okreslonym rozmiarze marnuje sie 20% miejsca przewidzianego na meshe, to juz jest zle. Bo kilka np. tekstur bedzie musialo zostac scietych.

[velendil]

Programista moze, tak, ale na pewno nie kazdy grafik to wie ;)

 

Wyjasnij wiecej, pociagnij temat, z checią poczytam i czegoś się nauczę : )

[plutko]

znaczy, ze quoi?

[Pussik]

(W Unity znajdziesz to w: Component>Mesh>Merge Children)

 

Taka opcja jest w 3ds maxie?

 

 

Odnoszac się do wątku o wydajności w grach. Interesują mnie dwie kwestie...zdaję sobię też sprawę, że mogą one zależeć od silnika, ale cóż.

 

Otóż, na ile nagatywny wydajnościowo wpływ ma używanie 2-sided poligons (odhaczane jako opcja w shaderze w moim przypadku) dla obiektów?

 

Drugie pytanie to.. otwarte bryły modeli. Np box, który jest słupkiem, z wywalonymi ściankami od spodu, które nie są widoczne. Czy silniki musza jakieś dodatkowe (jeżeli tak, to na ile skomplikowane) operacje wykonywac, jeżeli bryła nie jest zamknięta?

 

Myślę, ze kazdy grafik robiacy modele do gamedev wie, ze nie sa wazne poly/wierzcholki jakie mu pokazuje max, tylko to co dostaje karta, a ta przy rasteryzacji przetwarza n poly po 3 wierzcholki - co najwyzej mozna zaoszczedzic na przesyle danych (przy statychnych vbo w praktyce zyskujesz czas ladowania modeli tylko) i wysylać mniej wiercholków, jesli na kilku face wierzcholek ma takie same normalne, uv, pozycje... ale to nie zmienia tego, ze karta bedzie przetwarzać n triangle i 3*n vertexow - po prostu zaleznie od tego na ilu poly bedziesz mial dokladnie takie same wiercholki, tyle zaoszczedzisz na przesyle.

 

Nie całkiem jasno napisałeś, ale mniejsza z tym. Interesuje mnie, na ile faktycznie istotne z punktu tworzenia assetów, jest pilnowanie smooth group, w związku ze zwiększeniem się ilości vertexów do policzenia.

Edytowane 16 Lipiec 2011 przez Pussik

[plutko]

Pussik:

ad1) Kiedy uzywasz 2-sided dla np. nieprzezroczystego boxa, to te scianki z tylu zostana wyrysowane. Wiekszosc silniku nie stosuje sortingu na poziomie pojedynczego obiektu. Czyli tracisz na wydajnosci.

 

ad2) Nie ma powodu, zeby te scianki tam byly. To tylko strata pamieci i wydajnosci. Otwarte bryly sa ok. Jedyny powod, zeby zamykac, to to, ze komus moze wpasc do glowy przewrocenie Twojego boxa. Wiec pozorna oszczednosc, moze sie zamienic w przerabianie asseta.

 

ad3) o ile dobrze rozumiem Skotiego, nie ma to wplywu na wydajnosc (renderowanie pojedynczej klatki). Ma za to na ilosc zuzytej pamieci, w ktorej obiekt przechowujesz.

[Pussik]

Thx za odpowiedzi.

 

Nawiązując jeszcze do 2-sided. Osobiście uważam, że trancluded objects w grach jest MAŁO. Akurat pisząc o 2-sided faces, miałem na mysli używanie ich do zwykłych obiektów, jak daszki, płotki... obiektów z co najwyżej alphatestem czy alpha blendingiem, ale nie półprzezroczystych jako takich.

[Skoti]

Otóż, na ile nagatywny wydajnościowo wpływ ma używanie 2-sided poligons (odhaczane jako opcja w shaderze w moim przypadku) dla obiektów?

Będzie się rysował 2x dłużej (2-sided to po prostu 2 osobne wielokąty, rysowane przez kartę zamiast jednego).

 

Drugie pytanie to.. otwarte bryły modeli. Np box, który jest słupkiem, z wywalonymi ściankami od spodu, które nie są widoczne. Czy silniki musza jakieś dodatkowe (jeżeli tak, to na ile skomplikowane) operacje wykonywac, jeżeli bryła nie jest zamknięta?

Dla karty graficznej i silników nie istnieje coś takiego jak otwarta bryła czy zamknięta - są po prostu trójkąty, a jak one są poskładane to już nie jest ważne.

 

Nie całkiem jasno napisałeś, ale mniejsza z tym. Interesuje mnie, na ile faktycznie istotne z punktu tworzenia assetów, jest pilnowanie smooth group, w związku ze zwiększeniem się ilości vertexów do policzenia.

Praktycznie nieistotne, nawet ze względu na zajmowaną pamięć (a na to praktycznie jedynie ma wpływ), bo siatka zajmuje względnie mało pamięci. Załóżmy, bardzo pesymistyczny skrajny przypadek - na scenie masz 1 milion tri przy założeniu, że nie masz, żadnego powtażalnego obiektu (instancingu brak), każdy tri ma 3 wierzchołki, gdzie żaden wierzchołek się nie pokrywa z innym, więc każdy wierzchołek zajmuje po 32 bajty (3x norm, 3x pos, 2x uv pomnorzone przez 4 bajty na liczbę zmiennoprzecinkową) co daje nam 91 MB na siatkę, przy ekstremalnych warunkach (czyli cała siatka na całą scenę, bez instancingu, przy bardzo pesymistycznych założeniach - tyle co kilka tekstur (bo na karcie nie mają rozmiaru jak JPG, bo są trzymane bez kompresji (tak jak w BMP)), i dużo mniej niż zjedzą same efekty postprocess). A spokojnie możesz założyć, że z 10% sceny to instancing, a kolejne 50% wierzchołków będzie jednak zaoszczędzone, bo będą miały takie same wartości, to ostatecznie siatka będzie zajmować śmiesznie mało miejsca.

 

Nawiązując jeszcze do 2-sided. Osobiście uważam, że trancluded objects w grach jest MAŁO. Akurat pisząc o 2-sided faces, miałem na mysli używanie ich do zwykłych obiektów, jak daszki, płotki... obiektów z co najwyżej alphatestem czy alpha blendingiem, ale nie półprzezroczystych jako takich.

Jest ich mało, bo są problematyczne - problemem jest sortowanie obiektów (im więcej tym dłużej się je sortuje i tym gorsza wydajność), problemem jest renderowanie półprzezroczystych obiektów gdzie widać ścianki obiektu przez inne ścianki tego samego obiektu (bo każdy trójkąt musi być posortowany - w przeciwnym wypadku zrobi się sieczka - stosuje się tu dual depth peeling (wolne), czy weighted average (szybki, ale niezbyt fajny, wizualnie bo nie jesteś w stanie, określić co jest przed/za)), a na końcu problemem jest chęć wykorzystania wielu świateł w oświetleniu scen (deferred shading czyli liczenie oświetlenia postprocess - dlatego nie można obliczyć oświetlenia obiektów widzianych przez przezroczyste obiekty, bo nie ma dla nich danych (pozycji, normalnych, itp, a są tylko dla powierzchni obiektu przezroczystego)). Przezroczystych obiektów w grach jest mało, bo jest z nimi wiele kłopotów i wystrzega się ich jak ognia ;p.

[Pussik]

Dzieki za wyjasnienie tych kilku nurtujący mnie kwestii. :]

[PAINbringer]

(...)na ile faktycznie istotne z punktu tworzenia assetów, jest pilnowanie smooth group, w związku ze zwiększeniem się ilości vertexów do policzenia.

(...) Praktycznie nieistotne, nawet ze względu na zajmowaną pamięć (a na to praktycznie jedynie ma wpływ), bo siatka zajmuje względnie mało pamięci. Załóżmy, bardzo pesymistyczny skrajny przypadek - na scenie masz 1 milion tri przy założeniu, że nie masz, żadnego powtażalnego obiektu (instancingu brak), każdy tri ma 3 wierzchołki, gdzie żaden wierzchołek się nie pokrywa z innym, więc każdy wierzchołek zajmuje po 32 bajty (3x norm, 3x pos, 2x uv pomnorzone przez 4 bajty na liczbę zmiennoprzecinkową) co daje nam 91 MB na siatkę, przy ekstremalnych warunkach (czyli cała siatka na całą scenę, bez instancingu, przy bardzo pesymistycznych założeniach - tyle co kilka tekstur (bo na karcie nie mają rozmiaru jak JPG, bo są trzymane bez kompresji (tak jak w BMP)), i dużo mniej niż zjedzą same efekty postprocess). A spokojnie możesz założyć, że z 10% sceny to instancing, a kolejne 50% wierzchołków będzie jednak zaoszczędzone, bo będą miały takie same wartości, to ostatecznie siatka będzie zajmować śmiesznie mało miejsca. (...)

 

Muszę przyznać, że nie wierzyłem w to co napisałeś tu Skoti. Dlatego postanowiłem to po prostu sprawdzić. Rezultaty zdają się jedynie potwierdzać to co napisałeś - hard edge mają znikomy wpływ na FPSy.

(A od siebie (dla kolegów grafików) jeszcze dodam:

Hard edge może i mają mały wpływ na fps, ale za to ogromny na naturalny wygląd obiektów. Także robienie ładnych, gładkich edge'y - nadal należy do naszych obowiązków)

 

DETAILS:

W sytuacji którą zbudowałem, przy 5M trójkątów (co jest dzisiaj nadal ekstremalną sytuacją w grach), było to jedynie 0,5-2ms różnicy na CPU

Scena do testu była zbudowana tak, że było na niej 102 zamknięte meshe (1shell, 49k152tri) i kamera, nic więcej (żadnych świateł, cieni, post-processów etc).

Co ważne, gładkie meshe miały w sumie 2585700 vertexów, a te z samymi hard edge'ami miały w tym przypadku 3589380 vertexów - o 38,8% więcej niż gładkie meshe (*oczywiście ten procent różni się w zależności od budowy mesha)

 

[PS: Jeżeli znacie sytuację, w której wyniki mogą być inne (a na pewno takie są) - napiszcie]

 

Pozdrawiam

 

 

EDIT:

Wskaźnik ilości animacji pomińcie, nie ma tam ani jednej.

Edytowane 19 Lipiec 2011 przez PAINbringer

[Pussik]

Czemu na screenie parametry dotyczące textur się różnią?

 

Btw, nie wiem czy taki znikomy.. 9fps. :)

[PAINbringer]

Czemu na screenie parametry dotyczące textur się różnią?

Tak, na screenie widać również, że rozdzielczość okna się zmieniła. A deffered rendering polega na m.in. tym, że wszystkie informacje o frame'ie są spłaszczane do postaci textury.

(hmm technical artist powinien chyba o tym już wiedzieć?

 

Btw, nie wiem czy taki znikomy.. 9fps. :)

Sytuacja, w której na ekranie gry masz 5.000.000 trójkątów i każdy z nich nie jest gładko cieniowany z którymś z sąsiadów jest, co najmniej, mało prawdopodobna.

Jeżeli w ekstremalnej sytuacji jest to kilka fps'ów - to w sytuacji produkcyjnej wpływ tych dodatkowych vertexów, spowodowanych kilkoma modelami bez SG, prawdopodobnie nie powinien przekraczać dziesiątych części FPSa.

[plutko]

Zapodaj jeszcze rozmiar meshy w pamieci, prosze.

[Skoti]

Muszę przyznać, że nie wierzyłem w to co napisałeś tu Skoti. Dlatego postanowiłem to po prostu sprawdzić. Rezultaty zdają się jedynie potwierdzać to co napisałeś - hard edge mają znikomy wpływ na FPSy.

A od siebie (dla kolegów grafików) jeszcze dodam:

Hard edge może i mają mały wpływ na fps, ale za to ogromny na naturalny wygląd obiektów. Także robienie ładnych, gładkich edge'y - nadal należy do naszych obowiązków.

Dziwne są różnice w tym porównaniu (animacje, ilość vbo, rozdzielczość), ale najdziwniejsze jest wykorzystanie pamięci karty graficznej (VRAM - Video RAM), bo są to za niskie wartości i ledwo pokrywają wielkość tekstur - oznacza to, że nie masz statycznego VBO z danymi na karcie, tylko przesyłane są co klatkę (co tłumaczy niską wydajność (bez żadnych shaderów postprocess jest to śmieszna wydajność), oraz duże różnice w wydajności (tak to są duże, bo nie powinno być żadnej różnicy)).

 

Co do ogromnego wpływu na naturalny wygląd to zrób ściany budynku bez hard edge to zobaczysz jak nienaturalne są softedge - ogólnie radzę po prostu używać takich normalnych jakie pasują modelowi, a nie przejmować się wielkością zajmowaną w pamięci (bo różnicy w wydajności nie ma).

[PAINbringer]

@ Skoti

Wskaźnik animacji można olać, bo nie ma ich tam tak na prawdę. Ilość vbo - sam nie wiem... . Rozdzielczość zmieniłem przez przypadek, my fault.

Każdy obiekt ma 50k bo Unity ma gdzieś (chyba) hard-kodowane ograniczenie do 65k per mesh. Z tego samego powodu nie da się połączyć te meshe w jeden. Z tego co rozumiem, to chyba to tłumaczyłoby brak statycznego VBO (?)

Jak sądzisz - w silniku coś jest niezoptymalizowane czy ja tam coś źle ustawiłem, że jest taka bardzo słaba, jak pieszesz, wydajność?

 

Hard-edge są przede wszystkim bardzo problematyczne - AA powstał przecież z tego powodu.

I wbrew przeciwnie - da się zrobić ładne ściany/brzegi budynków z soft-edgami. Tylko potrzebne są do tego dodatkowe edge tzn. kontrolne/blokujące i zachowana ciągłość UV. Dzięki temu krawędź ściany jest odpowiednio "twarda", ale z miękkim gradientem światłocienia. Metoda ta jest już całkiem stara, także to nic niesprawdzonego

Edytowane 23 Lipiec 2011 przez PAINbringer

[Skoti]

@ Skoti

Wskaźnik animacji można olać, bo nie ma ich tam tak na prawdę. Ilość vbo - sam nie wiem... . Rozdzielczość zmieniłem przez przypadek, my fault.

Każdy obiekt ma 50k bo Unity ma gdzieś (chyba) hard-kodowane ograniczenie do 65k per mesh. Z tego samego powodu nie da się połączyć te meshe w jeden. Z tego co rozumiem, to chyba to tłumaczyłoby brak statycznego VBO (?)

Jak sądzisz - w silniku coś jest niezoptymalizowane czy ja tam coś źle ustawiłem, że jest taka bardzo słaba, jak pieszesz, wydajność?

Wskaźnik animacji nie można olać, bo jeśli silnik wczytał to jako plik z animacją to może mieć to znaczny wpływ - w najlepszym wypadku dorzucił do renderingu dane w wielkości tego co zajmują pozycje + normalne + uv (indexy i wagi dla kości jeśli w silniku jest ograniczenie dla grafików - max 4x kości wpływające na wierzchołek)... w gorszym przypadku uznał to za animacje morph, zamiast szkieletową i aktualizuje wierzchołki i przesyła całą siatkę co klatkę (wymuszenie VBO w trybie strumienia).

Nie znam tego silnika, i dziwne to ograniczenie (może takie tylko w wersji free?), ale nie powinno mieć ono wpływu na rodzaj VBO. Nie powiem Ci też po której stronie leży wina, bo nie znam silnika, ani tego co zrobiłeś (jednak sądząc po dziwnych różnicach na screenach, obstawiałbym winę użytkownika).

 

Hard-edge są przede wszystkim bardzo problematyczne - AA powstał przecież z tego powodu.

Tu jestem w szoku, bo pokazałeś, że nie masz pojęcia albo czym są hard-edge, albo czym jest AA (anti-aliasing)... jedno z drugim nie ma zupełnie nic wspólnego a problem aliasingu dotyczy renderingu zarówno soft jak i hard (a nawet grafiki 2d). Anti-aliasing to metody (nie tylko w grafice, ale też np. dźwięku i innych dziedzinach), które pozwalają radzić sobie z niskim próbkowaniem sygnału analogowego (np. ilość próbek na sekundę w dźwięku (analogową falę dzwiękową trzeba przedstawiać za pomocą próbek - w tej chwili miała fala wartość x, a 1/200 sec później miała wartość y (co się działo pomiędzy nie ma nikt pojęcia)), czy ilość pikseli na ekranie (piksele to zbiór prostokątów za pomocą których trzeba przedstawić dane, które niekoniecznie do pikseli pasują - bo np. pół piksela powinno być białe, a pół czarne (jednak w miejscu próbkowania było czarne i cały prostokąt jest czarny))).

W grafice komputerowej jest problem z tym, że piksel może być jednokolorowy i powstają schody próbkowania:

AA jest po to, żeby wyeliminować te schody (poprzez np. renderowanie do 4x większego obrazu i skalowanie w dół (supersampling - dzięki temu na faktyczny jeden piksel jest 4 próbki), lub renderowane jest z wielokrotnym próbkowaniem (piksel przechowuje wartości kilku/kilkunastu próbek, i później jest to uśredniane (MSAA))).

 

I wbrew przeciwnie - da się zrobić ładne ściany/brzegi budynków z soft-edgami. Tylko potrzebne są do tego dodatkowe edge tzn. kontrolne/blokujące i zachowana ciągłość UV. Dzięki temu krawędź ściany jest odpowiednio "twarda", ale z miękkim gradientem światłocienia. Metoda ta jest już całkiem stara, także to nic niesprawdzonego

Poza tym, że nie ma to wielkiego sensu poza zmniejszeniem wydajności (znacznie więcej trójkątów (ściana z 2 tri robi się ścianą z 18 tri)) to spoko pomysł ;p

[Pussik]

 

Poza tym, że nie ma to wielkiego sensu poza zmniejszeniem wydajności (znacznie więcej trójkątów (ściana z 2 tri robi się ścianą z 18 tri)) to spoko pomysł ;p

 

Nie no, czasem chamfery się stosuje, aby mieć fajny płynny kant, bo to jednak podnosi jakość. Ale jakbyśmy mieli to wszędzie stosować, to czas modelingu by wzrósł, nie mówiąc już o polycount'cie.

[Skoti]

Nie no, czasem chamfery się stosuje, aby mieć fajny płynny kant, bo to jednak podnosi jakość. Ale jakbyśmy mieli to wszędzie stosować, to czas modelingu by wzrósł, nie mówiąc już o polycount'cie.

Czasami jest to wskazane, a czasami wręcz przeciwnie - wszystko zależy od modelu, i często jest to uzasadnione względami wizualnymi (ale bywa, że wizualnie lepiej wygląda hard).