tnm061 3d-gra˜k - webstaff.itn.liu.sewebstaff.itn.liu.se/~stegu/tnm061-2012/projekt/tnm061... ·...
TRANSCRIPT
Specialeffekter i film
TNM061 3D-grafik – Projekt,
av Kristofer Höglund
Målet med detta projekt var att skapa en kortfilm på ca en minut som blandar animationer med spelfilm. Iden
var att ta en scen från en riktig film och sedan ersätta en karaktär från den scenen med en animation skapat i
ett 3D-verktyg.
Scenen som valdes för detta projekt var slutscenen i ”The Departed”. Jag hittade en gratis 3d-modell av Darth
Vader på www.the3dstudio.com som jag använde mig av för att ersätta en av karaktärerna i den scenen.
Arbetet inleddes med att jag delade upp scenen jag tänkte använda i en sekvens .jpg bilder. Jag importerade
sedan in bilderna i Maya där jag använde dem som referenser när jag satte upp scenen. Jag fäste bilderna på en
”image plane”, sedan skapade jag ett kameraobjekt som jag fixerade på planet. När detta var gjort importerade
jag Darth Vader modellen in i scenen. Jag skalade om modellen och placerade den framför kameraobjektet så
att den precis täckte den karaktär det var meningen att den skulle ersätta. Jag började sedan att animera med
hjäp utav keyframes. Jag animerade dels kameraobjektet då kameran rörde på sig samt Darth Vader modellen.
Jag skapade en pistol åt Darth Vader med hjäp utav box-objekt. Jag skapade även en laserstråle som skjuts ut ur
pistolen med hjälp av ett cylinder-objekt som jag tillsatte olika material och inställningar för sådant som
genomskinlighet och färg. Jag animerade laserstrålen på samma sätt som Darth Vader figuren, med hjäp utav
referensbilderna och keyframes. Istället för att göra allt i en och samma scen så skapade jag flera olika scener.
En scen för laserstrålen samt ett antal scener för olika Dart Vader rörelser.
Eftersom Darth Vader modellen inte var särskilt rörlig var jag tvungen att skapa ett nytt objekt för Vaders arm
som jag kunde röra fritt. Eftersom Darth Vader är placerad så pass nära kameran så ser man dock inte att
armen inte sitter fast på resten av modellen.
Jag renderade sedan animationerna som sekvenser av .PNG bilder. Jag valde detta format eftersom den har en
alpha-kanal där information om transparens finns tillgängligt. Detta är viktigt när man genom ”compositing”
ska lägga ett bildobjekt ovanpå en bakgrundsbild (se figurernan nedan). När jag renderat bildsekvenserna i
Maya importerade jag dem sedan till Adobe Premiere där jag sedan la samman alltihopa till en film. Jag
samplade ljud och monolog från filmen ”The Empire Strikes Back” som jag använde i min kortfilm.
TNM061 – 3D Computer Graphics – VT 2012 John Hollén, Sofie Lindblom, Max Hjärtström & Simon Jare
Jarmos Space Cave Jungle Adventure
version 1.0 Syfte
Att göra ett spel som innefattar programmering, animering och modellering. Tanken var att fördjupa sig i programmeringsdelen med motivering att en fortsättningskurs i c++ läses parallellt med
projektet.
Spelidé
Huvudkaraktären Jarmo befinner sig i yttre rymden i en djungelgrotta (frågor på det?). I djungelgrottan finns elaka cyberkatter som vill skjuta Jarmo. För att överleva måste Jarmo akta sig för
cyberkatterna och döda Supercyberkatten. Supercyberkatten finns uppe på en platå, för att döda denne måste Jarmo ta sig upp på platån. I djungelgrottan finns lådor omkringspridda, dessa kan Jarmo flytta på och använda för att klättra upp. Om Jarmo lyckas överlever han, annars får han börja
om.
Genomförande
Grafikmotor Ogre 3D Ogre valdes för att kunna koda i c++. Efter installation och genomgång av tutorials
gjordes försök att importera modeller från 3ds studio max. Någonstans här i skapelseprocessen togs beslutet att byta grafikmotor. Gruppen kände helt enkelt att programmeringskunskaperna och tiden inte räckte till.
Unity 3D
Är ett redskap för att tillverka spel och betydligt lättare att arbeta i. Det var först efter bytet som gruppen kunde sätta i gång på riktigt.
Hjälpmedel Karaktärer och banan är modellerade (och animerade) i 3Ds max.
Alla beteenden styrs av script som skrivits av gruppen. Ljudfilerna är dels från Unitys eget biblioteket och dels hämtade från internet. Ljussättning och kameraplacering är gjorda i Unity.
Resultat
Trots att mycket tid och arbete gick förlorat innan bytet till Unity anser gruppen att det var rätt
beslut. Vi är nöjda med resultatet och skulle gärna vidareutveckla ”Jarmos Space Cave Jungle Adventure” med fler banor, funktioner och animationer.
Av: Jacob Selg, Oskar Krantz, Albin Törnqvist, Emil Rydkvist, Alexander Uddfeldt MT2B
FloatBall är ett multiplayer-spel där radiostyrda båtar åker runt i en bassäng.
Båtarna spelar antingen i det blåa eller det röda laget, och ska försöka skjuta en badboll i
motståndarlagets mål. Flest mål vinner.
FloatBall är utvecklat i Microsoft Visual Studio med språket C#. Plattformen XNA har använts.
Alla modeller är gjorda i Autodesk 3ds Max eller Autodesk Maya.
Spelmusik och ljud är inspelat och redigerat i Cubase 5.
Texturer är gjorda i Adobe Photoshop.
Features:
Realtidssimulerad vattenyta med reflektion, refraktion och vågor
Partikelsystem för vattenstänk
Kollisionsdetektion med flera sfärer
2-6 spelare i nätverksmiljö
Sex olika båtmodeller med olika egenskaper och utseenden
Egeninspelad musik och effekter
Spelplan med egna texturer
Poängsystem med mål och assist
Flera olika kameravinklar
Inledning Atril är en simpel grafikmotor med en interaktiv komponent som är skrivet i C++ med hjälp av OpenGL och GLFW. På grund av att vi ville få en lärorik fortsättning på det vi redan kunde samt att vi ville syssla med någon form utav grafikprogrammering, föll valet på att koda så mycket som möjligt från grunden. Därför tänkte vi från början inte heller använda oss utav några tilläggspaket. Objektinläsning En av de första saker som implementerades i projektet var en funktion som läser in obj- och mtl-filer, exporterade från 3Dstudio MAX. Vi valde att använda oss av obj-formatet då det är en av de lättare objektstrukturerna att hantera på grund av att informationen sparas i ASCII format och kan då öppnas i en texteditor. Vi skapade en klass som läser in obj filer och sparade alla trianglar, vertices, normaler etc. i ett VBO (Vertex Buffer Object).
Lila ljussfär som sänder ut blåaktigt ljus.Sponza Palace med alla hörnpunkter utritade i grönt.
Matematiska operationer Eftersom de allra senaste versionerna av OpenGL inte stödjer de inbyggda matrisoperationerna bestämde vi oss för att ha en egen klass som omfattar dessa. Vi började dock med att använda klassbiblioteket GLM för att först få ett fungerande program och få en uppfattning om vilka operationer som behövdes. Biblioteket innehåller matris- och vektoroperationer som t ex multiplikation, addition och olika projektioner.
Shaders I början av projektet hade vi ingen kunskap gällande shaderprogrammering, så vi började utforma Atril utan shaders. Under projektets gång fick vi mer kunskap om shaders och dess fördelar så att vi kunde implementera och tillämpa detta i Atril. Shaderprogramkoden skrevs i GLSL (Opengl Shading Language).
Shadow Mapping + Texture Mapping Stencil Shadow Volumes: Skuggor där volymen är utritad i rött men är fel i förhållande till det infallande ljuset.
Skuggor Det gjordes två försök att implementera skuggor. Ett utan Shaders med hjälp utav Stencil Shadow Volumes och ett försök med shaders genom Shadow Mapping. Det som fungerade bäst var det senare, vilket den slutgiltiga versionen använder sig utav.
Utskjutna sfärer testar kollisioner. Collisionmap: Tillverkad i 3ds Max och utritad i Atril.
Kollisionshantering Implementerat finns ett system för s.k. sphere-triangle collision detection. Beroende på syfte kan objekt omslutas av osynliga sfärer som kan kollidera med omgivningen (åsyftat collision map eller andra sfärer). Konsekvensen av kollision är ombytlig, och kan resultera i ny rörelsebana eller förhindrande av framkomst. "Collision maps" kan definieras i 3d-program och laddas in via Atrils objektinläsningsmetod. Sfärer kan initiera med radie, hastighet, position och riktning som parametrar.
Projektet har gått ut på att lära oss hur man skapar ett “figtning”-spel.
Vi har lagt mycket tyngd på att göra en bra motor för fighting-spel som ska kunna användas vid ett
senare tillfälle då det finns mer tid att lägga på bättre animationer och snyggare modeller.
Program som använts: Kända program:
-3DS Max
-Photoshop
Nya Program:
-Zbrush
-Unity3D
3DS Max:
Användes för att rigga och animera mesher som sedan importerats in i Unity3D. Även hitboxar
skapades i programmet.
Photoshop:
Användes för gui-komponenter.
Zbrush:
Zbrush är ett modelleringsprogram som påminner om att modellera lerfigurer. Här skapades
högpolygon mesher som sedan importerades till 3DS Max.
Unity3D:
Är en motor för 3D-simuleringar som kan tillämpas för att skapa spel och här sammanfördes alla
ljud, animeringar, effekter, scripts och bilder till vårt spel. Unity3D utnyttjar framförallt tre
programspråk för att att skapa scripter som används av skapade spelobjekt; Javascript, c# och boo.
I vårt projekt användes först c# men då vi inte fann relevanta tutorials för det till Unity3D så gick vi
över till javascript.
Implementerade funktioner: -Kollisionstest
-Projektiler
-Tid, vinnare deklareras efter att tiden tagit slut.
-Livmätare
-Block
-Slag
-Specialslag med sekventiell input
-Partikeleffekter
-Dynamiskt GUI
-Prioritet av dom olika rörelserna
-Actionbuffer, som lagrar de senaste inputsen en
viss tid
-Rörelser, hopp/dash osv.
-Kunna använda handkontroll
-Ljud
-Kombomätare
-Stuns
Användbara länkar: http://unity3d.com/support/documentation/ScriptReference/index.html
Bra och användbar dokumentation som finns för alla tre programspråk.
http://www.youtube.com/user/infiniteammoinc
Skön kille med lärorika videos.
http://www.youtube.com/user/BurgZergArcade
Förklarar på ett trevligt sätt hur man skapar ett spel från grunden i Unity3D.
Ghost in the hallwayGhost in the hallwayDepthbased sceneblending
Vårt projekt har gått ut på att använda bl.a. separat renderad djupinformation som hjälp för att skapa en övergång mellan två renderade scener. Animationen som vi skapat är ett spöke som flyger genom vår korridor och in i sovrummet. Spökets position i djupet bestämmer övergån-gen mellan den normala, eller “goda“, scenen och den “onda“ scenen. Vi har använt 3D Studio Max för att skapa och rendera ut våra scener, animationer och djupinformation för scenen samt animationerna.
För att skapa effekten vi var ute efter, från all den information vi renderat ut, så använde vi oss av Matlab. Vi började med att skapa övergången mellan den “goda” och den “onda” scenen innan vi lade in spöket. Vi använde oss av djupinformationen från spöket samt scenen för att bestämma position och utföra övergången. För varje steg i animationen beräknade vi spökets position i djupet, för att sedan räkna om övergången med den nya positionen. Alla dessa bilder sparades ner. Tillsist lade vi in spöket i den skapade animationen och samlade ihop alla separata animationer till en komplett film med hjälp av Adobe Premiere.
Av: Norbert Szabó, Tobias Johansson, Anton Lantz
TNM061 Projekt i CryENGINE
Vår projektgång har varit lång och krokig. Vi hade som ambition vid projektstart att göra någonting
med motion capture. Vår idé gick ut på att filma en sekvens där vi med lysdioder fastsatta på armen
rörde armen i ett mönster. Vi skulle sedan använda dessa ljuspunkter och programkod för att få ut
ett uttryck eller punkter för rörelsen i världen.
Vi började, kom en bit på vägen men insåg snabbt att det inte var så spännande som vi hade tänkt
oss. I samma veva släppte Crytek en uppdatering till sin SDK, även kallad Sandbox Editor, som för
övrigt är helt gratis vid icke-kommersiell användning. Många forum på nätet skrev om uppdateringen
och att den hade gjort SDKn lättare att använda och arbeta i. De flesta av oss har spelat Crysis och
ville titta närmre på verktygen Crytek använder för att skapa detta fantastiska spel. Därför ändrade vi
våran projektidé.
CryENGINE 3 Free SDK är utvecklat av Crytek, mest kända för sina skapelser i Crysis serien. Sandbox
använder What You See Is What You Play, den renderar i realtid i arbetsytan, vilket gör att du direkt
och enkelt kan se vad det du gör kommer ha för effekt i världen. Det mesta finns färdigt i Sandbox
vad det gäller fysik, ljussättning, script mm.
Länkar för nedladdning, se bilagor.
Det vi har jobbat med är modellering av objekt i 3DS Max / Maya som vi sedan exporterat till
Sandbox.
Världen Vår värld är skapad med en Terrain Editor i programmet där man skapar terräng, berg, slätter,
floddalar mm genom att ”rita” i världen. Marktexturer är bilder gjorda i photoshop eller tagna från
nätet och sedan modifierade. Vi har även använt en del texturer som redan finns i Sandbox. Ett
exempel på hur lätt Sandbox är att använda är att man kan ”måla” på sina egna marktexturer med
den så kallade ”Layer Painter”.
Världen i Sandbox En bild på världen och Sandbox interface. Som sagt tidigare så renderas arbetsytan i realtid, vilket
underlättar arbetet.
Huvud Vi hade tänkt ha med en modell av en människa och
började med huvudet, vilket visade sig vara mycket svårt.
Men vi kom i alla fall en bit.
Bilagor Nedladdning av Sandbox
www.crydev.net
Martin Nygren
Peter Pedersen
Mikael Pettersson
Christoffer Wern
Gustav Zaphf
TNM061 – 3D Datorgrafik Projektabstrakt Linköpings Universitet Louise Carlström ITN Malin Kylegård 2012-06-01 Jessica Larsson
Abstrakt
Projektet var från början tänkt att vara en film, men slutresultatet blev lite annorlunda. Det är en
början på filmen som vi egentligen ville ha. Det är 3 frukter med armar, ben, fötter och händer. De
har ögon med controller så blicken går att styra. De har en anpassad biped med physique-modifier.
Filmen är på under 30 sekunder och de dansar till låten ”I’m sexy and I know it”.
Figur 1 Våra tre modeller
Vi började med att sketcha på papper vår tänkta scen samt modeller. Sedan gjorde vi flera versioner
av modellerna i programmet 3Ds MAX för att testa oss fram. Vi märkte snabbt att modeller med få
polygoner var att föredra, detta trots att modellerna ej var komplicerade till att börja med.
Detaljerna till modellerna, såsom ögon, händer och skor gjordes i separata filer för att kunna
användas till alla modeller.
Ögonen skapades som sagt i en separat fil. Där även med controllers. Först skapades själva ögonen
med ögonlock och sedan pointers mitt i ögonen. En till controller med en box skapades för att
sammanlänka båda ögonen att titta på denna box. På detta sätt blir det enklare att styra vart ögonen
ska titta (även djup-mässigt) och inte bara i vilken riktning.
Vi bestämde oss för att använda den biped som finns i 3Ds Max eftersom våra frukter är tänkta att
göra väldigt människoliknande rörelser. Det var här de flesta av problemen uppstod. Dels riggningen
av bipeden och länkningen av controllers visade sig vara problematiskt. Orsakerna till svårigheterna
med riggningen var främst att huden inte följde med, även då vi manuellt anpassat envelopes i
physique modifiern till att inkludera alla vertices på modellen. Det var här vi upptäckte stora
skillnader mellan att länka, gruppera, och ”attacha” olika delar till varandra. Då vi länkat de olika
delarna av modellen till varandra fungerade det inte att konvertera till en editable poly vilket behövs
för att lägga en physique modifier. Detta fungerar heller inte då man grupperar delarna. Lösningen
visade sig vara att attacha delarna.
TNM061 – 3D Datorgrafik Projektabstrakt Linköpings Universitet Louise Carlström ITN Malin Kylegård 2012-06-01 Jessica Larsson Nästa problem var att koppla ögonen till kroppen. Det fungerade inte med ovanstånde metoder, dvs
länka gruppera eller attacha, för det gör att ögonen ”fryser fast” på kroppen och inte går att styra
längre. Det löste vi genom att länka pointern i ögat till bipeden.
Texturer har vi valt att göra i 3Ds MAX. Äpplet har en glänsande röd färg och en bump map med
väldigt stora bumps för att äpplet inte ska se ut som en sfär. Päronet är grönt med mycket mindre
bumps. Till sist har vi bananen som har en gul matt färg. Vi har valt att nöja oss med dessa enklare
texturer och istället lägga tid på riggning mm.
Som animeringsmetod har vi valt keyframing. Detta för att det verkat som den enklaste och
snabbaste metoden. Motion capture skulle kunna ha använts men det tror vi skulle tagit längre tid då
vi varit tvungna att lära oss det först. Det har dock varit lite knepigt att få till steg, ansiktsuttryck,
naturliga rörelser med ögon och armar samt mindre dans.
Face morphing. För att underlätta keyframing har vi använt oss av face morphing. En modifier där
man kan förbestämma olika ansiktsuttryck som man sedan kan välja mellan då man animerar. På
detta sätt är det enklare att återupprepa ansiktsuttryck. Face morphing är nog den sak vi inte haft
problem med!
Figur 2 Face morphing i 3ds MAX av mun och ögonbryn
Avslutningsvis. Vi har främst använt oss av det inbyggda hjälpbiblioteket i 3Ds Max och youtube.
Några länkar vi skulle vilja rekommendera till den intresserade är:
Bones: http://www.youtube.com/watch?v=MRikV-jTFfc
Eyes: http://www.youtube.com/watch?v=1GtwOdTV0qA
Face morphing:
http://www.youtube.com/watch?v=yqSR5yQoSgk&feature=related
Jonas Petersson Karl Johan Krantz Marcus Nygren Jonas Zeitler TNM061 Presentationsstöd - 2012-06-02
Inhibitor
En interaktiv 3d-upplevelse i webbläsaren
Inhibitor är namnet på en demonstration av hur man kan använda sig av realtidsrenderad 3d-grafik i
en webbläsare. Projektet har gått ut på att skaffa sig så mycket praktisk kunskap i området som
möjligt. Det vill säga sådan kunskap som kan omsättas direkt från arbetsbrief till färdig prototyp.
För att nå de mål och krav som vi satt upp har ett antal verktyg använts. Här nedan finns en väldigt
överskådlig bild av hur vi använt dessa verktyg.
Scengraf:
Precis som Java3D använder
openGL eller Direct3D använder
THREE.JS webGL.
3D API:
WebGL är ett API för att
rendera grafik från en
webbläsare direkt på
grafikkortet. WebGL är
baserat på OpenGL ES 2.0.
Programmeringsspråk:
Både THREE.JS och WebGL
använder JavaScript som bas.
Det kanske inte är världens
snabbaste språk men duger för
syftet.
Modelleringsverktyg:
3DS Max har används för
att skapa alla modeller
som syns i demot.
Jonas Petersson Karl Johan Krantz Marcus Nygren Jonas Zeitler TNM061 Presentationsstöd - 2012-06-02
På ett mer konkret plan har vi jobbar mycket med att lösa problem som uppstått i de olika delarna.
Dels implementationsproblem men också rent hantverksmässiga problem.
Skydomen
Formulering: Hur gör man en himmel i datorn?
Bakgrund: Vi har valt att använda oss av en
teknik som tillämpar en (något tillplattad)
hemisfär för att få illusionen av ett himlavalv.
Detta, eller skybox verkar vara standard.
Problemlösning: Största delen av tiden har
gått åt till att läsa på om hur man rent
hantverksmässigt tänker när man gör en
skydome.
Skogen
Formulering: Vi behöver en skog … din budget
är 400 polygoner.
Bakgrund: Det bör påpekas att det finns
färdiga träd-meshes i 3DS Max men dessa träd
består av ca 30000 polygoner.
Problemlösning: Skogen, som säkert skulle
kunna göra mer noggrant, består av plan som
korsar varandra för att ge en någorlunda
illussion av ett buskage. På dessa läggs en
transparent textur med 6 ekträd. En stor del
av tiden gick åt till att implementera detta i
THREE.JS eftersom det är så dåligt
dokumenterat. THREE använder sig av ett
briljant depth-test som kallas alpha-test som
kort sagt fattar att vissa modeller ska vara
transparanta även fast de ligger i samma
mesh.
Partikelsystem
Formulering: Det ska finnas en animerad
dammtuss.
Bakgrund: Partikelsystem är ett område vi ville
titta närmare på. En perfekt applikation av
detta är förstås att göra eldflugor och
dammtussar.
Problemlösning: Svårigheterna har egentligen
inte varit att modellera och implementera
partikelsystemen. Den stora utmaningen har
varit att animera partiklarna. Speciellt att
definiera behaviour för dem.
Kamerarörelser
Formulering: Kameran ska vara interaktiv men
den måste göra som vi vill också.
Bakgrund: Precis som i 3 dreams of black är
kamerarörelserna i Inhibitor väldigt viktiga. Vi
ville ge användaren en känsla av att ha lagom
mycket kontroll, ungefär som när man kör
radiobil på Gröna Lund.
Problemlösning: THREE har en del väldigt
schysta interpoleringsmetoder för
kamerarörelser men räcker tyvärr inte för våra
behov. En halvbra lösning som går ut på att
använda olika kameror för olika delar av
demot blev den slutliga. Skulle vi göra om
projektet så skulle vi nog ha försökt skriva våra
egna metoder för kameraförflyttning.
Niklas Fransson - nikfr357, Anton Albèrt Karlström - antal650, Max Jonsson - maxjo1337
3D – Squad presenterar TALOS (the awesome life of Stegusauron)
3D-Squad har snart kommit ut med ett nytt spel till marknaden, ni som är här idag kommer får se en
exklusiv gameplay teaser av vår banbrytande produkt som dock fortfarande är i utvecklingsstadiet.
I dagens samhälle så sitter människor framför datorn eller TV:n på kvällen för att koppla av. Vi har
därför skapat ett spel med visionen om att ge användaren det lugn som saknas i dagens samhälle.
Spelet heter THE AWESOME LIFE OF STEGUSAURON vilket helt enkelt går ut på att ta sig runt i en
harmonisk miljö och uppleva ett fantastiskt naturlandskap.
Fokus i 3D-Squads arbete har legat i att få ett spel att fungera på en annan plattform än Windows. Vi
har inte lagt ner mest tid på att göra spelet särskillt interaktivt utan istället gjort spelet enkelt och
funktionsdugligt. Detta gjordes för att ge spelet en bra grund som är lätt att fortsätta att bygga vidare
på.
Vi har i första hand arbetat i en utvecklingsmiljö kallad Unity 3D vilket är en färdig grafikmotor med
bland annat stöd för att bygga egna modeller, skriva script i Java/C# samt importera färdiga modeller
från till exempel 3DS Max.
Mycket av arbetet har utförts i 3DS Max där vi har, förutom att modellerat figurer, utforskat
möjligheterna att animera korta filmsekvenser vilka vi har använt till spelet.
Problem vi stötte på var framför allt vid importering av figur till Unity 3D.
RÅTTAN AV Veronica Börjesson Karolin Jonsson Sara Eriksson Emma Hesseborn Fagerholm Idé Vår grundidé när vi började projektet var att skapa en kortfilm. Ursprungligen skulle det vara en kuslig film -‐ med mycket atmosfär och objekt. Snabbt kom idén om att ha en råtta som med tiden gick från biroll till huvudfigur. Filmen skulle innehålla två scener. Scen 1 visades råttans intåg i rummet och scen 2 dess upptäcktsfärd från råttans point-‐of-‐view. Vi började med att skapa objekt och ett rum. Den animerbara råttan gjordes som ett sidospår/experiment under tiden som vi inte visste om vi skulle använda än. Sedan lades mycket fokus på kamerarörelser, animationer och effekter som vi tyvärr aldrig riktigt fick till. Objekt och Helheten Rummet skapades och fylldes med objekt. Eftersom huvudscenen skulle vara ur råttans perspektiv skapade dettas både möjligheter och problem. Vi kunde t ex lägga fokus på att möblerna skulle se bra ut från råttans perspektiv istället för att göra ordentliga proportioner och heltäckande material (se bild 1). T ex har pianot inget material på tangenterna och soffan är väldigt stor dels för att se bra ut från råttans POV och dels för att ge plats för kameran att filma under den.
bild 1) Rummet ovanifrån.
Kamerarörelser Vi valde att använda oss av keyframes för att animera kamerarörelserna. I scen1 ser man hela råttan utifrån medan scen 2 är gjort ur råttans point of view. Vi fäste då råttans huvud vid kameran så det följde med rörelserna. Det som var svårt var att efterlikna råttans exakta rörelser – Det var svårt att göra t ex vaggande rörelser som såg verklighetstrogna ut. Depth of Field Eftersom en råtta är väldigt närsynt i verkligheten så ville vi göra så att råttan (kameran) såg klart på nära håll och suddigt på långt håll. Trots många försök fick vi inte fram något bra resultat (se bild 2), även z-‐buffermetoden gav tveksamma resultat (se bild 3). Vi beslutade istället att undersöka möjligheter att lägga på sådan effekt i after effects.
bild 2) samma bild, olika DoF inställningar , ingen skillnad
bild 3) 3ds max testbild för Z-buffer metoden Råttan Då den animerbara råttan var klumpig att använda valde vi att göra två modeller. En riggad att ha på håll och en statisk att använda ur råttans POV. Då behövde inte den animerbara råttan vara så noga modellerad heller.
Råttan – den animerbara Stegen för att skapa den animerbara råttan var följande: att skapa en modell, skapa ett matchande skelett (se bild 3), rigga och fixa skinningen (dvs koppla hörnpunkterna till rätt skelettben, bild 4), lägga på JK solvers och slutligen animera rörelser. Att animera rörelser var det i särklass mest tidskrävande, och därför utnyttjades inte råttans fulla kapacitet i scen 1. Det var även i vissa fall besvärligt att koppla rätt hörnpunkter till rätt ben samt ge dem en bra vikt. Att det fanns enstaka hörnpunkter som stack ut när man rörde modellen var ett vanligt problem.
bild 3) Råttan med skelett (svans ej med pga platsbrist)
bild 4) Råttan – skinning. Vertices kopplade till ett ben. Notera hur det högra örat är felkopplat (gult område) då örat inte borde tillhöra mittenpartiet. Råttan – huvudet Huvudet är oproportionerligt stort (bild 5) men detta är för att råttans POV ska se bra ut. Kameran är förälder till huvudet vilket gör att råttan följer med kameran (likt ett vapen i ett 1st person shooter). Stora problemet med denna modell var pälsen gjord med Hair & Fur modifieraren. Den skulle behöva stylas,
och ibland ställde ljuset till det (se bild 6) och pälsen blev självlysande och reagerade inte på inställningarna. Att ta bort hair paramters från ljuskällor kunde dock i vissa fall lösa det problemet.
bild 5) Snygg i filmen – ful i verkligeheten
bild 6) Självlysande päls Om vi hade haft mer tid och vetat bättre skulle vi ha:
• Fixat Depth of Field • Gjort ett bättre golv, det var
väldigt tråkigt att upptäcka att golvet inte såg ut som det skulle när vi ändrade ljuset.
• Lagt mer fokus på material som är bra på nära håll.
• Gjort klart modellen för råttan INNAN vi riggade den.
• Animerat nosryckningar och morrhår på råtthuvudet.
• Stylea pälsen och göra den snyggare samt förbättra renderingen av den (både kvalité och tid).
• Mer spännande händelser (tex råttan klättra upp på pianot och gå på tangenterna)
Modellering och animering av utomhusscen Målet med arbetet var att få bredare kunskap om olika metoder att modellera, animera, rendera och
efterbehandla för att få så verklig återskapning av en utomhusmiljö som möjligt. Med facit i hand kan
man sammanfatta upplevelsen med att vissa saker som upplevs lätta kan vara svåra att åstadkomma,
medan andra avancerade effekter ger ett bra resultat med relativt lätta åtgärder.
Mark: Marken har inte i sig varit speciellt viktig för slutresultatet. Lite kullar och sänkor inverkar men eftersom det till stor del täcks av gräs läggs inte så mycket fokus på att få till en bra jordtextur.
Gräs: Gräsets utseende har desto större inverkan på slutresultatet och är något vi lagt mycket tid och fokus på att få bra. Generellt gäller det att få variation i storlek riktning och utseende mellan olika grässtrån för att inte få en allt för homogen gräsyta.
Träd med löv: Vi har modellerat ett antal träd för att få olika utseende på dem, träd som återkommer med jämna mellanrum blir lätt väldigt störande. Även löven har vi använt avancerade material och effekter för att få ett snyggt reslutat.
Ljussättning: Ljussättningen har en väldigt stor roll i hur slutresultatet blir. Vi har använt oss av en Vray-sun där vi
testat oss fram bland inställningarna för att nå det utseende vi strävat efter.
Animation: Vi var tidigt inne på att vi ville simulera verklig vind. Vi har löst problemet med att få löven att ”blåsa
till” med noise animation i kombination med soft selection.
Arbetet utfört av: Anton Arbring, Ramin Assadi, August Ek, Oscar Johnsson, Carl Philip Matsson.
2012-06-02 TNM061 Johan Dagvall Jonas Görling Kahin Akram Marcus Gabrielsson Tobias Johansson Ramnäs
Ogre Burger Castle Crusade
Vi har gjort ett spel med hjälp av en
grafikmotor som heter OGRE (Object-Oriented
Graphics Rendering Engine) som är gratis och
kodas med C++. Till spelet har vi skapat
animationer i Blender, medan själva scenen är
modellerad i 3ds Max.
Grundtanken med projektet var att skapa ett
spel med tangentbord/mus styrning (fps) med
kameran i tredje person och interaktion
mellan objekt (fysik).
Terrängen gjordes för hand med en funktion i
3ds Max som heter soft selection, som gör att
man kan flytta en vertexpunkt så att de
närliggande vertexpunkterna följer med. Detta
gjorde dock att vi fick onödigt många
vertexpunkter detta löste senare när vi märkte
att spelet laggade med en funktion i 3ds Max
s.k. Optimize, den gjorde dock så att texturen
på vissa ställen ser lite konstig ut.
Vi har använt oss av två gratismodeller till
spelet, en ogre som styrs av spelaren och ett
skelett som fiende.
I början hade vi stora problem med att få
igång kollisionshanteraren OGRE bullet,
eftersom den var optimerad för Visual Studio
9. Men till slut med lite hjälp lyckades vi få
resultat.
Efter det plockade vi in vår terräng, som
består av en borg, ett hus, en grotta och några
träd och applicerades kollisionshanteraren på
dessa objekt.
Efter det återstod bara funktioner för att få
spelet att fungera som vi ville med att kunna
skjuta etc.
Matematisk visualiseringTomas Forsyth Rosin och Emil Axelsson
I våras !ck vi frågan från Olof Svensson och George Baravdish om vi ville göra interaktiva visualiseringar av innehållet i ITN:s kurser i "ervariabel- och vektoranalys, TNA006 och TNA007. Eftersom analys i "era variabler lämpar sig väldigt bra att visualisera med gra!k i tre dimensioner såg vi vår chans att arbeta med visualiseringsprojektet i kursen i 3D-datorgra!k.
Ett viktigt designmål har varit att skapa en så lättillgänglig 3D-applikation som möjligt. Detta i kombination med att vi båda har stort eget intresse för webben, gjorde att vi valde att genomföra projektet i WebGL. Efter att ha läst igenom några in t roducerande ar t ik la r om WebGL på l e a rn ingwebg l . com och e f t e r l i t e ege t experimenterande, insåg vi att någon form av framework med stor sannolikhet skulle göra livet enklare för oss. Vi valde att basera vårt projekt på Three.js - ett framework som tillhandahåller verktyg som en scengraf, en smidig abstraktion för a t t s k i c k a d a t a t i l l g r a!k k o r t e t s a m t grundläggande vektoroperationer.
MatematikFör att kunna göra lite matematisk visualisering är det bra om programmet bakom har en någorlunda vettig intern representation av matematiska uttryck.
Figur 1Uttrycksträd – så här sparas information om matematiska uttryck och funktioner.
För att rita funktionsytor behöver man kunna lagra funktioner och för att rita tangentplan behöver man kunna derivera. Vi vill även
kunna bilda funktioner utifrån användarens inmatning. En inte helt obetydande del av arbetet
har därför, även om det inte har någon klockren koppling till 3D-datorgra!k, handlat om att jonglera med matematiska utryck. Denna del av programmet har ett gränssnitt som tillåter oss att sedan göra:
var expr = CALC.parse(‘sin(x)*cos(y)’);var dzdx = expr.differentiate(’x’);
GeometriVårt program behöver kunna rita upp matematiska objekt såsom kurvor, ytor och vektorer. För att rita en funktionsyta behöver vi bygga ihop en samling polygoner utifrån våra matematiska uttrycksträd. Detta görs genom att beräkna funktionsvärden med jämna steg i x- och y-led. Därefter sammanfogas dessa punkter till fyrhörningar, som kan skickas till gra!kkortet för rendering. Parametriska ytor kan göras på liknande sätt, men här behöver x-, y- och z-värden b e r ä k n a s u t i f r å n a t t s t e g a i g e n o m parameteriseringens de!nitionsmängd.
Figur 2Tesselering av funktionsyta
För att i förlängningen kunna visualisera även vektorfält (det får bli en senare utmaning) är det bra om vi kan rita vektorpilar på ett smart sätt. Om en vektorpil byggs upp av trianglar, men ska ändra längd dynamiskt för varje frame som renderas, måste primitiverna "yttas stup i sekunden. För att avlasta CPU:n från att behöva köra onödigt mycket javascript, har vi experimenterat lite med vertex-shaders för att ändra på vektorers längd.
2012-06-01
AnimationEn viktig byggsten i våra visualiseringar är rörelse. Vi tror att mjuka rörelser då objektet man studerar roteras är ett måste för att den bortskämde betraktaren ska orka fortsätta använda vår visualisering. Jämna rörelser minimerar också risken att användaren tappar fokus från det vi strävar efter att visualisera. Vi har därför jobbat med ett verktyg vi kallar scheduler, som har stöd för att köa händelser på varandra såväl som att generera mjuka interpolationer mellan två lägen. En intressant frågeställning har varit huruvida schedulern ska räkna tid i sekunder eller i frames. Vi har i nuläget valt att räkna frames, vilket har fördelen att om renderingen stannar upp i en bråkdels sekund kommer ”!lmvisningen” att fortsätta där den stannade. Å andra sidan riskerar förloppet att ta farligt olika lång tid på olika datorer. En möjlig medelväg vi har diskuterat är att under körningen ta fram ett medelvärde på datorns fps, och anpassa alla rörelser därefter.
Figur 3Schedulerns möjlighet att interpolera mellan värden med hjälp av olika ease-funktioner
RenderingThree.js har en stor uppsättning färdiga material, som gör det enkelt att rendera ytor med exempelvis Phongshading. För att rendera funktionsytor på ett lämpligt sätt har vi dock valt att skriva en egen shader, som vi kapslat in i ett material vid namn CheckerMaterial. Den tillåter att färgen skiftar beroende på ytans z-värde, samt lägger till ett schackrutigt mönster som gör det lättare att få en uppfattning av hur lång en längdenhet är.
Om objekt dyker upp i en scen helt plötsligt utan att tonas fram, tror vi att det kan ha en viss disorienterande effekt på användaren. Därför vill vi gärna kunna ändra opaciteten hos alla våra objekt helt fritt. Här stötte vi på ett ganska stort problem, som vi bara lyckats lösa delvis. Z-buffern i OpenGL fungerar inte som vi naivt hade hoppats på. Om två fragments med alpha mindre än 1 ska renderas på samma xy-koordinat kommer den bakersta att inte renderas alls om den främre råkar renderas först. Detta beror på att z-bufferns värde uppdateras vid den första renderingen, varpå det bakre fragmentet kommer att kastas bort. Genom att alltid skicka in primitiver till vertex-shadern i
en sådan ordning så att primitiver långt bort från kameran kommer först, går det att påverka ordningen på fragment-renderingen. Men hur gör man det om man vill tillåta att kameran "yttar sig hela tiden?
Figur 4Svårt fall för en stackars fragment shader som inte vet så mycket
Problemet är för oss fortfaranade olöst om två halvtransparenta objekt ligger både framför och bakom varandra, som i !gur 2. Däremot har vi löst problemet för en ensam transparent yta som skymmer delar av sig själv. Genom att vid tesseleringen av ytan generera 6 olika ordnade meshar (en från varje sida på en kub) och byta ut dessa när kameran "yttar sig kan man uppnå önskad effekt.
InteraktionEtt viktigt designmål är att skapa ett ramverk som gör det enkelt att programmera nya speci!ka visualiseringar av olika matematiska begrepp. Att bygga ett ramverk för interaktion som uppmuntrar till mycket återanvändning av kod, men som ändå tillåter skräddarsytt beteende då det behövs, är för oss en stor utmaning. Ett grepp vi har tagit till för att göra systemet "exibelt är designmönstret Strategy, som tillämpas genom att vi när som helst i en visualisering kan ”ge” ett nytt verktyg åt användaren. Vänster musknapp kan i ett fall välja en punkt på en yta och i ett annat fall användas för att rotera scenen. Även om ytterst få Strategies vid det här laget är implementerade, hoppas vi att detta grepp kommer göra det enkelt för oss att fortsätta att utveckla programmet.
Andra interkationsfrågor som ligger närmare till hands i en kurs i 3d-datorgra!k är hur zoom och rotation ska fungera. Vi har valt att designa rotationsverktyget så att ”camera roll” inte är tillgängligt, så att användaren slipper hamna upp och ned när hon dessutom kämpar med att förstå vad ett tangentplan är för något. För att zooma har vi provat att använda Three.js’ kamerors !eld of view-parameter, till skillnad från att translatera kameran. En fördel är att man aldrig riskerar att ”zooma igenom” ytor, medan en nackdel är att perspektivet ser mystiskt ut då man zoomar ut väldigt mycket.
2012-06-01
3D – datorgrafik:TNM059
Martin Stengård Markus Waltré Tobias Palmér
Insane European Epatractorgame 2.0 Collectors edition
Sammanfattning Vi har ämnat skapa ett bilspel med realistisk fysik där användaren får fritt interagera med världen. Det finns utlagda uppgraderingar och flertal funktioner är inbyggda.
3D – datorgrafik:TNM059
Process Vi utgick från att arbeta i ett program som hanterar 3dmiljöer vid namn Ogre3D. Till detta kopplade vi samman en fysikmotorn ogrebullet som är en specialversion av bulletphysics anpassad för just Ogre3D. Mycket arbete lades på att implementera ogrebullets bibliotek i Ogre3d, något som inte gjordes lättare genom att dokumentationen var så gott som obefintlig.
Sedan fokuserade vi på att få fysiken för bilen realistisk. Detta gjordes genom att använda funktioner som hanterar motorkraft på hjulen som i sin tur flyttar bilen. Nästa stora steg var att få en ”collisionbox” på världen som vi skulle använda. Vi skapade en värld med hjälp av 3dprogram som Cinema 4D och 3ds max. Sedan använde vi ett plugin som kunde exportera .mesh filer som ogre stödjer. För att få material på våra objekt skrev vi .material-‐filer.
Till själva bilen laddade vi ner en färdig modell som vi sedan styckade upp i de delarna vi behövde för olika ”collisionboxes” och element.
Spelet Det som finns som gör att det efterliknar ett spel är dels en bil med full interaktiv rörelse. En miljö med vägar samt en start-‐ och stoptext som möjliggör ett varv. För texterna har vi en ”detect collision” som vid kontakt startar en klocka för varvet. När man sedan kommer till ”finish”-‐texten stoppas klockan och man har kommit i mål. För att göra banan lite mer spännande finns det en ”powerups” längs vägen som man kan ta samt en och annan ramp för hopp.
För att ge användaren information om bilen och hur det går finns det en ”dashboard” som visar vilken hastighet man kör i, vilken växel man är i samt hur lång tid man har kört på banan.