Domeniul de licență Informatică [301850]

[anonimizat] 3D [anonimizat]: [anonimizat]. univ. dr. Maria Miroiu Ivașcu Adelin

Pitesti, 2016

[anonimizat]- de obicei referind la o imagine creată de un calculator ajutat de hardware și software specializat. Este o vastă specializare din informatică. [anonimizat] s-au petrecut în prima jumătate a secolului douăzeci.

Capitolul 1 intitulat “Jocuri Video” [anonimizat].

Capitolul 2 intitulat “Motoare Grafice” listează motoarele grafice folosite în industrie pentru crearea atât jocurilor cât și efectelor speciale în filme și imagini. Conține un scurt istoric al evoluției acestora.

Capitolul 3 numit “Unreal Engine” [anonimizat].

În capitolul 4 “Graphics Processing Units” este vorba despre partea esențială rulării oricărui motor grafic și anumite cipul grafic care are sarcină de a randa imagina pe ecran în timp real pentru că utilizatorul să poată vedea ce editează.

Capitolul 5 “Prezentare UDK” cuprinde elementele kitului de dezvoltare Unreal Development Kit.

Iar capitolul 6 “Prezentarea Aplicatiei” [anonimizat] a acesteia.

Capitolul 1

Jocuri Video

1.1 Evoluție

Istoria jocurilor video datează încă din anii 1950, când informaticienii din academii au început să creeze jocuri simple și simulatoare ca partea a lucrării lor de cercetare. Jocurile video nu au ajuns la nivel popular până în anii 1970 și 1980, [anonimizat], alături de grafica pe ecranele computerelor și computerele de uz casnic au fost introduce publicului larg.

“Consola Atari 2600 alături de controllerul acesteia- 1977”

Încă din 1980, jocurile video au devenit o formă populară de divertisment și o parte a culturii modern în multe părți ale lumii. Unul dintreprimele jocuri create a fost Spacewar care a fost dezvoltat de un informatician. Primele jocuri de tip arcade au fost realizate între anii 1972 și 1978. Pe parcursul anilor 70’ [anonimizat].

“Jocul Pong si cabinetul Arcade al acestuia”

Perioada de aur a jocurilor Arcade a fost din 1978 până în 1982. [anonimizat]. Consolele erau mai ieftine și puteau fi jucate de către deținători pe propriul TV. Cele mai populare fiind Atari 2600 și Intellivision. În anii 80’ se dezvoltă și piața jocurilor pe PC și apare primele jocuri online. [anonimizat] 1983 are loc o cădere a pieței jocurilor video care a fost revitalizată apoi de Nintendo în 1985 cu popularul Nintendo Entertainment System sau NES.

“Nintendo Entertainment System (NES) 1985”

În prezent consolele se află în a opta generație acestea venind de la 3 mari comapnii: Nintendo, Sony și Microsoft. Consolele de pe piață sunt : Playstation 4, Xbox One, WiiU , Nintendo 3DS și Playstation Vita, ultimele 2 fiind portabile. Piața jocurilor pe PC este și ea destul de mare mulțumită în special serviciului de distribuire Steam care prin ofertele săptămânale au reușit să fie distribuitorul numărul 1 al jocurilor în format digital de pe piață. Mai sunt alte servicii de distribuire digital pe PC precum Origin, al celor de la Electronic Arts, Uplay al companiei Ubisoft și Gog al dezvoltatorului de jocuri CD Projekt.

“Cele 3 console principale de pe piață: Xbox One, Playstation 4 si WiiU”

Dacă în trecut marea mândrie a consolei era pe câți biți poate rulă (8 biți, 16 biți, 32 de biți, etc) aceastia însemnând câte culori poate afișa consola pe ecran șic ate de avansate pot fi efectele 2D, acum totul se bazează pe rezoluție și detalii grafice.

“Super Mario Bros. NES- 8 biti” “Super Mario World SNES- 16 biti” “Super Mario 3D World- WiiU”

1.2 Controverse

Încă de la început jocurile video au fost blamate pentru foarte multe lucruri rele care s-au petrecut în societate. Au fost considerate vinovate pentru comportamentul agresiv al celor care le joacă. Încă de la începutul anilor 80’ cei care sunt pro jocuri video au pus accentul pe el ca fiind un mod de liberă exprimare, în schimb cei care sunt împotriva lor le consideră nocive și trebuiesc să fie controlate și restricționate. Efectele pozitive și negative ale jocurilor video sunt și acum subiect pentru studii științifice. Rezultatele multor studii arată legătura dintre dependență, agresivitate, violență, și subdezvoltare socială, și o varietate de comportamente care instigă la stereotipizare, dar acestea încă sunt dezbătute.

1.2.1 Studiu

Asociația Divertismentului Software (Entertainment Software Association) raportează faptul că 17% dintre jucători sunt băieți cu vârstele sub 18 ani și 36% sunt fețe sub 18 ani, cu 48% dintre jucători în general fiind femei de toate vârstele. De altfel un raport menționează că vârstă medie a jucătorului este de 31 de ani. Un studiu făcut pe 1102 de copii cu vârste cuprinse între 12 și 17 ani a realizat că 75% dintre părinți au verificat dacă jocul respectiv este sau nu bun pentru copilul sau înainte să îl cumpere. Dintre acești copii, 14% dintre fete și 50% dintre băieți au dorit să cumpere jocuri care interzise copiilor.

1.2.2 Depententa

Dependența de jocurile video este un comportament excesiv și compulsive prin care o persoană are problem cu viața coditiana din cauza jocurilor video. Au fost raportate instanțe în care jucătorii se izolează de familie și prieteni și orice altă formă de contact social pentru a se concentra doar pe completarea jocurilor inloc de a-și trăi viața.Primul joc care a atras atenția politicienilor ca fiind prea captivant a fost jocul Arcade Space Invaders.

“Jocul Arcade Space Invaders din 1978”

Un studio făcut la Universitatea Chung Ang a observant că structurile creierului afectate de folosirea jocurilor video include cortexul cingulat anterior și cortexul orbifrontal. Resultatele experimentului sugerează o crește a stimulării în acele zone, arătând un tipar similar cu celedate de consumul de subtante care dau dependent.

1.2.3 Digital Rights Management

Digital Rights Management (DRM) este o tehnologie care a fost creată să controleze utlizarea conținutului digital și a dispozitivelor dup ace au fost cumpărate. Multe companii folosesc DRM pentru a preveni încălcarea drepturilor de autor și a proteja o proprietate intelectuală de a devein accesibilă publicului. Cei care se opun sistemului motivează asta prin faptul că această măsură nu face altceva decât să incomodeze utilizatorul care a cumpărat produsul și lasă companiile mari să stagneze inovația șiș a oprească competiția.

DRM-ul permanent , cunoscut și sub numele de autentificare online persistentă, este un tip controversat de DRM folosit în cazul jocurilor video. Acesta obligă consumatorul să aibă o conexiune constantă la un server pentru a-și utiliza produsul.

1.2.4 Religia și Jocurile Video

În timp ce religia e văzută ca o topică serioasă, jocurile video sunt considerate doar divertisment. Din cauza asta, utilizarea religiei și a motivelor religioase în jocurile video poate fi uneori controversată. De exemplu, Hitman 2: Silent Assassin a pornit o controversă din cauza unui nivel care consta în uciderea Sikh-urilor într-o depictie a locului lor sacru, Harmadir Sahib, unde sute de Sikh au fost masacrați în 1984.

1.3 Piața Independentă

Piață independentă jocurilor video se referă la dezvoltatorii de jocuri sau console care sunt formați în studiouri mici și care nu sunt finanțați de nicio corporație ci din sponsorizări independente sau site-uri care ajută astfel de dezolvatori precum Kickstarter sau Indie Go Go.

“Kickstarter, site-ul prin care dezvoltatorii indie sunt ajutați de oameni simpli pentru a-și atinge visul”

1.3.1 Console Independente

Ouya

Ouya este o consolă independentă creată de Julie Uhrman de la Ouya Inc. (cunoscuți sub numele de Boxer8) și sponsorizată prin Kickstarter. Sistemul de operare este pe bazat pe Android. Proiectul a costat 8.5 milioane de dolari fiind al cincilea cel mai bine finanțat proiect de pe Kickstar. Pe 28 Martie 2013 consolele au fost distribuite celor care au donat bani iar pe 25 Iunie a fost pusă pe piață.

Consola suportă de la început Twitch.tv și playerul media XBMC și folosea o versiune modificată de Android 4.1 Jelly Bean și i se poate face root(o metodă de hack specifică Android) fără a se pierde garanția.

Ca specificații hardware consola are:

Quad Core ARM Cortex A9

1GB DDR3 SDRAM

8GB memorie internă

Nvidia Tegra ca processor grafic

“Consola Ouya”

Open Pandora

Open Pandora este o consolă portabila independent și un computer personal portabil în același timp lansată în 2008. A fost concepută pentru a profita de software-ul gratuit și open source și să fie un produs pentru dezvoltatorii de astfel de software. Include câteva caracteristici pe care nicio altă consolă nu le are făcând-o pe această o combinație între o consolă și un notebook.Rulează pe versiune completă de Linux.

Specificațiile consolei sunt:

OMAP3530 600Mhz Cortex A8 ca processor alături de un co-procesor TMS320C64x+ de 430Mhz

256 MB low power DDR-333 RAM

