• 3DKaraktärsvektyg för 3d.

    Citat Ursprungligen postat av TheSpaceMan Visa inlägg
    Det här kom upp i diskussion pga en av Mattias postade lite bilder på Poser.
    Frågan som dök upp från Hildenborg är om det klarar 3d likväl som 2D. Men poser är inte anpassat för det eller har väldigt licensavtal gällande 3d meshs det producerar.

    Det jag kom att tänka på direkt är att det finns SÅ många spel idag som har custom verktyg för spelarkaraktärer i spel. Vi har ju folk här med redig kunskap runt det tekniska. Borde det inte gå att diskutera ihop något om hur man skulle sätta samman ett sådant system som kan vara open source OCH använda någon form av allmänt 3dformat så folk kan exportera om det till dom format dom vill ha?

    För folk som undrar vad jag prata om så följer lite filmexempel på spel som använder precis det jag menar, visst tror många grafiker hatar det pga att dom tappar den totala kontrollen. Men användaren tror jag hellre har frihet och som programmerare blir jag lyrisk över tanken att kunna ha 100 unika karaktärer med några rader kod, som kan dubblas genom att släppa in en meshbit till i slumpsystemet. Eller ha kontrollen coh sätta samman någorlunda vettiga karaktärer att ha i ett spel.

    ungefär 1:26 in så får man lite exempel av det jag menar.


    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").
    This article was originally published in forum thread: 3DKaraktärsvektyg för 3d noobs. started by TheSpaceMan View original post
    Comments 29 Comments
    1. DvDmanDTs avatar
      DvDmanDT -
      Jag har också varit inne lite på det där. Inte att göra ett verktyg, men customization. Jag vill nämligen kunna visa vad spelaren och andra karaktärer har på sig. Någon form av brainstorming följer..

      Hur svårt det är beror till ganska stor del på animationssystemet och hur noga man är med 'seams' och glipor. Jag gjorde ett ben-baserat animationssystem någon gång som bara slängde in en modell per ben t.ex. Blir jätteuppenbara glipor och sådär om karaktären tar upp stor skärmyta, men om man har rätt små karaktärer som i ett RTS t.ex så funkar det ganska bra. Nämnas bör väl kanske att det blir helt otroligt segt också.

      Vill man bli av med gliporna blir det snabbt lite klurigare. Det är antagligen inte jättesvårt att bygga ihop själva geometrin till en stor modell eller hur matriserna ska transformera varje enskild vertex. Kan tänka mig att det finns några fallgropar där, men inget jätteproblematiskt. Sedan måste man hantera texturerna också. När jag tänker efter är det kanske inte så problematiskt som jag först tänkte det heller.

      Man måste bygga upp ett arkiv av komponenter som måste göras på något sätt. Där är det väl enklast att bara specificera vilka vertices som ska finnas vid vilken anslutning för varje 'kroppsdel' för att dom ska passa ihop med nästa kroppsdelar och sådär, och sedan göra mallar i något lämpligt 3d-format.

      En annan grej jag funderat lite på är att ha komponenter som antingen 'bygger på' eller 'ersätter' grundkomponenten. Exempelvis kanske användaren plockar upp någon 'armor' som består av några läderband här och där (tänk fantasybarbar). Då kanske det vore smidigare att ha kvar 'grund-torso-komponenten' och lägga 'läderband-armor-komponenten' utanpå eller hur man nu ska säga. I det fallet skulle man för varje kroppsdel då ha en 'grundkomponent' och noll eller fler 'tilläggskomponenter'. Här tillkommer ytterligare frågor, som 'vad händer om användaren tar på sig en tröja med huva?'. Hur skulle det kombineras med att man har en hjälm på sig?
    1. TheSpaceMans avatar
      TheSpaceMan -
      Jo alla vertexar måste ju aligna enligt parts och skalas efter parent size osv. Men det borde ju gå att bryta ner till gemensama nämnare utan springor. Eller i värsta fall går det använda sluten geomatri i rätt färg och hoppas att ingen tänker på det.

      Jag tror den viktigaste tanken runt det överlag är att det ska vara snabbt och lätt att skapa karaktärer som använder ett delat skelett (om så skalat på visa sätt) så dom kan dela animationer. Vet att första crysis planerade stöd för ett sådant system. Mer eller mindre var deras tanke vid stunden att man skinnade alla delar till ett identiskt skelett så skulle dom röra sig enhetligt. Vet inte om det är en bra eller dålig lösning. Svårt att veta vart man ska börja, ska man ge störst frihet i slutprodukten är det väl bäst att gå mot opengl som då även är platformsoberoende.
    1. DvDmanDTs avatar
      DvDmanDT -
      Det är nog bäst att använda någon form av renderare för programmet i vilket fall. Fast det kanske är mer jobb än att göra det själv, det är ju inget jätteavancerat som borde behövas där i själva programmet. Modellerna/animationerna/resultatet bör exporteras i ett format som är oberoende av underliggande api/renderare i vilket fall så. Eller tänkte du göra det som ett lib?

      Jag föreslår att man kan välja ett skelett/en templategubbe/whatever så att man kan använda det till olika projekt. Man behöver inte kunna välja eller skapa nya sådana skelett/templates till en början heller, bara programmets struktur är byggd för att kunna hantera det.
    1. TheSpaceMans avatar
      TheSpaceMan -
      Det viktigaste tror jag är att glo upp det absolut minsta som behövs för att rendera en scene med en skinnad karaktär i samt den absolut minsta mängd data man behöver för det. Så som jag ser det är det både ett program och ett lib. Ett exempelprogram där man kan testa och sätta samman delar. Usch då behövs det ett gui samt även då ett lib för att kunna modifiera och nyttja datan internt i sina egna program om man vill. Tänkte att folk kanske vill ha ingame customization för sin huvudperson.
    1. DvDmanDTs avatar
      DvDmanDT -
      Man behöver nog ett utvecklingsverktyg i vilket fall för att testa animationer och sådär.

      Vad jobbar du normalt sett med för utvecklingsverktyg och så? Själv jobbar jag i princip uteslutande med XNA, och nu när det finns hyfsat kompetenta opensource-implementationer som stödjer OSX/iOS och Linux så känner jag mig inte jättemotiverad att gå över till något annat..

      Iofs, det stora problemet borde ändå vara content, eller? Känns inte som att det borde vara sååå mycket jobb med koden för den faktiska användningen sedan, så det kanske går att porta.
    1. TheSpaceMans avatar
      TheSpaceMan -
      Jag arbetade en hel del i XNA förut med och C#, men nu jobbar jag och kör huvudsakligen c++. Verktyget det implementeras i är ju inte så viktigt utan det blir ju slutformatet man måste vara klar över. Har man ett bra format går det bygga exporters och folk kan göra lite vad dom vill, samt ett format som är självförklarande implementations mässigt. "Det här skalar ett ben och allt som är anslutet till det", den här pendlar mellan mesh objekt som har den här tagen, typ flera olika hjälmar, hår etc.

      XML har jag fått för mig är det mest standard formatet som är relativt lätt att parsa. Det blir lite större filer dock än om man kör binärt. Men binärt tror jag bara är dumt att ens fundera på.
    1. DvDmanDTs avatar
      DvDmanDT -
      XML funkar men lär ju bli helt enorma filer.. Kanske kan stödja XML+GZip eller något iofs.

      Vad behövs för features då?

      • Skelett med en komponent per 'ben'
      • Komponentset med komponenter för flera 'ben'
      • Komponenter som är designade för att 'ta över' hela 'benets' plats och komponenter som är designade för att 'ligga utanpå' ett 'ben'
      • Stöd för att skala/morpha komponenter (om möjligt)
      • (sekundärt) Något sätt att rita delar av en karaktär/komponent i en speciell färg, typ för teams i ett rts eller sportspel, för att markera spelare i flerspelarspel eller för att göra en superfiende lite annorlunda
      • (sekundärt) Stöd för animerbara/lösa delar av komponenter (t.ex något som hänger och dinglar) och/eller particle emitters.
    1. TheSpaceMans avatar
      TheSpaceMan -
      Men är storleken en sådan issue. Jag köpte 1tb disk för 300 kr. Och om det aggerar verktyg påväg mot ett finalformat är det nogt inget problem.
      I övrigt tror jag du täcker det ganska bra. Det man skulle få tag på är ju ett standard skelett i något format som har rätt proportioner. Så har man något att utgå ifrån.
      Och ja det går ju zippa slutresultatet om det är så. Så kan folk välja själv senare om dom vill packa upp det och bearbeta det eller lägga in zipstöd i sin kod och bearbeta det.

      Killen som gjorde box2d och skrev fysiken till diablo rekomenderade att man hade ett mellanformat iaf, då om man ändrar något så är det lättare att konvertera än om man passerar något binärformat etc på vägen. Det gällde ju visserligen raggdolls etc. Men jag tror samma tanke gäller lite.
    1. DvDmanDTs avatar
      DvDmanDT -
      Problem med storlek är väl a) Allt är inte persondatorer, b) alla har inte snabba anslutningar utan överföringsbegränsningar och (inom parentes) c) många lagringsmedier är äckligt sega.

      Men det är detaljer, det är väl bara att programmet klarar .xml och .xmlz eller något. Jobbar man i .NET är det storleksordningen 4 rader för att lägga till komprimerinsstödet så det är ju inte direkt något jobb med det.

      Har du koll på om det finns något vettigt och hyfsat vanligt format för skelett? Det är ju inga problem att göra ett, men vore ju kanske trevligt om man kunde använda befintliga program för att animera dom. Blender?
    1. Hildenborgs avatar
      Hildenborg -
      Det ni behöver för att kunna göra ett sånt här program, är i första hand en eller flera duktiga artister som kan göra modellerna åt er. De artisterna kommer med all sannolikhet att arbeta med Maya eller 3D-studio Max.
      Båda dessa program kan exportera sina modeller med skinning och allt till FBX formatet.
      FBX formatet har en utmärkt SDK som finns för Mac, Windows och Linux, och är gratis all ladda hem.
      Vill man ta lite genvägar så kan man via FBX SDK'n använda den inbyggda scen grafen i FBX formatet, så slipper man bygga en egen.
      Utöver det så behövs en renderare, och jag har uppfattat som att Ogre kan hantera FBX, annars får man skriva en egen... Det är rätt mycket jobb för att få det bra, så man kan vilja titta på Scenix som är ruggigt bra, men som inte finns till alla plattformar ännu.

      Tja, det är mina tips, som naturligtvis är lite viktade då jag får mycket av min kunskap från mitt jobb... Fast jag tror inte att det finns så mycket enklare vägar att gå ändå.
      Och nej, jag har tyvärr inte tid att engagera mig i ännu ett projekt
      Men det låter kul, hoppas ni kommer någon vart, med eller utan mina tips.
    1. DvDmanDTs avatar
      DvDmanDT -
      Jag håller med om att vi behöver artister, men dessa måste samtidigt ha något att jobba mot. Om vi hittar 4 artister och ber dom moddelera varsin kroppsdel så lär vi knappast få något som passar ihop eller går att använda.

      Jag är just nu lite inne på att försöka bygga en så enkel modell som möjligt av en stående man med armarna utåt och fixa ett tillhörande skelett till denna. Efter denna kan man då definiera vilka vertices som måste finnas vid kopplingspunkterna för komponenter för att de ska passa ihop med grundmodellen. När man väl gjort det borde det vara lättare att få tag på riktiga artister som kan bygga komponenter för de olika kroppsdelarna.

      När det gäller filformat osv.. Det är väl FBX och/eller COLLADA som gäller där. XNA har inbyggt stöd för FBX vad jag förstår, så det tilltalar väl mig en del. Å andra sidan verkar det finnas en hyfsat vettig COLLADA-importer också.. Med det sagt vet jag inte hur mycket av dessa format/SDKer osv man har glädje av när man ändå måste bygga ihop modellen själv och det i slutprodukten.

      När det gäller vilka program och sådär.. Förhoppningsvis kan man använda format och tekniker som är så produktoberoende som möjligt. Även om de flesta duktiga artisterna antaligen föredrar 3ds max eller Maya så vore det trevligt att stödja något man kan använda utan att behöva lägga ut 30-50k i licensavgifter per användare.
    1. TheSpaceMans avatar
      TheSpaceMan -
      Hildenborg, tror din feedback bara skulle kunna vara nog nyttig även om du inte har tid med kod eller design av systemet, så kan du ju se tydliga uppenbara misstag vi gör. Collada sparar ju redan sin data i xmlformat, så det är ju ganska oberoende av en parser på sitt sätt. Dvs du behöver inte veta hur du tolkar binär data, i värsta fall går det läsa hur det hänger samman. Som ett första steg skulle jag bara föreslå att vi har en modell i T-Pose med ett skelett och gång animation och ser om vi kommer på hur man kan redigera skalan på olika noder och om det fortarande hänger samman med animationen.

      Ett problem vad jag förstått med animation, är väl att man arbetar ofta med normerade positioner när det gäller rotation/positon. I ärlighetens namn så är det här ett ganska stort projekt, då jag inte ens skrivit någon form av skinning tidigare.
    1. DvDmanDTs avatar
      DvDmanDT -
      Kan du vidareutveckla vad du menar med att skala noder?
    1. TheSpaceMans avatar
      TheSpaceMan -
      Jag skulle säga blender med för att skapa skelettet. Vad jag vet är skelett i sig inga egna format? Utan mer en samling noddata precis som vilken 3d model som helst.
    1. DvDmanDTs avatar
      DvDmanDT -
      Skeletten brukar nog vara inbakade i modellerna, explicit eller implicit, men du kan säkert exportera dom om du vill. Jag har ärligt talat ganska dåligt koll då jag nästan bara jobbat med 2d eller statisk 3d som jag byggt upp med kod. Dom gånger jag renderat modeller (utöver det jag gjort i kurser) har jag bara använt färdig funktionalitet för att importera och rendera existerande modeller så.

      Kan du med blender?
    1. TheSpaceMans avatar
      TheSpaceMan -
      Ett skelett är samman byggd av noder, det är i förhållande till dessa noder som modellen skinnas.
      Skalar man eller modifierar en nod så skalar/modiferar man allt som är skinnat till det. Så skulle man skala upp armnoderna så får man en karaktär med större armar även om resten av kroppen för blir den samma, vilket tillåter snabb lätt modifikation av karaktärer utan att behöva modifiera skelettdatan mer än med en float för dom relevanta benen. Dvs ett skelett är bara en länkad lista med noder.

      En skinnad karaktär håller ett skelett där varje nod har ett id, en animation är oftast bara skelettet med noderna animerade. Vid animationtime så flyttar man noderna i den skinnade karaktären enligt timeline för animationen i animationsskelettet.

      Det är iaf min tolkning då jag inte faktiskt suttit och implementerat det själv. Har jag rätt? ^^

      Grejen är den att om skelettet håller flera noder som är bundna till den skinnade karaktären så kan man göra flera modifikationer i olika skala på karaktären. Att bara säga skala är ju inte så bra, Man kanske även vill kunna köra translate och rotation till viss del.

      Dvs ögonbrynen på karaktären kan ha skinnade noder under sig, och genom modifikation så kan man flytta dom upp/ner och där av påverka höjden på ögonbrynen. Här blir det återigen då en fråga då, om man man behöver hålla alla noder/skelettpunkter efter modifikation. Eller om det går att spara om dom som statisk data. och få en mindre output fil.

      Ytterligare en fråga är om det ska vara symetiskt eller asymetriskt stöd. isf modiferar man bara en nod och det sätts uniformt över karaktären.

      På ett sätt känner jag att asymatri skulle vara skoj. Men det kan ställa till rejäla problem skelett och skinning mässigt.
    1. DvDmanDTs avatar
      DvDmanDT -
      Nu ska vi se. Ett skelett är en serie noder ja. Du har en rot-nod (oftast typ midjan) och sedan kan varje nod ha en serie barn. Barnen har en vinkel och ett avstånd till sin förälder.

      När du animerar ett skelett så gör du det med keyframes. För varje keyframe så har du har du en vinkel för varje ben (eller så har varje ben en serie keyframes med vinkeln för just det benet i just den tidpunken beroende på implementation).

      Varje nod får en matris för varje keyframe när du renderar.

      Varje vertex i modellen hör sedan till en eller flera ben/matriser. Om en vertex hör till ett ben så är det bara att kolla hur matrisen ser ut i föregående keyframe och i nästa keyframe, räkna ut var vertexen befinner sig i respektive keyframe och sedan köra linjär interpolering med tiden för att hitta var den är just nu. Dvs, om tiden just nu är mitt emellan tiden för keyframe A och keyframe B, så är nuvarande position medelvärdet av positionen i A och positionen i B.

      Om en vertex sedan hör till flera ben/matriser (typ armbåge) så används vikter. Då hittar du positionen enligt ovan för varje ben den hör till (säg att den hör till 2 ben/matriser, då har du alltså 2 positioner) och använder vikter (20% underarm, 80% överarm) för att hitta slutgiltig position.

      Det är iaf hur jag förstått det.

      När det gäller skalning.. Jag kan inte riktigt se framför mig om det är problematiskt eller ej. Att skala hela karaktären är inga som helst problem, men att skala enskilda ben/kroppsdelar/komponenter är eventuellt klurigare. Jag är egentligen inte helt säker på om det ens är klurigare heller. Det kanske är så enkelt som att multiplicera in en skalningsmatris i en viss kroppsdels matris, men är inte säker på att det spelar bra med dess barn riktigt. Jag vet heller inte om det är riktigt logiskt att göra just nu..?

      [edit] Såklart kan animationsdelen innehålla mer än bara vinkeln i varje keyframe också, det var bara ett exempel. Vinkeln räcker dock oerhört långt om man bara vill animera kroppsdelar på en människa.
    1. TheSpaceMans avatar
      TheSpaceMan -
      Hört från någon med mycket mer insyn i det här att han ska komma med lite synpunkter tankar kring det hela.
      Så jag väntar spänt på den posten.
    1. DvDmanDTs avatar
      DvDmanDT -
      Låter trevligt.

      Jag kom just på att jag läst en forumpost-tutorial där någon berättade om hur man gör den estetiska biten av det vi pratar om här och jag har för mig att den var hyfsat bra, men jag kommer för mitt liv inte på vart jag läste den. Någon som känner till en engelsk/internationell spelutvecklingssida med ett ganska mörkt tema? Det är inte gamedev.net..
    1. Mattias Gustavssons avatar
      Mattias Gustavsson -
      Citat Ursprungligen postat av TheSpaceMan Visa inlägg
      Det här kom upp i diskussion pga en av Mattias postade lite bilder på Poser.
      Frågan som dök upp från Hildenborg är om det klarar 3d likväl som 2D. Men poser är inte anpassat för det eller har väldigt licensavtal gällande 3d meshs det producerar.

      Det jag kom att tänka på direkt är att det finns SÅ många spel idag som har custom verktyg för spelarkaraktärer i spel. Vi har ju folk här med redig kunskap runt det tekniska. Borde det inte gå att diskutera ihop något om hur man skulle sätta samman ett sådant system som kan vara open source OCH använda någon form av allmänt 3dformat så folk kan exportera om det till dom format dom vill ha?

      För folk som undrar vad jag prata om så följer lite filmexempel på spel som använder precis det jag menar, visst tror många grafiker hatar det pga att dom tappar den totala kontrollen. Men användaren tror jag hellre har frihet och som programmerare blir jag lyrisk över tanken att kunna ha 100 unika karaktärer med några rader kod, som kan dubblas genom att släppa in en meshbit till i slumpsystemet. Eller ha kontrollen coh sätta samman någorlunda vettiga karaktärer att ha i ett spel.

      ungefär 1:26 in så får man lite exempel av det jag menar.

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