Nya artiklar
Mer innehåll
Taggar
Ursprungligen postat av TheSpaceMan
Det här är en intressant idé, och något jag länge varit intresserad av, men av olika anledningar inte kunnat genomföra. Jag har dock många idéer för hur man ska få till det för att både få flexibilitet och bra prestanda och bra visuellt resultat i spel.
Det är viktigt att notera dock, att det här är till 90% ett art-problem, inte ett tekniskt problem. Och av de tekniska 10 procenten, består 90% av att ta fram en komplett specifikation och 10% handlar om kodningen. Att skriva koden för ett sånt här system är enkelt, och det finns många bra referenser. Att modellera och texturera för det är svårt och tidskrävande, och med komplikationer som man vanligen inte har.
Så utan duktiga modellerare, så faller hela projektet. Men specifikationen kan man ju förstås börja jobba fram ändå :-)
Jag har en massa att gå igenom här, och jag är inte säker på vilken ordning som är bäst, och kanske inte förklarar det så bra, så man kan behöva läsa det här inlägget framlänges och baklänges ett par gånger om man ska förstå det hela - men ställ gärna frågor om förtydliganden. Jag har försökt göra lite bilder för att illustrera (eller laddat ner bilder i vissa fall), men de är till för att illustrera konceptet, och får inte det hela att se speciellt vackert ut
Jag anser att den grundläggande designprincipen bör vara flexibilitet. Att ha ett system där en modellerare kan modellera något EN gång, och att det sedan kan kombineras med alla redan existerande och framtida expansioner - och inte ha det så att för varje tillägg man gör, måste man modellera det i ett antal olika varianter. Jag tror detta är nyckeln till stor variation med rimlig arbetsinsats.
Det första som behövs är en grundmodell. Eftersom flexibilitet är huvudmålet (och pga. användandet av morphs, vilket jag går igenom längre ner) så behöver grundmodellen vara av hög upplösning - högre än vad som är rimligt för en realtids 3D applikation. Här är en rimlig upplösning - notera hur uniformt distribuerade polygonerna är (vilket är viktigt) och hur mycket tätare de är i ansiktet (av goda skäl som kommer visa sig senare).
Det behövs inget speciellt avancerat skelett - de röda linjerna visar en möjlig uppsättning bones. Som man kan se så motsvarar de kroppens huvudsakliga leder, och det räcker i regel alldeles utmärkt för animation. Notera dock att huvudet bara är ett enda bone - animationer och modifikationer av ansiktsuttryck görs med fördel på annat sätt (mer detaljer om detta senare).
Så, det höga polygon-antalet behövs för att man ska få den flexibilitet som behövs, men för att kunna använda det hela i realtid, behöver man samma figur i några olika level of details, eller LODs. Här är ett exempel på hur jag menar med olika LODs (men tänk dig att dessa är grundade i samma modell som bilden ovan, istället för en helt annan figur - jag hittade denna bild på nätet för att illustrera exempel):
Observera dock att i denna bild, på de lägre LOD nivåerna, är distributionen inte lika uniform - i vårt system skulle de dock behöva vara mer jämnt distribuerade (inte de där långa polygonerna längs benen till exempel).
Nu till avdelningen morphs. Morphs (eller morph target animations) är, i min mening, det grundläggande konceptet för att få den flexibilitet vi behöver. Morphs funkar som så, att man tar orginalmodellen, och modifierar den, men UTAN att lägga till eller ta bort några vertexer eller polygoner. Man bara flyttar runt deras positioner, för att få en annan form. När man gjort modelleringen, beräknar man skillnaden mellan orginalmodellen och den nya, och de delta-värden man får kan man sedan använda genom att addera dem till orginalmodellen. Det fiffiga med morphs är att de är additiva, så man kan applicera flera olika morphs, och få ett kombinerat resultat. Det är även väldigt enkelt att skala delta-värdena innan man adderar dem till orginalmodellen - så man kan i princip välja med vilken styrka man vill applicera en viss morph.
Här är ett antal exempel (jag använde en lågpoly modell från poser för att visa det hela tydligare - så ser inte så bra ut som det kan göra om man har en mer högpoly modell). Bilderna visar en orginalmodell, med ett antal olika morphs applicerade, och även exempel på flera olika morphs samtidigt. Notera att morphsen som visas i översta raden är modellerade (modifierade utifrån orginalmodellen) för hand av en grafiker - men de kombinationer som visas nedanför är bara resultatet av att applicera flera morphs samtidigt. I dessa exempel har jag applicerat morphs med 100% styrka, för att tydligare illustrera det hela - det går att få betydligt subtilare resultat om man applicerar dem med mer varierad styrka.
Här är en av anledningarna till att grundmodellen måste ha hög upplösning (speciellt i figurens ansikte) - för om upplösningen inte är tillräcklig, blir man begränsad i hurdana morphs man kan få till, eftersom det inte finns tillräckligt många vertex punkter att flytta runt (man kan ju inte lägga till punkter, för då tappar man ju kompatibilitet med grundmodellen). Vi kommer att använda LODs och ett par extra-trick för att få en realtidsvänlig variant, men fortfarande behålla mycket av detaljerna.
En stark poäng med morphs systemet, är att olika artists kan skapa morphs till systemet oberoende av varandra. Nån kanske skapar en morph för alv-öron, nån för alien-huvud, etc... och som användare kan man kombinera och använda dem som man tycker passar, utan oro för kompatibilitetsproblem. Detta är något som metoden med "utbytbara kroppsdelar" inte har - där är det ju inte möjligt att kombinera på samma sätt som morphs, utan varje kombinationsdel måste skapas individuellt.
Det här kanske blir ännu tydligare när man tittar på kropps-morphs:
Principen med additiva morphs är densamma, och här kan man se styrkan i att kombinera dem. Det påvisar än en gång hur viktigt det är med hög upplösning - tänk dig att man skapar en morph som får figuren att se ut som den är klädd i kavaj, eller har vida byxor... Polygonerna måste helt enkelt finnas där för framtida behov och flexibilitet, även om de inte direkt behövs för grundmodellens egen skull.
Klädsel är intressant. I tidiga versioner av Poser, fanns en del morphs för jackor, byxor etc, men från version 3 (tror jag det var) började man med separata modeller för kläder. Jag tror att för vårt syfte, vore det en sämre lösning - vi skulle få flera lager av polygoner, men framförallt skulle det bli mycket mer grafikjobb - om man gör en ny kropps-morph, då måste den ju göras separat för varje klädesmodell man har - onödigt extrajobb, och begränsar flexibiliteten. Bättre då att även göra kläder med hjälp av morphs.
Här vill jag göra en liten avstickare, och snabbt behandla ett alternativ som jag INTE förespråkar, men som kan vara intressant att iakttaga varför det inte är att rekommendera - nämligen att använda bones för ansiktsuttryck etc, istället för morphs.
Ett spel som använder bones för "facial animation" är The Getaway, så jag lånar lite bildmaterial därifrån för att illustrera (hämtat från denna artikel, som är väl värd att läsa, för att få djupare förståelse inom ämnet).
Som man kan se, så är det väldigt många bones i ansiktet, för att kontrollera ansiktsuttrycken. Och det ger endast möjligheten att kontrollera ansiktsmusklerna - om man vill kunna modifiera ansiktsform eller features som haka, näsa etc, skulle man behöva många fler bones. Och samma sak för kroppen. Det skulle behövas hundratals bones för att få riktigt bra flexibilitet - men det skulle ändå vara mindre flexibelt än morphs.
Dessutom skulle det vara mycket mer jobb att skapa olika variationer med bones, än vad det är med morphs. Att skapa en morph kan göras med verktyg som ZBrush, som demonstreras i denna video - man skulpterar helt enkelt fram variationen:
För tänk vilka möjligheter detta öppnar upp - någon kan t.ex. skapa en väldigt specialiserad alien-morph - och ändå veta att alla befintliga morphs, för "Smile", "Frown" etc är fullt kombinerbara med det - vilken reduktion i arbetsbörda!
När det gäller texturer, så tycker jag man bör satsa på en liknande flexibel approach där. Här är en bild som illustrerar hur man kan blenda olika texturer för att få kombinerade variationer. Även i detta fall har jag dragit på styrkan till 100%, men för mer subtilt resultat kan man ju blenda med lägre styrka, precis som i fallet med morphs - men här rör det sig om lager av bitmappar istället.
Samma princip kan med fördel användas för texturer till kläder - om man t.ex. gör en textur för en jeans-jacka, så gör man den i olika lager: tyget för sig, tråden i sömmarna för sig, knapparna för sig, och kanske några olika slags tryck på ryggen i separata lager. Då kan man lätt skapa flera varianter på den, genom att ändra Hue, Saturation och Brightness för de olika lagren separat, och därmed kunna göra både blå jeansjacka med mässingknappar såväl som svart variant med silverknappar, allt utifrån samma texturuppsättning.
Så ovanstående är det jag anser att man behöver för att kunna skapa modeller med maximal variation samtidigt som man minimerar antal modeller/texturer som behöver skapas. Det gör det något mer komplicerat att skapa elementen, men i gengäld kan de återanvändas i oändliga kombinationer, vilket mer än väl bör uppväga detta.
Men hur tar vi oss från detta och till att ha modellen i vår realtids 3D motor? Det är här LODs kommer in i bilden igen:
När vi tweakat vår modell, genom att applicera morphs och så, så kanske den ser rätt annorlunda ut än grundmodellen, och därför även annorlunda ut än de lägre LOD nivåernas modeller. Vi vill ju inte att när man gör en morph, att man ska behöva göra den för varje LOD nivå - vi behöver ett sätt att automagiskt applicera den komplett morphade topologin från vår modell till de lägre LOD nivåernas modeller. Om dessa skapats på rätt sätt, är det en enkel process - det viktiga är att både grundmodellen och de lägre LODsen är mappade til samma UV-layout (textur). För då kan vi använda detta faktum, och för varje vertex i LOD modellerna, hitta den vertex i den morphade modellen som ligger närmast på UV-mappen, och helt enkelt flytta LOD modellens vertex till samma position som motsvarande vertex i den morphade modellen. Detta ger oss en LOD med mycket lägre polygon-antal (eller rättare sagt flera LODs, så vi kan använda de lägre varianterna i fjärran), men som fortfarande följer konturerna av den morphade modellen så gott den kan.
Men, vi behöver inte stanna där. Eftersom den morphade modellen har så högt polygon-antal, kan vi generera en normal map från den, genom att rendera ut dess UV mapp men med värden från dess normaler. Eftersom UV-layouten är likadan i LODsen, så kommer de kunna använda normal mappen som den är. Om man önskar kan man även generera en ambient occlusion map från högpoly modellen, som kan ge extra detaljer när man belyser modellen.
Det här exemplet visar hur en lägre LOD kan se mycket mer detaljerad ut med en normal map och en ambient occlusion map. Och normal maps finns det vidsträckt stöd för - Unity har det inbyggt t.ex. Men, man behöver det höga polygonantalet för att kunna generera ut den informationen - även om man inte direkt tar in den högupplösta modellen i sin 3d motor.
En sak när det gäller texturen dock - man bör inte göra UV-mappen som i exemplet ovan - den ger för lite detaljer på karaktärens sidor, då den bara fångar framsida och baksida. Bättre är något i stil med bilden nedan, där man "vikt ut" texturen istället - men vi behöver nog inte samma detaljnivå för tänder, naglar och ögon som på denna :P
Man bör vara medveten om att även om denna teknik kommer att ge grym flexibilitet och variation, så kommer det inte att se lika bra ut som om man skapade alla variationer/kombinationer för hand - alltså individuellt modellerade varje karaktär till sitt spel enligt traditionell metod. När man applicerar morphs så blir det lite sträckningar och uttänjningar, som warpar texturen lite. Inte så det stör speciellt mycket, men ett tränat öga ser det nog direkt. Men såna kompromisser får man räkna med för sådana här system.
När det gäller filformat, så tror jag att det bästa är att hålla det enkelt. Man kan tillåta en plugin-struktur, där folk kan skriva plugins för att importera och exportera meshes och morphs i olika filformat - internt kan systemet använda sitt eget. Om man implementerade stöd för att importera från OBJ format som ett första steg, så har man täckt in så gott som alla modelleringspaket. Och med export för FBX som första anhalt, så man kan få modellerna in till t.ex. Unity direkt. Sen kan folk skriva egna export plugins, eller konverterare från fbx, vilket de nu föredrar. Men detta är den enkla delen av problemet, eftersom man ju i det skedet har sina LODS med applicerade variationer och sammanslagna texturer, och bara kan skriva ut dem.
För animation, skulle jag föreslå att man använder nåt i stil med BVH formated (specifikation här) som är enkelt och har utbrett stöd. Något bör notera med animationer, är att man bör begränsa dem till "joint rotations" - och ingen skalning eller translation av joints, då det leder till ett antal problem, och ofta gör att blendningen av kroppsdelar inte funkar så bra.
Det är lite idéer iallafall - hoppas jag lyckades göra mig någorlunda förstådd :-P Och som sagt, frågor, synpunkter och korrektioner välkomnas.
Jag är inte beredd att ta på mig att driva ett sådant här projekt, men är gärna med och ger tips, råd och hjälp. Det som framförallt behövs är grafiker - och när man väl har ett grundsystem uppe, tycker jag man bör överväga att göra så att individuella grafiker kan göra expansioner som de kan sälja till användarna för ett rimligt pris - tror det skulle vara svårt att hitta frivilliga att jobba på detta gratis, då vi ju faktiskt pratar om att göra ett system som på sikt eliminerar behovet av grafiker för de som använder det (dock med konsekvensen att det inte blir lika snygg grafik som om den vore "custom made").
Bloggar
vBulletin-meddelande