512MB stocare cu 2 slot-uri de cardurid e memorie SDHC, plus USB.

“Consola Open Pandora”

1.3.2 Jocuri Independente

Braid

Braid este un joc de tip platformer cu elemente puzzle creat de Number None Inc. A fost lansat în August 2008 pe XBOX 360 prin serviciul XBOX Live Arcade. Portari ale acestuia au apărut pe Widnows în Aprilie 2009, OS X în Mai 2009, Playstation 3 în Noiembrie 2009 și Linux în Decembrie 2010.

Expoziția jocului e simplă, Tim care este personajul principal, încearcă să salveze o prințesă de un monstru.Acțiunea jocului este de dată de numeroasele obstacole pe care Tim trebuie să le depășească într-un fel sau altul folosind abilitatea de a manipula timpul.

“Jocul Braid- 2008”

Minecraft

Minecraft este un joc de tip sandbox creat de programatorul suedez Markus “Notch” Persson și mai apoi dezvoltat și publicat de Mojang. Jocul se bazează pe talentul artistic al fiecărui jucător în a construi orice folosind cuburi generate într-o lume 3D. Alte activități constau în explorare, adunarea de resurse, crearea de obiecte pornind de la materie primă și combat. Mai multe moduri de joc sunt prezente precum Survival Mode unde jucătorul trebuie să adune resurse să construiască lumea și supraviețuiască, Creative Mode în care jucătorii au resurse nelimitate să contruiasca ce vor ei și un Adventure Mode în care jucătorii pot încerca hărți create de alți jucători.

“Jocul Minecraft- 18 Noiembrie 2011”

Capitolul 2

Motoare Grafice

Un motor grafic e un framework software destinat creării și dezvoltării jocurilor . Dezvoltatorii îl utilizează pentru a crea jocuri pentru consolă ,dizpozitive mobile. Funcționalitatea principală a motorului constă în motorul propriu de randare pentru grafica 2D și 3D ,un motor de fizică sau detectare de coliziuni,sunet,scriptare,animații,inteligență artificială,networking,streaming, management de memorie,threading,localizare,graph-ul scenariului și poate conține suport video.

“Exemplu tipic de motor grafic”

Dezvolatrea jocurilor e mai ușoară prin reutilizarea motorului și a elementelor acestora ,fie pentru a crea genuri diferite de jocuri, fie pentru a fi mai ușor de portat pe alte platforme.

Scopul principal al motoarelor este a oferi o gamă variată de unelte de dezvoltare împreună cu capacitatea de a reutiliza componentele software. Aceste unelte sunt puse la dispoziție într-un mediu de dezoltare integrat(IDE) pentru a permite o dezvoltare rapidă, simplificată a jocurilor într-o manieră object oriented.

Creatorii motoarelor de dezvoltare îl scriu cu elemente prefăcute pentru a fii la dizpozitia dezvoltatorului când își începe proiectul,acestea având suport pentru sunet,grafică, fizică și I.A. Denumirea acestora în industrie este "middleware" deoarece sunt mijloace flexibile și reutilizabile care oferă toate nevoile de bază care reduce enorm costul dezvoltării,complexitatea acesteia și timpul pe market.

Motoare populare pentru crearea jocurilor includ:

Unreal Engine;

Gamebryo;

JMonkey Engine;

AnvilNext;

CryEngine;

Dunia Engine;

“Dunia Engine”

“Cryengine si Unreal Engine”

“Anvi Next”

Ca majoritatea soluțiilor middleware, motoarele permit abstractizarea platformei, permițând unui joc să ruleze atât pe console cât și pe PC fără a face mari modificări în cod.

De multe ori ele vin cu capacitatea de a extinde unele părți ale sistemului pentru a include alte componente software, precum motorul fizic Havok ,Miles Sound System pentru sunet și Bink pentru video-uri.Motorul RenderWare de exemplu a fost creat și o serie de componente middleware conectate superficial care pot fi combinate la alegerea dezvoltatorului.Însă extensibilitatea rămâne un aspect important al motoarelor datorită multiplelor moduri în care ele pot fi aplicate.

În ciudă numelui motoarele pot fi utilizate pentru alte domenii cum ar fi arhitectură, antrenare în armată și modelarea mediului.

Unele motoare oferă doar capacități de randare 3D în timp real , acestea depinzând de dezvoltator pentru a integra celelalte componente. Acestea se numesc"motoare grafice","motor de randare" și "motor 3D".Motoarele moderne oferă un graf scenic care arată reprezentarea unei lumi 3D în formă object-oriented care de multe ori simplifica design-ul jocului .

Cu cât îmbătrânește tehnologia, componentele motorului devin învechite sau insuficiente pentru necesitățile unui proiect iar costul programării unui motor complet nou poate rezultate în amânări inacceptabile , echipă de dezvoltare fie vor updata motorul ei înșiși sau vor alege un motor nou conform nevoilor.

Componentele unui motor reprezintă un framework cu obiective diferite.

Programul jocului

Unde se află logica implementată de algoritmi.

Motorul de Randare

Motorul generează animații 3D printr-o metodă aleasă (raytracing, rasterization,etc.)

În loc să fie programat și compilat pentru a fi executat pe CPU și GPU direct, majoritatea timpului randarea se face prin API-uri , cum ar fi Direct3D sau OpenGL care permit o abstractizare software pentru GPU.

Librării low-level precum DirectX ,SDL și OpenGL sunt utilizate pentru a oferi acces independent de platformă pentru alte componente hardware cum ar fi dizpozitivele de input (keyboard,mouse,controller),carduri de rețea, sau plăci de sunet. Înainte graficii 3D accelerate prin hardware ,software-ul de randare a fost utilizată.

Randare prin software încă este utilizată în unele unelte de modelare sau imagini generate pentru o acuratețe vizuală care e prioritară performanței în timp real(FPS) sau când hardware-ul nu are suport pentru unele tehnici, cum ar fi shader-ul.

Motoarele de jocuri pot fi scrise în limbajele de programare C,C++,Java sau C#,însă fiecare limbaj are structură diferită și poate avea nivele de acces diferite pentru funcții specifice.

Motorul Audio

Componenta responsabilă pentru algoritmii de sunet. Poate calcula lucruri pe CPU sau pe un ASIC dedicat, sau API-uri de abstracție cum ar fi OpenAL ,xAudio 2,etc.

Motorul Fizic

Responsabil pentru emularea legilor fizicii prin algoritmi în aplicație.

Inteligență Artificială

Este scris printr-un modul special de către dezvoltatorii prin cunoștințe de specialitate.

2.1 Istoric

Înaintea motoarelor grafice, jocurile erau create ca entității singulare, create de la 0 pentru display-ul la alegere, numit kernel de către dezvoltatorii retro.Constrângerile de memorie au împiedicat un design bazat la greu pe date mari .

Arcadele au condus la atitudinea de a scrie codul apoi renunțând complet la el pentru a putea utiliza resursele în plus. Astfel, până în anii 80 arhitectura era bazată pe un sistem bazat pe mașină cu nivele puține și grafică prin date.

Deși nu exista conceptul de motor grafic existau sisteme de create a jocurilor 2D ,cum ar fi Pinball Construction Set, ASCII's War Game Construction Kit ,Thunder Force Construction , Adventure Construction Set ,Garry Kitchen's GameMaker, Wargame Construction Set ,Shoot'Em-Up Construction Kit(1987),Arcade Game Construction Kit, și RPG Makerele ASCII din 1988 încoace.

Motoarele grafice sunt printre cele mai complexe programare scrise , având o mulțime de sisteme interacționând cu o precizie controlată de utilizator. Evoluția constantă a motoarelor a creat o separare puternică între randare, scriptare, artă și design-ul nivelului,rezultând în mai mulți artiști în echipe comparativ cu programatorii.

Threading-ul a devenit un aspect foarte important datorită sistemelor de mai multe nuclee și creșterea cerințelor pentru realism. Threadin-ul e utilizat pentru randare, streaming, audio și fizică. Jocurile de curse utilizează această tehnică pentru motorul de fizică rulând într-un thread separat cu mult inainte celorlalte subsiteme.

Deși majoritatea motoarelor sunt scrise cu limbaje low level (C și C++) ,mai nou motoarele au început să fie scrise în limbaje de nivel înalt cum ar fi Java și C#(TorqueX siVisual3D.NET) sau Python(Panda3D).Cum majoritatea jocurilor 3D depind de GPU, încetinirea posibilă datorită limbajelor acestora devin neglijabile și conduc la o productivitate crescută.

Texturile

Texturile sunt imagini folosite în Materiale,acestea fiind mapate asupra Materialele pe care sunt aplicate. Ele fie sunt aplicate direcft ,(Base Color textures) sau prin valorile pixelilor Texturii(texels) sunt utilizate în Material ca și măști sau alte calcule.

În unele instanțe Texturile pot fi utilizate extern într-un program de ediate imagine, cum ar fi Photoshop, apoi importate în Unreal Editor prin Content Browser.

Unele Texturi sunt create în Unreal ,cum ar fi Texturile de Randare(Render Textures). Acestea iau informtii din scenă și o randeaza pe o Textură să fie utilizată altundeva.

Un singur mateial poate utiliza mai multe texturi care sunt mostre și pot fi utilizate în scopuri diferite , cum ar fi un material care Base Color texture , o textură Specular sau o mapa normală. Poate să existe o mapa pentru Emissive și Roughness stocată în canalele alpha pentru una sau mai multe texturi.

