[WIP] Blokowisko [Pytania] od wizek do gier - podstawy

[Razer]

Mógłbym zacząć jak asdaq w tym poście.

Koniec babrania się i robienia stu rzeczy na raz STOP

Chcę pracować w Game Devie STOP

Wszystko co będę teraz niekomercyjnie robił ma służyć temu celowi STOP

Co chcę robić: Asset/Texture Artist, potem Enviroment Art STOP

Jemu w listopadzie stuknie 30-stka, mi 31 :) Przez lata robienia archvizek czegoś tam się nauczyłem, ale wiadomo że gameart to zupełnie inna para kaloszy. Dlatego zaczynając małymi krokami postanowiłem od razu zwrócić się do specjalistów aby ustrzec się "błędów początkującego".

 

Robię bloki. Blokowisko. Piękną polską wielką płytę. W Unity, bo tak :) Chcę zrobić "poziom" którego głównym elementem będzie niewielka przestrzeń pod jedną z klatek, cała reszta "osiedlowej panoramy" będzie tylko nieinteraktywnym tłem. I z tym tłem raczej problemów nie mam - proste bryły, proste tekstury. Nie wiem natomiast jak zabrać się za pierwszoplanowy budynek. Stworzyłem sobie dwie tekstury, jedną z tynkiem, drugą z oknami i stolarką.

 

 

Do tego zbudowałem kilka podstawowych elementów bloku - ściany z różnymi otworami, ramy i okna.

 

 

Z tego wszystkiego w maxie złożyłem sobie coś takiego, powielone kilka razy powinno wystarczyć:

 

 

I tutaj zaczynają się moje wątpliwości.

1) Czy takie podejście do sprawy (taka tekstura, budowanie z takich elementów) jest w ogóle dobrym podejściem?

2) Czy lepiej będzie zrobić cały blok w maxie i wyexportować jako jeden scalony obiekt (a raczej dwa, skoro mam dwie tekstury), czy exportować każdy element oddzielnie i składać je w Unity?

3) Brudy, zacieki, pęknięcia tynku itp. Jak robi się takie rzeczy - decalami już w Unity?

4) W Unity wszystkie obiekty są one-sided, jak sposób na doublesided jest lepszy - dołożenie geometrii czy załatwienie tego jakimś specjalnym shaderem?

 

Mam nadzieję że mi pomożecie, dzięki temu będę mieć jeszcze więcej pytań ;)

Edytowane 11 Październik 2013 przez Razer

[Dalamar]

Cześć,

 

to tak na szybko postaram się odpowiedzieć.

 

1) i 2) Jeśli chodzi o model, to wydajniej sprzętowo niż taka modularność się nie da. Wszystko jest na prostych instancjach, ale level designer Cię zabije, jak będzie musiał złożyć z tego blok, albo sobie złoży jedno piętro i je skopiuje i cała zabawa w nie wiadomo ile możliwości i tak będzie nie użyta. Produkcyjnie, póki to nie jest wielka firma, nikt nie ma czasu na zabawę w takie składanie. Ale to jest dobry nawyk, żeby myśleć o modularności. Generalnie lepiej by było się skupić np. na piętrach, czy segmentach ściany. Zauważ też, że jeśli zrobisz w taki sposób, to wszędzie zacznie Ci wychodzić tile na teksturach, bo to małe elementy powtarzane wiele razy na 1 bloku. Na segmencie można to bardziej rozróżnić.

Jeśli chodzi o teksturę, to choć to jest optymalne, to jednak lepiej mieć choćby ściany i okna osobno. Jeśli manipulujesz w jakikolwiek sposób teksturą w silniku, np potrzebujesz trochę ciemniejsze ściany, czy część z nich, żeby nie wgrywać kolejnej tekstury, to nie zrobisz tego na takiej jaką masz, bo zmienisz także okna. Oczywiście można to maskować w materiale, ale to więcej zabawy, a maski użyć do czego innego.

W UDK i każdym programie graficznym, możesz nakładać kilka materiałów na jeden obiekt, więc w Unity też musi się dać. Wtedy masz większy obiekt. Np. piętro, na który dajesz 2 materiały, powiedzmy ścian i okien. Wtedy po skopiowaniu piętra powyżej, możesz zmienić sam materiał okien, co da Ci różnorodność której potrzebujesz.

Z całym blokiem, to zależy. Jeśli to będzie budynek obok którego idziesz, to nie, ale na dalszym planie, to może być jeden prosty model z powtarzającą się teksturą.

 

3) Decalami i także na teksturze. Bazowe brudy itd, nie wyróżniające się dajesz na teksturze, żeby była po prostu ciekawsza, ale tak, żeby nie rzucał się w oczy tile. Duże zmiany, np graffiti na ścianie, uwalony kawałek tynku, to już decal.

 

4)Jak wcześniej w UDK i programach graficznych, możesz ustawić w materiale( shaderze) "two sided", ale to też zależy co potrzebujesz. Jak będzie się do budynku wchodzić, to robisz geometrię. Jak nie będzie się wchodzić, to nie potrzebujesz two sided, bo raczej go będziesz zamykał z każdej strony. W razie robienia dziury, to już też będzie potrzebna raczej geometria.

