TNM0613D-gra�k

Projektredovisningar 2012-06-02

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.

Projekt Desert Fighters

Av Oskar Havsvik, Jonas Gerling och Rickard Gräntzelius.

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.