Unreal Engine

UE a fost dezvoltat de către Epic Games, arătat prima data în 1998 în FPS Unreala,această fiind specializarea motorului , însă acesta este capabil și de alte genuri, cum ar fi stealth, MMO și RPG-uri.Codul aplicației a fost scris în C++, permițând un grad de portabilitate ridicat.

Cea mai nouă versiune suportă DirectX 11 și 12,(Microsoft Windows, Xbox One, WindowsRT);OpenGL(OSX,Linux,ps4,iOS,Android,WindowsXP);Vulkan(Android);Metal(iOS) și JavaScript/WebGL(HTML5).

2.2 Istoria motorului

Unreal Engine 1

Debutul în 1998 , scris în C++,UnrealScript și Assembly, avea intregrata randarea, detectarea coliziunilor, AI,networking, scripting și sistem de file management într-un genine complet.

Venise cu un sistem software de rasterizare și o cale de randare accelerată-hardware folosind Glide API, dezvoltat specific 3Dfx GPU-urilor și a fost updatat cu OpenGL și Direct3D, marcată de lansarea Unreal Tournament.

Motorul devenise popular datorită arhitecturii modulare ale acesteia și includerea unui limbaj de scriptare numit UnrealScript care a permis modare ușoară.

“Primul Unreal Engine”

Unreal 2

Această generație a avut codul și motorul de randare complet schimbat, venind cu un editor de nivele numit UnrealED 2 care debutase în versiunea anteriora și apoi urmat de UnrealEd 3 , împreună cu SDK fizic Karma .

Motorul acesta fizic a permis fizică de "păpuși" în Unreal Tournament 2003 și 2004. Alte noutăți erau support pentru Xbox și Gamecube ,însă doar Xbox era suportat direct de Epic rezultând în licențiați modificând motorul pentru mai multe nevoi și generații, cum ar fi Wii, X360, PS3, PSP și 3DS.

UE2.5 ,un update pentru versiunea originală, a îmbunătățit tehnologia de randare și performanță aceștia și a adăugat fizică pentru vehicule,un editor de particule și suport 64-bit pentru UT 2004.

“Unreal Engine 2”

Unreal Engine 3

Scris în C++, C#, UnrealScript, GLSL, Cg, HLSL, a fost prezentat pentru prima data în 2004 , fiind deja în dezvoltare pentru 18 luni și venind cu suport complet pentru shaderii DirectX 9 , calculele fiind făcute per pixel spre deosebire de per vertex și vene cu suport pentru randare gamma-corect de distanță dinamică mare.

Inițial cu suport doar pentru Windows , X360 și PS3, în timp ce Android și iOS au fost adăugate în 2010.

Tehnicile de randare includeau HDRR, per-pixel lightning și umbre dinamice.

În 2011 s-a inclus suport pentru Adobe Flash Player 11 prin Stage 3D API-uri.

Engine-ul a marcat o creștere a licențierilor cum majoritatea companiilor nu erau pregătite pentru era HD .

Primul joc a fost Gears of War pentru consolă și Roboblitz pentru PC.

În durata de viață a motorului multe îmbunătățiri au fost incorporate , cum ar fi illuminare globală, zone destructibile, soft body dynamics, simulare de mulțimi mari,integrare Steamworks ,iluminare globală în timp real.

Suportul DirectX 11 a fost demonstrat cu demo-ul Samaritan, care a fost creat de Epic împreună cu NVIDIA, inginerii din toată țara impingang grafica la un nou nivel.

Motorul a fost folosit și în serialul de copii LazyTown pentru a creă orășelul în șine, actorii fiind incluși prin green screen. FBI-ul a licențiat UE3 pentru simulările de antrenare.

Din Februarie 2015 UE3 nu mai e suportat de Epic, dar poate fi folosit în continuare până în 2020.

Unreal Development Kit(UDK)

Deși modarea era posibilă încă din prima versiune, crearea și vinderea jocurilor se făcea pur prin licență până în Noiembrie 2009, când s-a anunțat o versiune gratuită a UDK-ului pentru public.

În Decembrie 2010 UDK-ului îi s-a adus suport pentru iOS .

“Unreal Engine 3 pe iOS si Android”

Unreal Engine 4

Motorul a fost dezvoltat de Tim Sweeney din 2003 până în 2008 singur, fiind țintit către generația 8 de console , PC și Android.

Dezvăluirea acestuia limitată a fost făcută în 2012 la Game Developers Conference și un video cu demonstrarea motorului a fost lansat publicului în Iunie 2012.Acest Demo a rulat pe 3 GTX 580 și pe PC putea rulă pe un singur 680.

Inițial motorul venea cu iluminare globală în timp real în tehnică voxel cone tracing, dar datorită puterii limitate a consolelor a venit cu o tehnică similară dar mai puțin complexă.

Un alt aspect al motorului e modificarea codului C++ în timp ce rulează motorul. Noul sistem "Blueprint" , un sistem de scriptare vizuală permite dezvoltarea rapidă a logicii jocului fără a utiliza C++ și permite debagare în timp real. Rezultatul e o scădere a timpului iterației și o diviziune mai mică între artist tehnic, designerii și programatorii.

Conform lui Allan Willard:"Dacă trebuie să schimbi logică de damage pentru un inamic și armă ar fi putut dură zile datorită timpului de compilare de 15 minute , dar cu modificările recente timpul de compilare s-a redus la 30 de secunde , abilitatea noastră de a rula și a vedea cum merge jocul este mult mai rapidă."

În 2014 la GDC motorul a fost dezvăluit publicului și cu el lansarea unui nou tip de subscripție, toate unelte și codul sursă C++ fiind disponibil dezvoltatorilor. Această schimbare , conform lui Tim Sweeney. "reflectă schimbarea în industrie a modului de lucru. Ne-am dat seamă că e o unealtă învechită și am început de la 0 cu idea:"Cum putem face motorul să fie disponibil pentru cât mai mulți oameni.""

Subscripția poate fi anulată oricând și uneltele pot rămâne în mână dezvoltatorilor dar nu vor primi update-uri sau acces la noile UE4.

În septembrie 3 2014 , Epic a lansat Unreal Engine Marketplace, permițând licentiatolor UE4 sa cumpere și să vândă materiale create de comunitate de toate varietățile. Marketplace-ul venise cu artă, medii create, personaje, obiecte, sunete, animații și cod C++ cu un număr mare de materiale de alte tipuri precum demo-uri ieftine și tutoriale.

În Septembrie 4 2014 epic a lansat UE4 studenților și universităților gratis, pentru specializările de dezvoltare a jocurilor , știință calculatoarelor, artă, erhitectura, simulare, și vizualizare ale programelor.

UnrealScript

Fostul limbaj nativ de scriptare utilizat în crearea logicii jocului și evenimentele de gameplay înainte de lansarea Unreal 4.A fost creat pentru programare simplă la nivel înalt în jocuri. Este similar cu limbajul unui al limbaj de scripting ZZT-oop.

Similar cu Java, UȘ era orientat pe obiecte fără moștenire multiplă(toate clasele moșteneau de o clasă Obiect comună) și clasele erau definite în fișiere separate .Spre deosebire de Java, nu avea object wrappers pentru tipuri primitive.Interfețele erau suportate doar în UE3 și puțin în UE2. Suportă supraincarcareea operatorilor dar nu și supraîncărcarea metodelor.

În 2014 Epic a anunțat că UE4 nu va mai suporta Unreal Script dar va suporta C++ pentru scripting. Scriptarea vizuală se face prin Blueprints Visual Scripting, o înlocuire pentru sistemul Kismet folosit anterior.

“Unreal Engine 4”

Capitolul 4

Graphics Processing Unit

Putem discuta oricât despre motoare grafice și grafică pe calculator în general,dar componenta esențială care face ca această să apară pe ecran este Graphics Processing Unit (GPU) sau cum este cunoscută mai des: Placa Video.

Scurt Istoric

Acelerarea graficii prin hardware a început odată cu sfârșitul sistemului de țevi,mai întâi rasterizand liniilor de scanare ale unui triunghi.Generațiile următoare de hardware au lucrat iar cu sistemul de țevi, astfel încât algoritmi de nivel înalt al aplicațiilor de stare au fost comise la acceleratorul grafic. Singurul avantaj care îl are hardware-ul față de software e viteză, dar viteza este critică în grafică.

În ultimul deceniu, hardware-ul grafic a suferit o transformare incredibilă. Primul cip grafic pentru consumatori a inclus procesare vertex prin hardware(NVIDIA Geforce256),lansat în 1999.

Nvidia a venit cu termenul graphics processing unit(GPU) pentru a diferenția GeForce 256 de versiunile anterioare de cipuri cu rasterizare, și numele a devenit comun în industrie.În următorii ani , GPU-ul a evoluat de la o implmentare configurabilă a sistemului de țevi cu funcție fuxia într-un șir e sloturi programabile pentru dezvoltatorii pentru a implementa proprii algoritmi.

Shaderii programabili de tipuri diferite sunt sursă principală prin care este controlat GPU-ul. Shader-ul vertex permite operații variate(tranformarii și deformări) care pot fi aplicate asupra fiecărui vertex. Similar shader-ul de pixel procesează individual pixelii.