[Razer]

Dzięki za odpowiedź. Faktycznie muszę poczytać o kilku materiałach na jednym obiekcie, domyślałem się że w gamearcie też da się tak zrobić ale jeszcze nie wiem jak. Pomysł z budowaniem segmentów pięter i oddzielnych teksturach np dla samych okien też sprytny, już nawet wiem jak go dobrze wykorzystać.

 

Jeśli chodzi o two-sided to bardziej miałem na myśli takie elementy jak uliczny śmietnik (praktycznie zwykły box, blacha nie potrzebuje grubości) albo parapety (znowu cienka blacha).

[arev]

Kilka materiałów na obiekcie obsługiwane jest z marszu. Wystarczy, że w Maksie zdefiniujesz inne ID dla niektórych face'ów, a w Unity po wrzuceniu ich na scenę będziesz miał w MeshRendererze dwa sloty na materiał. Co do modularności - fajnie, ale lepiej chyba wypluwać jednego mesha z Maksa. W Unity jest wprawdzie narzędzie do merge'owania statycznych siatek, ale nie ruszali tego od dawna i kompletnie nie działa z lightmapami (tymi Unitowymi). Używając takich atlasów tekstur pamiętaj, że jeśli ustawisz ufałkę idealnie na granicy elementów, to w Unity wyjdzie lekkie zmieszanie koloru z sąsiadującym elementem (bilinear).

[legomir]

Pozwolę się dołączyć do pytań z wątków i zapytać:

 

1) i 2) Jeśli chodzi o model, to wydajniej sprzętowo niż taka modularność się nie da. Wszystko jest na prostych instancjach, ale level designer Cię zabije, jak będzie musiał złożyć z tego blok, albo sobie złoży jedno piętro i je skopiuje i cała zabawa w nie wiadomo ile możliwości i tak będzie nie użyta. Produkcyjnie, póki to nie jest wielka firma, nikt nie ma czasu na zabawę w takie składanie. Ale to jest dobry nawyk, żeby myśleć o modularności. Generalnie lepiej by było się skupić np. na piętrach, czy segmentach ściany. Zauważ też, że jeśli zrobisz w taki sposób, to wszędzie zacznie Ci wychodzić tile na teksturach, bo to małe elementy powtarzane wiele razy na 1 bloku. Na segmencie można to bardziej rozróżnić.

 

A co jeśli to model proceduralny i lvl desinger dostaje go wraz z wygodnym modelem suwaczków a definicja bryły trwa parę sek, są att randomizacji, proceduralne mapowanie, możliwość poustawianie sobie decali w programie etc.?

[Dalamar]

Świetne pytanie. Uświadomiłeś mnie, że myślę w wąskich kategoriach typów gier. Tworzę shootery, fanem jestem rpg i mmo, więc ja to jestem fanem wszystkiego customowego, widoczków, ciężkiego designu lokacji, co się sprowadza do ręcznej dłubaniny przy wszystkim. Ale racja, można sobie postawić bazę miasteczka także w shooterze, czy zrobić domki do rpg, to faktycznie załatwia sprawę modularności.

 

Wiesz może ile studiów z korzysta z takich rzeczy, albo do jakich gier, czy na jakie platformy? Tu już moja ciekawość się budzi.

 

Szczerze powiedziawszy takiego przypadku nie miałem w rękach, widziałem owszem, ale nie pod game dev, więc nawet nie brałem tego pod uwagę. No cóż za specjalistę to ja się nie uważam jeszcze, służę jedynie radą i wiedzą jaką posiadam, a Ty, poszerzyłeś mój horyzont :)

[legomir]

Nie wiem aczkolwiek to mnie bardzo interesuje z racji iż programów jakich używam. Wiem na pewno iż czegoś takiego używa Ea Canada, Naughty Dogs, Guerrilla Games i coś tam jeszcze. Moje zainteresowanie sprawą spowodował głównie ten artykuł: http://www.sidefx.com/index.php?option=com_content&task=view&id=2139&Itemid=68

 

Swoją drogą w meta danych można przemycić ścieżki do plików z teksturami bazowami i decalsami, jeśli duża ilość masek nie byłaby problemem to i maski z brudem można by.

[Dalamar]

Czyli także dość nisko używana technologia, ciągle w testach. Fajne patenty, ale wydaje mi się że do prototypowania, do samego ogarnęcia designu lokacji, nim siadają do tego graficy i mesherzy. Wiadomo, że takie rzeczy jak tory itd, to ból w tyłku, żeby samemu składać to tutaj będzie bardzo pomocne. Zastanawia mnie skala użycia tego.

 

Faktem jest że wcześniej i czasem teraz też składało się całe levele w programie graficznym, potem tylko eksporty, także ciekawe co będzie dalej.

 

