PAINbringer

Widzę że działa to jedynie nielicznym szczęśliwcom

@ 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

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ć? 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.

(...) 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.

Nie mam najmniejszych wątpliwości, że od strony graficznej na Unity da się już zrobić o wiele ładniejszą grę niż BlackSite. Mówię to nie bez pokrycia, bo robię w tym kierunku rzetelny research. Dlaczego takowy tytuł jeszcze nie powstał? To tylko kwestia czasu, ale powody są przynajmniej cztery: Pierwszy to taki, że nikt nie chce ryzykować z produkcją czegoś większego na niesprawdzonej pod tym względem platformie. Drugi powód jest taki, iż teamy indie nie zapoczątkują tego same, bo dla nich kwestia braku modułu humanoidalnego AI (nota bene już został zapowiedziany) jest śmiertelną przeszkodą. Trzeci: Brak części wydajnych i high-endowych narzędzi (navmeshe, kod sieciowy, porządny fx editor, terrain tool). Ogólnie wiele narzędzi w tym momencie trzeba pisać sobie samemu = co zwiększa ryzyko i koszty produkcji Czwarty to taki, że Unreal już się sprawdził > 100 razy. Więc żeby wybrać Unity zamiast niego musisz robić to dla jakiegoś konretnego powodu... Jeżeli go nie masz, to po prostu sięgasz po Unreala W każdym bądź razie, według mnie, gdy w Unity w końcu pojawi się dobre sandboxowe AI, to na tym silniku zaczną powstawać mini-wersje gry typu BlackSite jedna po drugiej

zonk, trochę się spóźnili z tą decyzją IMO

Jak na niecałe dwa lata nauki to nie ma dramatu

Żenująca to jest płytka interpretacja. Chyba nie rozumiesz kolegi Valerego. To nie jest kwestia wiary a stan rzeczy, że wiekszość firm game developerskich na całym świecie nie istnieje dłużej niż 5 lat (google it). Polska tu nie jest magicznym wyjątkiem Co się z nimi dzieje? Są zamykane wraz z ich projektami, a na ich miejscu rodzą sie nowe, często lepiej działające. To naturalna, często smutna, ale w dłuższej skali czasu - w wielu przypadkach uzdrawiająca kolej rzeczy... Niech to będzie jasne - wszyscy trzymamy kciuki za Afterfalla, dlaczego? Bo sukces Afterfalla ściągnie więcej kapitału do tej branży w Polsce, a to wszystkim wyjdzie na dobre. Lecz szczerze wątpię by dziecinne "trzymam kciuki" było czymś w tym momencie rozsądnym i pomocnym do powiedzenia Pozdrawiam EDIT: IMO "dziecinne" jest banalizowanie wartości powiedzenia czegoś szczerego

Chris, a może to jest właśnie konstruktywna krytyka ludzi? Ktoś kto by życzył Wam źle, jestem pewien, że właśnie napisałby iż wszystko wygląda dobrze i jest super Plutko wcale nie jest złośliwy, szczodrze przekazał obiegowe zdanie jakie ma teraz wiele osób wokół tego projektu Los developera jest zawsze srogi, jak jest dobrze - wszyscy są z tobą. Ale jak jest coś źle - nie można obwiniać innych że im się nie podoba i zarzucać że złorzeczą. To po prostu nieprofesjonalne. IMO lepiej brać wszystkie baty na siebie, wyciągać z wszystkiego wnioski a źródeł problemów najpierw szukać u siebie. Inaczej nadal nikt nie będzie traktował Was poważnie, a już na pewno - nie ma co liczyć, że coś się poprawi. Peace

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

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. 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 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 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 nie jestem programistą u_u' 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

@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

O tak, do gry o trudnym życiu termita w tartaku - idealne

Czekam na model choinki z ZBrusha... srsly lol

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