Shader-ul de geometrie permite GPU-ului să creeze și sa distrugă primitivii geometrici(puncte, linii,triunghiuri) pe loc. Valorile calculate pot fi scrise în multipli buferri de precizie înaltă și pot fi reutilizat ca și vertex sau data de textură. Pentru eficientă, unele părți din sistemul de țevi rămâne configurabilă nu programabilă, dar trend-ul este care programabilitate și flexibilitate.

Implementarea sistemului de țevi pentru randare în GPU are următoarea ierarhie:

-Vertex shader;

-Geometry shader;

-Clipping;

-Screen mapping;

-Triangle Setup;

-Triangle Traversal;

-Pixel Shader;

-Merger;

GPU-ul implementează geometria și rasterizarea conceptuală a sistemului de țevi prezentat. Acestea sunt separate în multiple stadii ale hardware-ului cu grade diferite de configurabilitate și programabilitate.

Shaderul vertex este un stadiu complet programabil care este utilizat de stadiile funcționale "Model and View Transform", "Vertex Shading," și "Projection".Shaderul de geometrie este un stadiu opțional,complet programabil care operează pe vectorii unei primitive(punct,linia sau triunghi). Poate fi utilizat pentru a face operații de shadin per-primitive, pentru a distruge primitive sau de a creă unele noi.

Stadiile de clipping, screen mapping,setupul de triunghi și tringhiul tranversal sunt stadii funcții-fixe care implementează stadiile de funcție cu aceleași nume.Similar cu vertexul și shaderii de geometrie, shaderul de pixel este complet programabil și se aplică în stadiul funcției de "Pixel shading".

În final , the stadiul de merger îs undeva între complet programabil în stadiul shaderilor și operație fixă în alte stadii. În ciuda faptului că nu este programabil, este ușor configurabil și poate fi aplicat unei varietăți mari de operații. Bineînțeles ,se implementează stadiul funcțional "Merging", care are are rolul de a modifica culoarea, Z-buffer,blend-ul,stencil și alte buffere reletive.

De alungul timpului ,sistemul de țevi al GPU-luia evoluat de la codarea pe mașină și mai mult către felxibilitate și control. Introducerea stadiilor programabile de shaderii a condus la cel mai important evoluției.

Stadiile de shader moderne(cele care Shader Model 4.0,DirectX 10) folosesc un nucleu de shader comun, astfel shaderii de geometrie,pixeli si vertex impart un model de programare.

Nucleul shader comun este un API, shaderii unificați fiind o capacitate a GPUlui.Primele GPUri aveau mai puțin în comun când venea vorba de vertex și pixel shaderii și nu aveau shaderii pentru geometrie.În ciuda acestui fapt, elementele se află în hardware-ul vechi, doar mai simplu sau lipsind, fără a fi complet diferit.

Shaderele sunt programate printr-un limbat de shading că și C-ul cum arf fi HLSL,Cg și GLSL.Acestea sunt compilate cu un limbaj independent de mașina de asamblare, numit și limbaj intermediat.Modele anterioare ale shaderelor permiteau programarea directă în limbaj de asamblare, dar cu DirectX10 programarea în acest fel este visibilla doar prin outputul debugului.Acest limbaj de asamblare este convertit la limbaj de mașină într-o etapă separată ,deobicei în drivere. Acest aranjament permite compatibilitatea între mai multe implementării hardware.Libajul de asamblare poate fi considerat că definind o mașină virtuală fiind ținta limbajului de compilare a shaderului.

Mașina virtuală este un procesor cu o varietate de tipuri de regiștrii și sourse de date, programat cu un set de instructiiuni.Cum multe operații grafice se fac prin vectori scurți(lungime maximă 4), procesorul are un SIMD(single-instruction multiple-data) de 4 căi .Fiecare registru are 4 valori independente. Scalari de floating-point single-precision de 32-bit și vectorii au tipuri de date simple, suportul pentru integerii de 32-bit au fost adăugați recent.

Vectorii floating-point conține date precum poziții(xyzw),normale,rânduri din matrice, culori(rgba) sau coordonatele texturilor(uvwq).Integerii au fost folosiți cel mai mult pentru reprezentarea contoarelor,indicilor sau măștilor de biți.Tipuri de data agregate cum ar fi structurile, arrayurile și matricile sunt și ele suportate.

Pentru a lucra cu vectorii,swizzling, replicarea oricărei componente ale vectorului e și ea suportată. Elementele vectorului sunt rearanjate sau duplicate cum se dorește.Similar, măscărea, unde numai vectori specifici sunt utilizați ,este și ea suportată.

Un draw call invocă grafica APIlui pentru pentru a desenă un grup the primitivie, sistemul de țevi grafice executanduse. Fiecare stadiu al shaderului programabil are două tipuri de inputuri: uniforme, cu valori cara rămân constante în timpul draw callului(poate fi schimbat între draw calluri), și cu inputuri variate, diferite de fiecare vertex sau pixel procesat de către shader.

O textură este un tip special de unitate uniformă care a fost odată o imagine colorată aplicată asupra unei suprafeti, dar acum poate fi gândită ca și arrayuri de date mari.Este important sa se noteze că shaderele or avea o mare varietate de inputuri , putând fi apelate în diferite feluri,outputs-urile sunt extrem de constrânse.Această e cea mai mare distincție între shadere și programre care executând pe procesoare generale. vine cu regiștri speciali pentru diferite de inputuri outputuri.

Inputurile uniforme acessate prin regristii constanți bufferi constanți read only , numiți așa pentru datele constante timpul draw callului.Numărul de regiștrii constanți valabili este decât numărul de regiștrii valabili pentru veritatile de inputuri outputuri.

Acest lucru se datorează datorită nevoii de separat fiecare vertex pixel, inputuri uniforme stocate odată refolosite toate verticele pixelii dintr-un draw call. are regiștrii temproarii de utilizare .

Toate tipurile de registrii pot fi indexati prin array utilizand valori integer in registrii temporari.Inputuri si outputurile pentru shaderul masinii virtuale poate fi explicate astfel:

Shader Virtual Machine

<–Varying Input registers(16/16/32 registers)

<–>Temporary registers(4096 regiters)

–>Output registers(16/32/8 registers)

<–Constant registers(16 buffere pentru 4096 registrii)

<–Textures(128 array of 512 textures)

Operatiile care sunt comune in calculele grafice au eficiente in executare pe GPUrile moderne.Tipic cele mai rapide oepratii sunt scalare si multiplicarile vectorilor, adunarile si combinările acestora, cum ar fi adunări multiple și produsul înmulțirilor. Alte operații precum recprocal, pătratul,sinus, consinus,exponentiarea și logaritm tind să fie mai costisitoare dar au o viteză destul de bună.

Operațiile de texturizare sunt eficiente, dar performanța lor poate fi limitată de factori precum timpul petrecut așteptând după rezultatul unui access.Limbajil de shading expune cele mai comune dintre aceste operații(cum ar fi adunările și înmulțirile),restul fiind funcții intrinsice, atan(),dot(),log() și multe altele.Funcțiile intrinsice există pentru operații mult mai complexe , cum ar fi normalizarea vectorului și reflecțiile, produsele în cruce, transpunerea matricilor și determinant.

Termenul de flow control se referă la utilizarea unei ramuri de instrucțiuni pentru a schimbă curse execuției codului. Aceste instrucțiuni sunt utilizate în implementarea constructorilor de limbaj înalt cum ar fi "if" și "case", și tipurilor variate de loop-uri.

Shaderii suportă două tipuri de flow control:

Static Flow control

Ramurile sunt bazate pe valorile inputurilor uniforme, adică cursul codului este constant în timpul draw callului.Beneficiul primar pentru acest tip de control este capacitatea aceluiași shader să fie folosit într-o varietate de situații(număr variat de lumini).

Dynamic Flow Control

Este bazat pe valorile variate ale inputurilor. Este mai puternic decât static flwo control dar și mai costisitor,în special dacă cursul codului se schimbă eratic între invocările shaderului.Cum un shader este evaluat pe un număr de vertice și pixeli pe rând.

Dacă cursul alege ramură de if pentru unele elemente și else pentru alte elemente, ambele ramuri trebuiesc evaluate pentru toate elementele(și ramură nfolosite pentru fiecare elemente este ignorată).

Programele de shaderii sunt compilate offline înainte de a se încărca programul sau în timpul rulării. La fel că și orice alt compilator , există opțiuni pentru generarea diferitelor fișiere de output și pentru utilizarea diferitlor nivele de optimizare.Un shader compilat este stocat că și un strîng de text fiind apoi tranferat în GPU printr-un driver.

Evoluția Programării Shaderelor

Idea unui framework pentru programarea shadingului datează încă din 1984 prin Cook's shade trees.Un shader simplu și shader treeul acestuia este arătat astfel:

Limbajul RenderMan Shading a fost dezvoltat din această idee în anii 80 și este utilizat în continuare în randarea producției unui film.Înainte de shadere programabile suportate de GPU nativ, au fost mai multe încercări de a implementa operații de shading programabile în timp real prin mai mulți pași de randare.Limbajul de scripting în Quake II:Arena a fost primulcu succes comercial răspândit în 1999.