Hmm z tymi meta danymi...sama maska jest bez sensu, żeby ją trzymać na 3 kanałach. W jednym pliku można wcisnąć 3 ew. 4 maski, pytanie czy wtedy można się do nich dobrać. Znając życie tak, tylko ja jestem zacofany z programowaniem xd No i jeśli chodzi o ilość, to wchodzą next geny, nie trzeba się będzie tak spinać.

[legomir]

3 ew. 4 maski, pytanie czy wtedy można się do nich dobrać

 

Kolor jest wektorem 3/4 wymiarowym czyli dobranie się do niego do żaden problem. Hmm... w ten sposób można robić pojedyncze budynki jak i całe miasta ;) Zresztą Houdini Engine ma być podpięty bezpośrednio pod Unity na razie a potem pewnie Unreal i Cry, zresztą nie śmiecę już wątku Razora, Dalamar jeśli masz czas mógłbyś wejść teraz albo wieczorem na gg i chwilę pogadać?

[iniside]

Cześć,

 

to tak na szybko postaram się odpowiedzieć.

 

1) i 2) Jeśli chodzi o model, to wydajniej sprzętowo niż taka modularność się nie da.

To jest mit. Nie wiem dlaczego ludzie go ciagle powtarzaja jako prawde. W wiekszosci przypadkow meshe nie sa instancjowane i batchowane.

Nowoczesne karty graficzne (od GTX 560 w góre) sa w stanie przemielic miliardy trisów na sekunde.

Problemem jest ilosc tych obiektów.

Tak naprawde nie ma żadnej reguły na temat tego jak jest wydajniej, bo wszystko zalezy od silnika którego sie uzwa (wbrew obiegowym mitom, Unreal nie instancjuje niczego poza Foliage).

Małe modularne obiekty łatwiej poddaja sie cullingowi, ale dodaja duzo Draw Calli (przez co GPU nic nie robi tylko czeka na CPU).

 

Oczywiscie modelowac sobie z modułów nikt nikomu nie zabroni, ale to czy wyeksportowac moduły czy jeden wielki obiekt to juz jest inna i całkiem indiwdualna sprawa, zalezna od tego co sie robi.

Budynki itd, to ja bym jako jeden duzy mesh, z osobnym meshem na wnetrze.

 

Tak czy inaczej powstrzymałbym sie ze sprzedawaniem takich pomysłow jak modułowosc czy pakowanie wszystkiego na atlasy jest ultimate i najlepszym sposobem, jako prawdy objawione, bo w zderzeniu z rzeczywistoscia okazuje sie, ze to tylko kropla w morzu optymalizacji :D.

[plutko]

inside:

z wiekszoscie sie zgadzam. Wszystko zalezy od silnika, zastosowanych rozwiazan i potrzeb. Mozesz jednak napisac cos wiecej o Unrealu? To dla mnie zaskoczenie i jakos nie moge tego znalezc w sieci...

W przypadku Razera oczywiscie nie ma sensu bawic sie w moduly przy glownych budynkach.

[veti]

Lightmass w Unreal Engine jest "per object" a nie "per material" - dlatego nie można zastosować instancing'u dla static mesh'y

Ja jeszcze tylko dodam ,że obiekty rzucające dynamiczny cień nie są batchowane - stałe dla wszystkich silników.

Edytowane 14 Październik 2013 przez veti

[iniside]

inside:

z wiekszoscie sie zgadzam. Wszystko zalezy od silnika, zastosowanych rozwiazan i potrzeb. Mozesz jednak napisac cos wiecej o Unrealu? To dla mnie zaskoczenie i jakos nie moge tego znalezc w sieci...

W przypadku Razera oczywiscie nie ma sensu bawic sie w moduly przy glownych budynkach.

 

I najpewniej nie znajdziesz. Bo to informacje ze sie tak wyraze z pierwszej ręki. Nie wchodziłem w detale, bo chcialem sie tylko dowiedziec jak to jest z tym instancjowaniem i sprawa wyglada tak:

1. Foliage - pelny instancing i batching. W jednym rzucie, mozna przemielic setki obiektów (pojedyncze zdzbla trway sa akceptowalne i mozliwe).

2. Static/dynamic/skeletal meshes - jedyne co sie dzieje, to oszczeedzeanie pamieci poprzez instancing, ale kazdy obiekt i tak dodaje draw calle.

3. Materialy - Material Instances sa uzywane wylacznie do tego zeby moc szybko zmieniac rozne wartosci, oszczedzac pamiec, albo zeby poprostu kazdy pracowal z tym samym.

 

veti, dobrze mowi ze to przez Lightmass, bo Foliage jest automatycznie grupowane i dzieli wspolny lightmapping (jesli uzywasz). Tak sobie teraz skojrzylem kiedy czytalem dokumentacje na ten temat.

[Dalamar]

Sam proponowałem dużo większe segmenty :) Generalnie wszystko rozbija się o to co się robi, w czym i jakie znaczenie w grze ma dany model.

 

@inside Dzięki za to info powyżej, przydatna rzecz.