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

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.

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

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

Heh, dobra żenująca rada, ...;] Ta, złóżcie wszyscy wypowiedzenie bo NG wali w ch... :O (...)

Ż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

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

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

@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

Super mega czad! Czekam na wersje Android

Pozdr

Jak zobaczyłem to po raz pierwszy to myślałem, że to jakiś przeciętny prerenderowany CG. Ale jak na RT to nieźle

PS: Renderer RT a Engine (z wszystkimi narzędziami) to dwie kolosalnie różne rzeczy. Rendererów jest (literelnie) 100 razy więcej na rynku, bo narzędzia wymagają kosztownego i długotrwałego R&D

Czujne!

Aż trudno mi uwierzyć że tylko ok 1h. Więc wielki szacun za należycie wyrobiony warsztat kompozycji brył i przyjemnego koloru. Bardzo mi się podobają

PS: SBT77 - wypracowanie rodem z liceum... ;) Pani byłaby teraz dumna

Pozdr.

hater

Dawaj krótkiego making of'a :) Sam nie robię gier flash, ale bardzo chętnie bym się dowiedział jakie były Twoje z tym doświadczenia, wnioski i wyzwania stojące przed taką produkcją (zwłaszca w tak dużym zespole ;))

Cieszy mnie fakt, że w końcu na tym forum poza wątkami "zrobiłem miecz do gry" pojawia się wątek "zrobiłem grę" - to na prawdę orzeźwiające (!)

Prosta ale za to bardzo przyjemna gra, trzymam kciuki za dalszy development

Pozdrawiam

http://www.develop-online.net/news/37192/GDC11-Unity-PSN-title-unveiled

"The first PSN game to be authored on the Unity platform has been revealed at GDC in San Francisco."

O tak. Jak ktoś znajdzie newsa kiedy ma ruszyć obsługa PSN dla Unity na szerszą skalę, niech podzieli się newsem

Pozdrawiam

http://www.hutonggames.com/playmaker.html

"Kismet" dla środowiska Unity. Dla tych co go jeszcze nie sprawdzili - polecam.

Aby zrobić pod nim proste eventy nie potrzeba nawet znać sie na programowaniu (otwieranie się drzwi, uruchamianie animacji, podmiana materiałów, spawnowanie obiektów itd.) - świetny do prototypowania gry lub jakiejkolwiej aplikacji interaktywnej.

Lecz żeby zrobić bardziej skomplikowane rzeczy (np. prototyp systemu gry) - niestety już trzeba umieć programować. Nie mniej jednak tool jest warty zainstalowania.

Playmaker jest w fazie beta (darmowej), ale pełna ma być płatna.

@Chruper3d: Strzelam, że nie masz na scenie światła rzucającego Cienie

EDIT: Bez tego lighmapa się wyrenderuje, ale będzie płaska.

http://www.youtube.com/watch?v=gxvNGy5jUeA

Ktoś powinien przykleić to w dziale "Tutoriale" ;)

Unity 3 przede wszystkim jest dużo wolniejsze, to na pewno.