În 2000 Peercy a descris un sistem care traducea shaderii RenderMan pentru a rulă pe mai mulți păși în grafica hardware.GPUlui îi lipseau două componente pentru a face acest lucru posibil: abilitatea de a folosi rezultatul calculelor că și coordonate ale texturilor (dependent texture reads ) și suport pentru tipurile de date cu un randament și precizie extins în bufferele de texturi și culori.One din tipurile de date propuse a fost o nouă(pentru acel timp) reprezentare de 16 bit floating point.Majoritatea GPUrilor aveau sistemele de țevi foarte configurabile ,dar nu suportau shadere programabile.

GeForce 3 în 2001 a fost primul GPU care a suportat shadere de programare vertex expuse prin DirectX 8.0 și extensii la OpenGL.Aceste shadere erau programate într-un limbaj de tip assembly care convertea driverele în microcod pe loc.Shaderele de pixeli erau includei DX8 dar pixel shaderul SM 1.1 încă nu era cu adevărat programabil – programele limitate suportate erau convertite în stării de blending a texturii prin driver, care la rândul ei erau legate împreună de "register combiners" hardware.Aceste programe nu erau doar limitate în lungime(12 instrucțiuni sau mai puțin) dar le lipsea cele două elemente(dependent texture reads și float data) care Peercy identificase că și cruciale programabilității adevărate.

Shaderii în această perioda nu permiteau flow controlul, astfel conditionalele trebuiau emulate prin calcularea atât termenilor și selectării sau interpolării între rezultate. DirectX a definit conceptul de Shader Model pentru a distinge hardware-ul cu capacități de shader diferite. GeForce 3 a suportat modelul de vertex shader și pixel shader model 1.1(shader model 1.0 era intenționat pentru hardware că nu a mai fost lansat).În parcursul anului 2001, GPUrile au prograsat spre un model de programare a shaderelor pentru pixeli mai general.

DirectX8.1 a adăugat modele 1.2 spre 1.4 pentru pixel shader(fiecare pentru hardware diferit), care a extins capacitățile shaderului de pixel mai departe, adăugând instrucțiuni în plus și suport general pentru dependent texture reads.

2002 a fost anul lansării DirectX 9.0 care a inclus Shader Model 2.0 și exteniile sale, care conțineau shaderii complet programabili pentru vertex și pixel.Funcționalitatea a venit și sub OpenGL prin mai multe extensii. Suportul pentru dependent texture reads arbitrare și stocarea valorile 16 bit floating point a fost adăugat, în sfârșit satisfăcând cerințele lui Percy .

Limitele asupra resurselor shaderului cum ar fi instrucțiunile, texturile și regiștrii erau mai , astfel shaderele efecte complexe. Suportul pentru flow control fost adăugat el.Creșterea lungimii complexității shaderelor create cu modelul de limbak assembly deveniseră greoaie.

Din fericire DX9.0 inclus un nou limbaj de shader numit HLSL(High Level Shadin Language).HLSL fost dezvoltat de Microsoft colaborare cu NVIDIA ,care lansat o cross platform Cg. același timp ARB(Architenture Review Board)-ul lui OpenGL lansat un limbaj similar numit GLSL.Aceste limbahe erau influențate de design—ul limbajului de programare C inclus elemente din RenderMan Shading language.

Shader Model 3.0 fost introdus 2004 fost îmbunătățire , capacități opționale devenind , crescând limitele resourselor adăugând suport limitat pentru citirea texturilor vertex shader.

Când-lansat o generație de console 2005(Xbox360) 2006(PS3) au venit cu Shader Model 3.0, cu fixed function GPU Wii-ul de la Nintendo .

Alte limbaje medii pentru dezvoltarea shaderelor valabile. De exemplu, limbajul Sh permite generare combinarea shaderelor GPU printr-o librărie C++.Acest proiect open source rulează pe un număr de platforme. La celalt avem o mulțime de unelte de programare care permit artiștilor(care nu comfortabilit cu limbaje de programare C) de face design la shadere.Aceste unelte includ editoare de graf visuale folosind un link predefinit de blocuri de construcție shaderelor , compilatoare care traduc rezultatul grafului limbaje de shading precum HLSL.

Exemplu:

“Un graf al shaderului”

Următorul pas important a venit în 2007, Shader Model 4.0 (incluși în DX10.0 și valabil în OpenGL prin extensii), a introdus mai multe îmbunătățiri, cum ar fi stream output și geometry shader.

Shader Model 4.0 a inclus un model de programare unform pentru toate shaderele(vertex,pixel și geometry), nucleul de shader cmun descris anerior. Resursele au crescat și mai mult și suportul pentru tipuri de date integer(incluzând operații bitwise ) a fost adăugat. Shader Model 4.0 are suport pentru limbajele de nivel inaqlt pentru shadere(HLSL pentru DirectX și GLSL pentru OpenGL)- nefiind o interfață de limbaj de asamblare care poate fi scris de utilizator, cum a fost în modelele anterioare.

Producătorii de GPU,Microsfot și ARB continuă să rafinee și să extindă cpacitatile de programare ale shadingului.Pe lângă noi APIuri , noi modele de programare cum ar fi CUDA lui NVIDIA și CTMul lui AMD au devenit ținte pentru aplicații non grafice.

În ciudă îmbunătățirilor, dezvoltatorii trebuie să suporte hardware care folosește tipuri vechi de modele shading.Din acest motiv vom face o comparație scruta între capacitățile mai multor modele de shading: 2.0,3.0 și 4.0.

Ne vom concentra asupra DirectX, deoarece are lansării distincte , spre deosebire de evoluția extensiilor OpenGL, fie de la ARB sau comform producătorului. Acest sistem de extensie are avantajul că orice capacitate de ultima oră de la un vender hardware independent(IHV) poate fi utilizat imediat. Direct X 9 și modele anterioare suportă IHV prin expunerea unor biți de capacitate care pot fi examinați de GPU pentru a permite o funcțiune.

Odată cu DX10 Microsoft s-a îndepărtat de această practică spre un model standardizat care trebuie suportat de totuți IHV.În ciudă acestei concentrări asupra lui DirectX, ce vom descrie mai departe va avea relevanță și pentru OpenGL.

Tabelul din continuare compară capacitățile mai multe modele de shader.

În Tabel "VS" vine de la vertex shader și "PS" vine de la pixel shader(Shader Model 4.0 a introdus shade de geomertrie, cu capacități similare shaderului de vertex).Dacă nici VS sau PS apăr, se aplică și la vertex și la pixel shader. Cum mașină virtuală e un SIMD de 4 căi , fiecare registru poate stoca între una sau patru valori independente.

Sloturile de instrucțiuni/Instruction Slots se referă la numărul maxim de instrucțiuni care poate conține shaderul.

"Max Stepts Executed"indică numărul maxim de instrucțiuni care pot fi executate , luând ramficiarea și ciclurile în calcul.

"Temp.Registers" arată numărul de regiștrii generali care sunt valabili pentru stocarea rezultatelor imediate.

"Constant Registers" indică numărul de valori cosntante care pot fi inputul unui shader.

"Flow Control,Predication" se referă la abilitatea de a calculă expressi condiționale și de a execută cicluri prin instrucțiuni de arbore și preziceri(abilitatea de a execută condiționat sau a sări o instrucțiune)

"Textures" numărul de texturi distince care fi acesate de shader (fiecare sahder poate fi acesat de multe ori).

"Integer Support" se la abilitatea de face operații pe de date integer cu operații bitwise integer.

"VS Input Registers" numărul de regiștrii de input care fi acesate de shaderul de vertex.

"Interpilator Registers" are regiștrii de output pentru shaderul de vertex regiștrii de input pentru shaderul de pixel. Se numesc așa datorită valorilor de outptu de la shaderul vertex care se interpolează tringhiului înainte de fi trimis către pixel shader.

"PS Ouput Registers" numărul regiștrii care fi output de la shaderul de pixel- fiecare asignat unui buffer diferit unei ținte de randare.

Shaderul Vertex

Primul stadiu în sistemul de țevi funcțional . Deși este primul stadiu care procesează grafica, vom notă că manipularea datelor poate să se facă înainte de acest stadiu.În input assemblerul de la DirectX , un număr de streams de data pot fi combinate împreună pentru a formă seturi de vertice și primitivi care sunt trimise pe țeava.

De exemplu, un obiect poate fi reprezentat de un array de poziții și un array de culori.Input assemblerul crează tringhiurile obiectului(sau linii sau puncte) prin creare verticelor de poziții sau culori.Un alt obiect ar putea folosi același array sau un array diferit de culori pentru reprezentare. Există suport pentru input assembler pentru a instanția, permițând unui obiect să fie desenat de un număr de ori cu date variate pe instanță cun singur apel de desenare.

Input Assemblerul din din DX10 marchează fiecare instanță, primitivă și vertex cu un număr de identificare care poate fi acesat la oricare etapă a shaderului care urmează.Pentru modele mai vechi de shader datele trebuiau adăugate explicit modelului.

Un mesh de tringhi este reprezentat de un set de vertice și informații în plus descriind care vertice formează fiecare tringhi.Aceste date nu sunt valabile shaderului de vertex ,acesta ocupanduse exclusiv de verticele care vin. În termeni generali, shaderul de vertex vine cu o cale de a modifică ,creă și ignoră valorile asociate cu pvertexul fiecărui poligon , cum ar fi culoarea, normalul, coordonatele texturii, și poziția. În mod normal prgramul vshaderului de vertex tranforma verticele de la un model spațial spre un spațiu clip homogen,minim, un shader de vertex trebuie să facă output-ul în această locație.

Această funcționalitate a fost introdusă în 2001 cu DirectX8 . Deoarece era primul stadiu în sistemul de tenvisi invocat relativ infrecvent, putea fi implementat de GPU sau CPU, care ar trimite apoi rezultatele la GPU pentru rasterizare.

Tranziția de la hardware-ul vechi la cel nou a fost pentru viteză nu pentru funcționalitate. Toate GPUrile produse acum suportă shadingul vertex.

Shader de vertex însuși are nucleul comun pentru mașină virtuală descris mai devreme. Fiecare vertex care trece este procesat de programul shaderului, care după acea face output pentru un număr de valori care pot fi interpolate în jurul unui triunghi sau linia.Shader de vertex nu poate nici creă vertice sau a le distruge , rezultatele generate de un vertex nu poate fi transferat la un alt vertex. Cum fiecare vertex este tratat independent ,orice număr de procesoare de shader pe GPU poate fi aplciat în paralel cu un stream de vertice care or să ajungă.

Vom descrie în continuare efectele de vertex shader, cum ar fi shadow volume creation, vertex blending pentru animarea jointurilor și randarea siluetei, și lens effects(ecranul apăra că e sub apa, prin ochii unui peste).

Alte efecte:

-Object definition, prin crearea unui mesh o singură data și poate fi deformat de shaderul de vertex;

-Object twist, bend și operații taper.

-Procedural deformations, cum ar fi mișcările hainelor, apei,etc.

-Primitive creation, prin trimiterea meshurilor degenerate pe sistemul de țevi și li se da o arie după necesitate. Această funcționalitate este unlocuita de shaderul de geometrie în noile GPUri.

-Îndoirea pagînilor,efectele de căldură, undele de apa, și alte efecte pot fi executate prin întregul frame al conținutului bufferului că o textură pe un ecran aliniat de procedura de deformare a meshului.

-Recuperarea texturii vertex poate fi folosită pentru a aplică texturile la meshurile vertex, permițând suprafețele coeanelor înălțimea terenurilor fie aplicate cu cost minim.

Exemple de deformări:

Outputul unui vertex shader poate fi consumat într-un număr de moduri diferite. Caleea generală este pentru că fiecare instanță a tringhiului să fie generată și rasterizata, and fragmentele produce ale fiecărui pixel individual să fie trimis la pixel shader pentru a continuă procesarea. Cu introducerea Shader Model 4.0 , datele se pot trimite către shaderul de geometrie, trimis prin stream

sau amândouă.

Shaderul de Geometrie

Shaderul de geometrie este adăugat pentru grfica acelerata hardware prin sistemul de țevi odată cu lansarea DirectX 10 în 2006. Este localizat imediat după shaderul de vertex în sistemul de țevi și utilizarea acestuia este opțională.

Inputul pentru shaderul de geometrie este un singur obiect și este asociat cu verticele .Obiectul este tipic un triunghi într-un mesh, o linia din segment sau un simplu punct.Primitivele extinse pot fi definite și procesate de către shaderul de geometrie.În particular,trei vârfuri înafară unui triunghi pot fi transferate și două obiecte adiacente pe o linie poly poate fi folosită.(Figură 3.6)

Shaderul de geometrie proceaza primitive și scoate zero sau mai multe primitive. Outputul este în formă de puncte,polylinie și bezi de triunghiuri.Mai mult de o singură bandă de triunghi poate fi outputul unei singură invocări ale programului shaderului geometric.De notat, shaderul geometric poate avea output 0.Astfel, meshul poate fi modificat selectic prin editarea verfurilor, adăugarea unor noi primitive și înlăturarea acestora.

Programul shaderului de geometrie este setat la inputul unui singur tip de obiect și outputul un singur tip de obiect, astfel aceste tipuri nu corespund.De exemplu, un tringhi poate fi input și centroizi poate fi output că și puncte, per inputul unui triunghi.Chiar dacă inputul să outputul tipului obiectelor e identic , datele tranferate la fiecare vârf poate fi omis sau expandat.De exemplu, planul normal al unui triunghi poate fi calculat și adăugat la fiecare output al datelor vârfului.Similar cu shaderul de varfm shaderul geometric trebuie să aibă un output un spațiu homogen clip pentru fiecare vârf produs.

Shaderul geometric garanteza că rezultatele outputului de la primitive sunt în aceași ordine că și cele de la input. Acest lucrur afectează performanță, doararece dacă numărul de unități de shader rulează în paralel , rezultatele vor fi salvate și ordonate. Că un compromis între capacități și eficientă, exita o limită în Shader Model 4.0 de 1024 de valori 32 bit care pot fi generate per execuție .Astfel generarea a o mie de tufișuri primind că și input o singură frunză nu este fezabil și nu este recomandat în utilizarea shaderului geometric. Teselarea suprafețelor simple în meshuri thingiulare mai elaborate nu este recomandat. În acest stadiu este vorba mai mult de programabilitatea modificării datelor care vin sau crearea unui număr limitat de copii, nu amplificarea sau replicarea masivă a acesteia. De exemplu , una este folosită pentru a genera șase copii de date tranformate în ordine spre a le randă simultan cu șase de cubara.Algoritmi adiționali care folosi avantajul or shaderul geometric include crearea unor particule de mărimi variate din date de puntc, creare unor fire pentru randarea blănii găsirea muchiilor obiectului pentru algoritmi de umbre.

Stream Outputul

Utilizarea standard pentru sitemul de țevi al GPUlui este de a trimite date prin shaderul de vârfuri, apoi să rasterizeze rezultatele tringhiurilor și procesarea acestora în shaderul de pixel. Datele erau de neatins în sistemul de țevi și nu erau posibile rezultatele intermediare.Idea unui stream output a fost introdusă în Shader Model 4.0.După ce vârfurile sunt procesate de către shaderul de vârfuri(opțional, de shaderul geometric), acestea pot fi output într-un stream, adică un array ordonat apoi trimis spre stadiul de rasterizare. Rasterizarea poate fi oprită cu totul și conductă poate fi folosită că un procesor de stream non grafic.Datele procesate în acest fel pot fi trimise înapoi în conductă, permițând procesarea iterativa. Acest tip de opratie este în particular folositor pentru simularea apei curgătoare sau alte efecte de particule.

Pixel Shaderul

După shaderii de vârfuri și geometric își fac operațiile, primitivele sunt clipate și sunt pregătite pentru rasterizare.Fiecare triunghi este traversat și valorile vârfurilor interpolate deasupra ariei tringhiului.Pixel shaderul este pasul următor programabil.În OpenGL acest stadiu este cunoscut că shaderul de fragment, idea fiind că tringhiul acoperă fiecare celulă al unui pixel complet sau parțial.și materialul este opac sau transparent.

Rasterizarea nu afectează direct culoare pixelului stocat, dar mai degrabă generează date care descriu cum să acopere tringhiul celulă pixelului.În timpul mergului datele fragmentului este folosit pentru a modifică ce este stocat la pixel.

Outputurile shaderului de vârfuri devin inputurile pixel shaderului, efectiv. 16 vectori (de valoare 4 fiecare) sunt transferați de la shadrul vârfului la pixel shader în Shader Model 4.0.Când shaderul geometric este utilizat poate avea un output de 32 de vectori la pixel shader.

Alte inputuri sunt adăugate specific pentru pixel shader cu introducerea SM 3.0.De exemplu, care parte a triunghiului este vizibilă este adăugat că și flag de input.Această informație este importantă pentru randarea materialului diferit în față versus spate al fiecărui triunghi într-un singur pas. Poziția ecranului unui fragment este și el disponibil în pixel shader.

Limitările pixel shaderului este că poate influența doar fragmentul primit, când acesta se execută, nu poate trimite rezultatul către pixeli vecinii.Mai degrabă, folosește datele interpolate de la vârfuri, împreună cu constante și date de texturi stocate, pentru a computa rezultatele care vor afecta un singur pixel. Această limitare nu este însă atât de severă.Pixelii vecini pot fi influențați de către tehnici de procesare a imaginilor.

Singurul caz în care pixel shaderul poate acesa o informație pentru pixeli adiacenți(indirect) este prin computarea unui gradient sau informații derivate.Pixel shaderul are abilitatea de a luă orice valorare și de o computa într-o cantitate care se poate schimbă per pixel împreună cu axele X și Y ale ecranului.Acest lucru e util pentru o varietate de computatii și adresare a texturilor.

Acești gradienți pot fi importanți în particular pentru operațiile cum ar fi filtrarea.

Majoritatea GPUrilor implementează această capacitate prin procesarea pixelilor în grupuri de 2 x2 sau mai mult.Când un pixel shader cere o valoarea unui gradient , diferență pixelii adiacenți este .

Un rezultat acestei implementării este informația gradient nu poate fi acesata părțile shaderului care afectate de dynamic flow control, toți pixelii într-un grup fiind procesați cu instrucțiuni. e o limitate funadmentala care sistemele de randare offline.Abilitatea de acesa informații fradient este capacitate pixel shaderului , nefiind de către alte stadii programabile de shader.

de pixel shader setează fragmentul culorii pentru merguirea stadiul final aceștia.Valoaqre de adâncime stadiul de rasterizar poate fi ea de pixel shader.Valoarea bufferului șablon nu poate fi , dar poate fi transferată prin stadiul de merge. SM 2.0 departe , un pixel shader poate la datele fragment care vin, generează 0 output.Aceste operații perfomanta iar optimizările care făcute deobicei de GPU nu fi folosite.Operațiile de computare testarea alpha fi mutate de la operații de merge la computatiile pixel shaderului SM 4.0.

Shaderele de pixel curente capabile o cantitate de procesare. Abilitatea de orice număr de valori într-un singur de randare la de multiple render targets (MRT). loc salveze rezultatele pixel shaderului într-n singur buffer de culoare , multipli vectori fi folosiți pentru fiecare fragment de qa la bufferi diferiți.

Acești bufferi trebuie dimensiuni unele arhitecturi fiecare aceași adâncime de (cu formate diferite, după necesitate).Numărul de PS output registers se la numărul de bufferii acesibile separați(4 8).Spre deosebire de bufferul de culoare pentru display, limitați la fiecare .De exemplu,nici un de anti-aliasing poate fi executat.

Chiar cu limitare, funcționalitatea MRT este un ajutor puternic utilizarea algoritmilor de randare. un număr de imagini rezultate intermediar computate de la același de date, numai un singur de randare este necesar, locul unui singur per buffer de output.Cealaltă capacitate cheie cu MRTuri este abilitatea de imaginile rezultate texturi.

Stadiul de merge

Stadiul de merge unde adâncimea și culoare fragmentelor individuale (generate de pixel shader) sunt combinate cu un buffer de frame.În acest stadiu unde operațiile bufferului șablon și Z-bufferului se întâmplă.

O altă operație care se petrece în acest stadiu este blendingul culorii ,care este folosită cel mai frecvent pentru operațiile de transparența și compozitionare.

Stadiul de merge ocupă un punct mijlociu interesant între stadiile fixed-function și stadiile de programare a shaderului.Deși nu este programabil, operația este foarte comfigurabila.Blendingul de culoare în particular poate fi setat pentru a computa un număr mare de operații diferite.

Cele mai comune combinații sunt multiplicările, adunările și scăderile pentru valorile culoriloe și alpha, dar alte operații sunt posibile , cum aqr fi minim și maximum, precum și operații de logică bitwise.DX10 a daugat capacitatea de a blendui două culori de la pixel shader cu o culoare de la frame buffer(dual color blending).

Dacă funcționalitatea MRT este folosită, atunci blendingul poate fi făcut pe mai multe buffere.DX10.1 a introdus capacitatea de execută operații de blending diferite pe fiecare buffer MRT.În versiunile anterioare operațiile de blending erau executate pe toți bufferi.

Efectele

Deși shaderele de vârfuri, geometrie și pixeli sunt necesare pentru controlul stadiilor nu există în vid.În primul rând, un program de shader individual nu este util singur: rezultatele de la shaderul de vârfuri sunt trimise către shaderul de pixeli.Ambele programre trebuiesc încărcate pentru că muncă să fie dusă până la capăt.Programatorul trebuie să facă unele protirviri la outputurile shaderului de vârfuri spre inputurile shaderului de pixel.

Un efect de randare particular poate fi produs de orice număr de programe de shader executate în câțiva păși.În afară programelor de shadere în șine, variabilele de stare sunt uneori setate într-o configurație particulară pentru că aceste programe să funcționeze cum trebuie.

Exemplu: starea randarii include dacă și cum au fost folosite bufferul șablon și Z-bufferul, și efectul fragmentului pe o valoare pixel existența(replace, add sau blend).

Din aceste motive grupuri variate au dezvoltat limbaje de efecte cum ar fi HLSL FX,CgFX și COLLADA FX.Un firier de efect încearcă să încapsuleze toate informațiile relevante necesare executării unui algoritm de randare particular.Definește unele argumente globale care pot fi asignate de alicatie.De exemplu, un singur fișier de efect poate defini shaderele de vârf și pixel necesare randarii unui material de plastic într-un mod convingător.Ar expune argumente cum ar fi culoarea plasticului și duritatea astfel încât acestea să se poată schimbă pentru fiecare model randat ,folosind același fișier de efect.

Pentru a arată aromă unui fișier de efect, vom merge prin versiunea simplă a sistemului FX Composer 2 a lui NVIDIA.Acest fișier HLSL DX9 implementează o formă foarte simplă de Gooch shading.O parte a shadingului Gooch este de a folosi suprafața normală și de o compară cu locația luminii. Dacă normalul e îndreptat către lumina, un ton cald este folosit pentru a colora suprafața, e invers, un ton rece fi folosit.

Unghiurile culori diferite interolare, este non fotorealistica de randare.

Variabilele efectelor sunt definite la inceputul fisierului de efect. Cateva instante de variabile sunt imposibil de schimbat, parametrii pentru pozitia camerei sunt urmarite automat pentru efectul:

float4x4 WorldXf : World;

float4x4 WorldITXf : WorldInverseTranspose;

float4x4 WvpXf : WorldViewProjection;

Tipul sintaxei este type id:semantic. Tipul float4x4 este folosit pentru matrice ,numele este definit de utilizator si semantica este un definita prestabilit.Dupa numele matricii, WorldXf este modelul-to-world a transformarii matricii,WorldITXf este inversa transpusei matricii si WvpXf este matricea care transforma spatiul model spre zona de clip a camerei.Aceste valori cu valori recunoscute sunt asteptate de la aplicatie si nu este aratat in interfata utilizatorului.

Apoi sunt definite de catre utilizator variabilele specificate.

float3 Lamp0Pos : Position <

string Object = "PointLight0";

string UIName = "Lamp 0 Position";

string Space = "World";

> = {-0.5f, 2.0f, 1.25f};

float3 WarmColor <

string UIName = "Gooch Warm Tone";

string UIWidget = "Color";

> = {1.3f, 0.9f, 0.15f};

Capitolul 5

Prezentare UDK

Introducere

Unreal Development Kit este o unealtă prin care creatorii pasionați de jocuri își pot transpune imaginaia într-o lume virtuală. Acesta cuprinde motorul grafic Unreal Engine, care a fost creat de Tim Sweeney în 1998 alături de compania să Epic Games pentru jocul Unreal Tournament, un joc de tip First Person Shooter. Motorul grafic este scris în C++ și este folosit și pentru alte genuri de jocuri cum ar fi Role Playing Game (RPG), Hack n’ Slash, Adventure și chiar Racing. Au fost realizate mai multe versiuni, cea mai recentă fiind 4 lansată în 2012. În prezent Unreal Engine rulează pe aproape toate dispozitivele capabile să producă grafica, de la PC până la consolă și până la telefoane mobile.

Cerințele de system pentru a rulă UDK sunt următoarele:

Windows 7 64-bit sau mai nou ori Mac OS X 10.9.2 sau mai recent

8GB de RAM

CPU Quad Core Intel sau AMD

Placă video cu support Direct X 11 GTX 480 sau mai nou

1.1 Componente

Editorul de Nivel

Editorul de Nivel furnizează nivelul de bază de creație și funcționalitate pentru Unreal Editor. Aici este locul unde nivelurile de jos sunt create, previzualizate și modificate în special prin plasarea , transformarea și editarea proprietăților Actorilor.

În Unreal Editor, scenele în care creăm experiență de joc sunt în general numite Niveluri. Ne putem gândi la un nivel că la un mediu 3D în care putem plasă o serie de de obiecte și obiecte geometrice care să definească o lumea pe care jucătorul să o experimenteze. Orice obiect care este plasat în această lume de joc, fie o lumina, un personaj, este considerat că fiind un Actor. Tehnic vorbind , un Actor este o clasă programabilă folosit de Unreal Engine că să definească un obiect care are o poztie 3D, rotație, și o dimensiune. Pentru simplitate ne putem gândi că un Actor este orice obiect care poate fi pus în nivel.

“Unreal Editor pentru Unreal Engine 4”

Actori

Un Actor este orice obiect care poate fi pus într-un nivel. Actorii sunt o clasă generic care suportă transformări 3D cum ar fi mutarea, rotirea și schimbarea dimensiunii. Actorii sunt create și distruși prin gameplay(jucărea jocului) sau cod(C++ sau Blueprints). În C++, un AActor este clasă de bază a tuturor Actorilor.

Sunt diferite tipuri de Actori, niște exemple are fi: StaticMeshActor, CameraActor și PlayerStartActor.

Indiferent de tipul de Actor pe care îl folosim în nivel- fie o lumina, un Static Mesh, un Actor de Emitere al Efectelor de Particule sau orice altceva- trebuie să știm câteva lucruri de bază în ceea ce privește crearea și manipularea lor și punerea lor în scenă.

Asta implică câțiva păși: plasarea Actorilor, selectarea Actorilor, positionarea Actorilor și modicarea Actorilor. Cu alte cuvinte, pentru a creă un nivel, Actorii trebuie să fie plasați pe o hartă, mutați prin zonă pentru a creă un mediu și proprietățile lor trebuiesc modificate pentru a îi face să comporte natural.

“Exemple de Actori”

Materiale

Materialele sunt component care sunt adăugate unor obiecte pentru a controla efectele vizuale ale nivelului. La un nivel mai înalt, e proabil mult mai ușor să ne gândim la Material că la o vopsea ce o aplicăm unui obiect. Dar și asta poate să fie puțin derutant, mai ales fiindcă un Material poate fi definit că un tip de suprafața din care obiectul nostrum pare să fie făcut. Poți defini culoarea, cât de lucios este, fie că putem vedea prin el, și multe altele.

În termeni tehnicim când lumina din nivel lovește suprafața, un Material e folosit pentru a calculă cum interacționează acea lumina cu suprafața. Aceste calcule sunt făcute folosind date care provin din imaginile (Texturile) care compun Materialul și expresii matematice, precum și din proprietățile care I s-au dat acestuia.

“Materiale bazate pe lucruri reale:Carbune, Ciment, Asfalt, Cupru, Fier, Aur, Aluminiu, Argint, Nichel, Titaniu”

Texturi

Texturile sunt imaginile folosite în Materiale. Ele sunt mapate Materialului căruia i se aplică. Chiar dacă Texturile sunt aplicate direct, pentru Texturile Culorilor de Bază sau sunt introduce valori ale pixelilor Texturilor acestea sunt folosite în Materiale că măști sau pentru alte calcule. În anumite instanțe, Texturile pot fi folosite direct, înafară Materialelor , pentru lucrarui cum ar fi crearea interfețelor. De cele mai multe ori Texturile sunt create înafară motorului grafic în editoare de imagini cum ar fi Photoshop, și apoi importate în Unreal Editor prin Content Browser. Totuși, anumite Texturi sunt generate în motorul grafic cum ar fi Texturile de Randare. Acestea, în general culeg informative din nivel pe care o randeaza că Textură pentru a putea fi folosită în altă parte.

Un singur Material poate utiliza mai multe Texturi care sunt aplicate uniform pentru diferite utilizări. De exemplu, un simplu material poate avea o Textură de formă unei simple culori și o Textură Speculară.

“Exemplu de Textura in UDK”

Simulara de particule fizice

Unreal Engine 4 folosește motorul fizic PhysX 3.3 pentru a reproduce simularea efectelor de fizică și a calculelor matematice pentru a creă distanțele de coliziune ale obiectelor. PhysX furnizează abilitatea de a detectă cu acuratețe coliziunea obiectelor cât și de a simulă interacțiunea fizică dintre acestea în nivelul creat.

Nvidia PhysX

PhysX este motor de fizică în timp real proprietar al celor de la Nvidia. Termenul PhysX se referă și la placă de expansiune creat de cei de la Ageia pentru a acceleră efectele PhysX din jocurile care suportau tehnologia. Aceștia au fost cumpărați de Nvidia în 2008 iar tehnologia a fost inclusă în plăcile de la Nvidia fără a mai fi nevoie de placă de expansiune,deși la început pentru efectele PhysX era nevoie de 2 plăci video de la Nvidia. Primul joc care a avut tehnologia PhysX a fost Bet on Soldier: Blood Sport.

“Demonstratie a efectelor de fizica in UDK”

Capitolul 6

Prezentarea Aplicației

Aplicația interactive 3D tip Puzzle în UDK a fost dezolvata pe platform Unreal Engine 4 lansată de Epic Games în 2012. Ea oferă numeroase posiblitati de creație prin uneltele și suportul pe care îl are cu programe terțiare de genul Photoshop sau Blender.

Aplicația poate fi văzută și că un mini joc care are la bază completarea unor sarcini care devin din ce în ce mai dificile. Jocul începe printr-un puzzle simplu și intuitiv după care jucătorul trebuie să folosească ce a învățat pentru a trece mai departe. Jocul are la bază ideea de a plecă de la origini spre drumul cunoașterii.

Unreal Engine 4 are nevoie de următoarele componente pentru a rulă:

Procesor – Quad-core Intel or AMD, 2.5 GHz sau mai rapid

Memorie RAM – 8GB

Placă Video – seriile NVIDIA GeForce 470 GTX sau AMD Radeon 6870 sau mai puternice decât acestea.

Sistem de operare – Windows 7/8 versiunea de 64 de biți

Versiune de DirectX – Ultima versiune de DirectX (Iunie 2010)

Versiune de .NET-.NET 4.0 (instalabil cu ajutorul Windows update-ului)

6.1 Crearea Puzzle-ului

Puzzle-ul prezent în aplicație a fost creat cu ajutorul mai multor unelte cum ar fi: Blueprints, o unealtă de visual scripting prezența în Unreal Engine 4 și Matinee, o unealtă prin care se pot crea diferite evenimente în joc precum platforme care se mișcă și filmulețe. Inspirația pentru acest tip de puzzle a venit de la jocul pentru consolă Super Mario 3D World dintr-o secțiune asemănătoare cu ce este prezent în aplicație.

Ideea primului Puzzle-ului constă în faptul că jucătorul trebuie să schimbe platformele roșii(starea 1) în platforme verzi(starea 3) lucru ce va rezultă în avansarea acestuia la următorul puzzle prin deschiderea caii acestuia. Că și feedback când jucătorul apăsa o platform această devine temporar galbenă(starea 2) pentru a-i confirmă jucătorului că a apăsat respective platform. De altfel, dacă se apăsa iar aceeași platformă această devine roșie , întorcăndu-se la starea inițială.

“Starea 1” “Starea 2”

“Starea 3”

Crearea aplicației a început prin a selecta un nou proiect și a porni Unreal Editor și a selectă presetarea “First Person” alături de “Starter Pack” fără de care nu am avea asseturi cu care să lucrăm.

De acolo am eliminat elementele cum ar fi armă personajului și obiectele care erau în plus. Aplicația a fost făcută integral folosind sistemul de Blueprints ale motorului grafic. Primul lucru din Blueprint va fi verificarea celor 3 puzzle-uri pentru a asigură o funcționalitate optimă a acestora.

Primul Puzzle

Primul puzzle a fost realizat folosind Matinee pentru a crea evenimentele care duc la rezolvarea puzzle-ului și a deschiderea drumului jucătorului. Am folosit animații și triggere.

Pentru platform am folosit cuburi 3D transformate apoi în simple platforme prin unealtă de schimbare de dimensiune a motorului grafic( Fig 1) iar apoi am adăugat triggerul inserând și culorile necesare interacțiunii folosind Blueprints (Fig 2) care duc la animația create în Matinee.(Fig 3).

“Fig 1”

“Fig 2”

“Fig 3”

Si cu aceste procese am reusit sa fac primul puzzle urmand sa trec la cel de-al doilea.

Al Doilea Puzzle

Al doilea puzzle este ceva mai complex având și niște elemente de platforming. Acest puzzle are la bază același concept ca primul numai că de data asta platformele nu mai sunt puse într-un singur loc iar unele apar în momentul în care sunt activate cele de dinainte folosind triggere alături de Blueprints(Fig 5) și Matinee(Fig 4) pentru animația acestora.

“Al doilea Puzzle”

“Fig 4”

“Fig 5”

Al Treilea Puzzle

Cel de-al treilea puzzle pornește direct după ce jucătorul a completat al doilea puzzle printr-o animație (Fig 6) care creează mediul pentru acest puzzle (Fig 7). Au fost folosite că și până acum Blueprints și Matinee pentru triggere și animații. Cu toate astea al treilea puzzle este opțional nefiind necesar ajungerii la finalul jocului. Puzzle-ul este mai complicat decât celelalte 2 de data asta intrând în calcul și puțină gândire logică. Fiecare apăsare pe platform activează si celelalte platform adiacente sale. Totuși adevăratul test rămâne de intuiție a jucătorului de a observa ceva înafară de puzzle în mediul său(Fig 8).

“Fig 6”

“Fig 7”

“Fig 8”

6.2 Designul Puzzle-ului

Cum am menționat și mai sus jocul nu este încă gata, dar până la final mai trebuie parcurs și drumul care a dus la crearea lumii acestuia: Designul.

Designul jocului a fost făcut folosind pachetele de asset-uri: Starter Pack, MixamoAnim Pack, GTFreeMaterials Pack și câteva texturi și materiale importate din alte proiecte Unreal Engine.

Am început prin a creă punctul de pornire al jucătorului, o mică așezare de oameni decorata cu diferite artefacte și copaci creând un loc credibil. Acesta este punctul din care jucătorul pleacă în călătoria sa spre cunoaștere, spre rezolvarea puzzle-urilor.

“Locul din care jucatorul porneste”

Scaling

Am început cu o simplă platformă pe care am mărit-o până la punctul la care pot construi un mediu de joc. Am folosit materialul Ground_GrassThickGreen pentru platforma pe care sunt așezate toate celelalte lucruri. Copacii au fost creați dintr-unul singur folosind unealtă de mărire sau miscorare a acestora.

Lighting

Un alt aspect al designului a fost și evidențierea anumitor materiale folosind lumina și tehnica de reflectare a acesteia de altfel folosind și efectele de particule cum ar fi aburul de a evidenția obiectul dorit

Utlizarea Texturilor si Materialelor

Am folosit numeroase texturi și materiale pe obiectele care erau disponibile în Unreal Editor pentru a da un efect cât mai credibil mediului de joc dând iluzia de loc real în care jucătorul se află. De altfel am inclus și sunete amibiante și o melodie pentru atmosferă.

Efecte de Particule

Motorul grafic dispune și de efecte de particule, cum ar fi fumul, focul, ceață sau scanteiele așa cum sunt evidențiate în imaginile de mai jos.

În final putem spune că drumul spre a creă un joc este un drum greu, care consumă foarte mult timp, putem spune că este o muncă grea dar din pasiune la fel cum este programarea în general.

Cu această ultimă imagine putem spune că am atins pragul cunoașterii.