Pocokthadam-TEST MODELLEK, SZÁMÍTÓGÉP ÁLTAL KÉSZÍTETT KÉPEK, CLUSTER ALAPÚ RENDERELÉS

1.Bevezető

A dolgozat a számítógép által készített képekkel foglalkozik és azon belül is a 3D-s modellekről készült képekkel, továbbá a renderer enginekkel. Napjainkban a leggyorsabban fejlődő része az informatikának a számítógépes grafika.

A 3D-s modellekről készült képeket nem csak a szórakoztató ipar pl. filmek, reklámok, animációk, hanem az ipar is alkalmazza pl: autóipar, építőipar stb. Ezekről a modellekről alkotott képek sokszor igényelnek nagy számítási kapacitást, amit sokszor csak nagy szerverek (Mainframe) vagy szuperszámítógépek elégítenek ki.

Dolgozatomban a kis és közép vállalkozásoknak adok megoldást, hogy ne kelljen drága szervereket alkalmazni vagy gépidőt vásárolni valamelyik szuperszámítógéphez. A megoldást az Nvidia videokártyái jelentik, amelyek tartalmaznak CUDA-s GPU magot-magokat. Ezen felül nagyobb számítási kapacitás érhető el, ha a használaton kívüli számítógépeket a vállalkozásokban clusterekbe szervezük.

Dolgozatomban bebizonyítom, hogy igen hatékony a fent említett két megoldás a render idő csökkentésére, de arra is rámutat, hogy az egy gépen való renderelésben nem CUDA-s és CUDA-s gép között hatalmas teljesítmény növekedés tapasztalható, viszont a Clusteren való renderelésnél már nem ekkora a hatásfok növekedése.

A fő probléma a render enginek működésében és az architektúrában rejlik A render enginek, ha bevonják a feladatba a GPU-t is, akkor a kiszámolt képrészleteket a rendszer memóriájában tárolják, de mikor az utolsó szelet is kiszámításra került, akkor a végső képet, az összes adatot vissza kell másolni a GPU memóriájába ezzel megnövelve a render időt. A clusteres megoldás esetében ez a fő magyarázat arra, hogy miért nem érhető el akkora hatékonyság, hiszen ott a hálózati kártyán is van némi késleltetés az adatok visszamásolása mellett.

Ennek kiküszöbölésére létre kell hozni egy transzparens réteget ahová gyűjtjük a kiszámolt adatokat. A render enginnek innen kell előállítania a végső képet ez esetben már bőven elérhető ugyanakkora hatásfok-növekedés a Clusteres megoldásnál is.

2.A modellezés alapjai

Az elsődleges lépés nem lehet más, mint az, hogy létrehozzuk a 3D-s modellt, hiszen anélkül nem lehet létrehozni a képeket, esetleg animációkat. Más?más eljárással szabályokkal készülnek az animációk és a látványtervek. Ehhez szükséges különbséget tennünk high-poly és low-poly között.

High-poly-t (Magas polygon szám) a CGI képeknél alkalmazzuk, hogy minél pontosabb legyen a geometria. Bizonyos polygon szám felett már nem vehető észre különbség, de ezt az objektum geometriája határozza meg.

Low-poly (Alacsony polygon szám) ott alkalmazzuk, ahol gyors renderelés szűkséges pl: animáció, ahol több képet fűzzünk össze. Ugyanis egy másodpercnyi filmhez 24-25 képkocka (Frame) szűkséges. Ebben az esetben más eljárással érhetjük el az élethűséget pl: bump-mapping, normal-mapping

Így, hogy eldönthető, hogy mely esetekben milyen magas polygon számú objektumokat kreálunk nincsen más, mint megfelelő modellezési eljárással megalkotni az objektumot, jelenetet (Scene). A modellezés megkezdéséhez a megfelelő referencia anyagokat össze kell gyűjteni, gépjárművek esetében néhány főbb paramétert is mint például: hosszúság x magasság x szélesség.

Ezenfelül úgynevezett blueprinteket is be kell szereznünk, magyarul műszaki rajzokat, de jelen esetünkben elegendő méretarányos képeket, legalább két oldali nézettel. Ezek a referenciák, blueprintek beszerezhetőek az internetről adatbázisokból, a gyártótól illetve nyomtatott sajtóból. A modellezés megkezdéséhez be kell állítanunk a blueprintet. Ezekután az ismert modellezési eljárásokkal le kell modellezni a cél objektumot.




Box modeling/ Sub-divison: Egy meglévő primitívből építkezünk mégpedig osztásos eljárással, illetve kiemeléssel (Extrude), a geometriát körbe rajzoljuk a blueprint segítségével, ügyelve a megfelelő topológiára. Az eljárásban a sub-divison a felosztást jelenti, ezt sajnos nem a program végzi, hanem nekünk kell megoldani, tehát a polygonokat is a megfelelő helyekre kell "tologatni", ez a gyakorlatban a verticles-pontok mozgatását jelenti.

A modellezési eljárás gyorsan tanulható, de időigényes, hiszen az osztásoknál keletkezhetnek olyan polygonok amikre nincsen szükség, így azokat törölni kell. Ez, többszöri ellenőrzést igényel, ami igen nagy figyelmet kíván a nagyobb pontosság érdekében. A nem megfelelő poly háló nagy torzulást is okozhat, legrosszabb esetben a render engine hibás számításához is vezethet.




Edge modeling / Countour modeling: Az eljárás nagyban hasonlít az előzőhöz azzal a különbséggel, hogy itt nem zárt primitívekből építkezünk, hanem nyitottakkal pl: lap (Plane), cilinder (cylinder), cső (tube). Az eljárásban a beállított blueprintet rajzoljuk meg, de a felosztást itt már a programra bízzuk, amennyiben alkalmazzuk a meshsmooth v turbosmooth iterációt. Az eljárás a két él közötti távolságot (Edge) felezi. Ezeknek a felezése attól függ, hogy hányszoros iterációt alkalmazunk. Minél több iterációt alkalmazunk annál több polygon keletkezik, ami nagy mértékben foglalja a memóriát.




Spline modelling: Az eljárás során Bezier görbékkel írjuk- modellezzük le a geometriát. Nagyon nehezen elsajátítható eljárás, hiszen a rácsszerkezetet nekünk kell megszerkeszteni a görbékkel. Az emberi hibázás aránya nagy illetve a referencia képek minőségétől is nagy mértékben függ. Hatalmas előnye, hogy nem kell a felhasználónak a felosztással törődnie és a programon belül sem kell alkalmazni a felosztási iterációkat, tehát sima felületet kapunk. Másik óriási előnye, hogy nem jár hatalmas polygon számmal mégis valós geometriát kapva, gyorsabb lesz a renderelés.




Procedural modelling: Az eljárás során a felhasználó nem tud direkt módon belenyúlni a geometria leképzésébe. Ennél az eljárásnál bluprintet sem kell alkalmazni, hiszen a program generálja az objektumot vagy objektumokat különféle szabályokból. Leginkább várostervezés, légszennyezés, hő vizsgálatoknál alkalmazzák ezt az eljárást.




Digital sculpting: Digitális szobrászkodás , az organikus modellezés egyik új fajtája. Különlegessége, hogy a szobrászkodás közben létrejövő hatalmas polygon számok nem terhelik le úgy a számítógépet, mint az Edge vagy Box modelling esetén. A szobrászkodás esetében, úgy mint a valóságban, a kiindulópont egy hatalmas primitív objektum, melyből különféle ecsetekkel (brush), alakítják ki a végső objektumot.




Imaged Based Modelling: Az eljáráshoz a felhasználónak nem kell beavatkoznia és szabályokat sem kell beállítani, a szoftver a megfelelő méretarányos képekből elkészíti a 3D-s objektumot. Jelenleg kutatási fázisban tart az eljárás, ezáltal nem is terjedt még el, nagy a hibázási ráta.




3.Hibajavítás

A megalkotott nyersmodelleket szaknyelven Clay-modelleknek hívjuk, mint a járműgyártásban az agyagból készített méretarányos modellt. Ahhoz, hogy bármilyen textúrát, shadert kaphasson az objektumunk, ellenőrizni kell, hogy tartalmaz-e hibákat. A modellezés során törekedtünk a megfelelő topológia kialakítására, de előfordulhat, hogy az objektum egyes részei topológiailag nem megfelelőek, ez lehet polygon hiba például négyszög helyett háromszög található.

Mesh & Turbosmooth alkalmazás nélkül azért probléma, ha háromszögekből épül fel az objektum, mert a renderelés indításakor a számítógép hozza létre a háromszög hálót, de azáltal, hogy mi hoztuk létre a háromszöget a számítógép nem fogja tudni eldönteni, hogy-hogyan ossza fel az objektumot ezzel megnövelve indokolatlanul a renderelési időt. Az alábbi listában felsorolom a leggyakrabban előforduló hibákat.

- Topológiai hiba
- Geometria hiba (Az objektum nem megfelelően van lemodellezve, eltér az eredetitől)
- Polygon szemetet tartalmaz
- (Chamfer) Letörés használata után nem megfelelő polygon háló.

A hibajavítások után a clay modellt egyszerű, egy pontos, legfeljebb két pontos fényeknél gyors render mellett megvizsgáljuk, hogy valahol van-e még hiba a modellen. Ilyenkor fénytörést, tükröződési hibákat keresünk. Ha nem találunk, teljesen felkészítettük a következő műveletre, ahol shader és textúrákat kap.

4.Anyagozás

Az anyagozással alakítjuk ki, az objektum végleges kinézetét. Ez egy nagyon összetett folyamat, hiszen a modell egyes részei nem csak egy shader és textúrából állhatnak, hanem akár 22 féle részegységből is, mint például : bump-map, normal-map, diffuse-map stb. A render-enginek rendelkeznek saját shaderekkel, de vannak közösek is, általában a render-enginekhez fejlesztett shaderekkel szebb eredményt kapunk, de használatuk bonyolultabb is. A shaderhez rendelt textúrát úgy készítjük el, hogy az adott modellt poly lapjaira terítjük egy kockán ezt úgy nevezik UVW Template.




A nyers UVW Template-et be kell töltenünk valamelyik vektoros képszerkesztő programba, én az Adobe Photoshop CS6-ot alkalmaztam. Ehhez a folyamathoz elengedhetetlen néhány referencia kép, hogy megalkothassuk az eredeti mását. Az ellenőrzést mindig a modellre töltött képpel tesszük mégpedig úgy, hogy engedélyezzük a viewportban a textúrákat így láthatjuk, a hibákat.




Az objektum minden egyes pontja megkapta a megfelelő textúrát, mint az a 9.-es képen látható is, gyakorlatilag felkészítettük a renderelésre. Mivel a textúrázott modell is erőforrást von el, ezért jó előre meg kell határozni, hogy milyen felbontású textúrákat alkalmazunk, illetve előre eltervezzük az ideális polygon számot. Az alábbi táblázatban azt láthatjuk, hogy mekkora memória igénye van a különböző felbontású képeknek.

Léteznek standard méretek amiktől el lehet természetesen térni, de ezek a méretek általánosan el fogadottak:
64x64 , 128x128 , 256x256 , 512x512 , 1024x 1024 , 2048x2048 ,4096x4096

Napjainkban egy otthoni konfigurációban már minimum 4GB memória található,így ennek tudatában az ideális méret a 2048x2048-as textúra lehet. Ennek a felbontásnak nincs köze a megjelenítő felbontásához, de jó ha tudjuk, hogy bizonyos méret felett az emberi szem már nem veszi észre a különbséget. A 9.-ik képen látható jármű teljes textúrázása után, de még a renderelés előtt ellenőrizve 3.25 GB memóriát foglaltak le. Így a számítógépnek maradt 4GB az adatok tárolására renderelés közben.

Bump-mapping: Ez az eljárás amikor egy egy 2D-s képet ráfeszítünk egy 3D-s alakzatra, legyen az alakzat bármi, általában greyscale képeket alkalmaznak, de működhet többféleképen is. A lényeg, hogy a bump-mappingnél alkalmazott kép egyszínű hátterű legyen.

Normal-mapping: Az eljárás hasonló, mint a bump-mapping azzal a különbséggel, hogy itt a kép tárolja a vektor irányokat és nem az intenzitást alkalmazza.

Diffuse-map: A fő textúra, ez általában valamilyen bitmap fájl, ezt mi hozzuk létre a UVW template-ből

5.Világítás, kamera elhelyezés

A modellünk mit sem ér,ha nem készítünk róluk renderelt képeket. A fentebb említett anyagozás után, nincs más feladatunk, mint felkészíteni a jelenetet amit éppen le szeretnénk renderelni. Többféle fénybeállítást alkalmazhatunk, használhatunk omni lightot, plane lightot , dome lightot.

Méréseim szerint a leggyorsabb renderelési időt az omni light adja, de a fő hátránya, hogy kevésbé ad élethű képet. 1920x1080-as felbontású képen ilyen fényt alkalmazva közepes elsimítással 1p20s/frame-t értem el egy gépes rendszeren.




Amennyiben több fényből állítjuk elő a jelenetet, mint a fentebb látható garázsnál a megvilágítást olyanra állítjuk, mint a valóságban, hogy több fényforrást állítunk be, a számítási igény hatványozódik. Tehát mondhatjuk, azt, hogy a memória igény az alábbi képlet alapján alakul.

Összmemória = G+fx+m

A G az esetünkben a geometriák összességét jelenti, mely a polygonok számával növekszik, az fx , ahol az x a fények számát jelenti az f pedig konstans 2, az m nem más, mint az összes textúra és shader memória igénye így kiszámítható, hogy mennyi memória is kell összesen egy adott jelenethez, hogy egyáltalán betöltethetővé váljon a szoftver számára. A jelenet betöltéshez nem használható a swap memory, csak és kizárólag a fizikai memóriába tölti be azt, így egyes jelenetnél előre kell kalkulálni a várható memória igényt.

A render idő a fényektől pedig az alábbi módon számítható.

Fénr_t=fények száma * (fx+tükröződés+árnyékok)


Tehát a fenti képlettel megkapjuk azt a gépidőt amennyi csak a fények számításához szükségesek, tehát a fényforrások szorzata az fx+tükröződések+árnyékok száma, ha ez 1 fényforrás akkor általában a végeredmény megközelítőleg 4. Tehát egy fényforrás alkalmazásánál már 4x több gépidő kell, mintha nem használnánk fényeket.

Gyorsításra van lehetőség, amennyiben nem animációt készítünk, hanem látványtervet. Ebben az esetben van rá mód, hogy az anyagozásnál a material editorban egy külön csatornán hozzá rendeljünk shadow és light mapokat amik a fény és árnyékok külön külön lenyomatai így rendeléskor nem számolja azokat, csak hozzá rendeli. Előnye, nagy mértékben redukálja a renderelési időt, hátránya, hogy mozgóképek készítésére nem alkalmas, mert ott minden egyes képkockán újra kell számolni azt.

Egy másik alternatív módszer a látványképek elkészítésének meggyorsításához: a végső képről készítünk lenyomatot és úgy sütjük össze a textúrával (Bake Texture), a számítógépes játékipar is ezt használja. Hátránya szintén az, hogy mozgóképeknél egyáltalán nem alkalmazható.

A geometria elkészítésével, a textúrák, shaderek beállítása után, a fények hozzárendelése után is szükség van különböző ellenőrzésekre:

- A fényforrás megfelelő intenzitású legyen
- A textúrázott, shaderezett objektumon a fénytörés jobban megfigyelhető; így jobban kiszűrhető, hogy hol van még hiba a geometrián
- Megfelelő memória mennyiség maradt még a renderelés elindításához
- A megfelelő árnyék beállítások

6.Renderelés

A renderelés beállítása eléggé bonyolult, hiszen mi magunk határozzuk meg, hogy GI (Global Illumination)-t használunk vagy a 3DS MAX gyári számítási modelljét. A render enginek többsége úgy működik, hogy előbb a nyers geometriát számolja ki, mely nem igényel nagy gépi teljesítményt, majd a textúrákat és shadereket húzza rá és ebben az iterációban már a fényekkel is számol. Ennél az iterációban a minél nagyobb pontosság érdekében több iterációt is beállíthatunk, de ezzel az iterációval a számítási időt nagyban növelhetjük.

Az utolsó lépés az úgynevezett final render mikor a végső kép készül el. Ekkor az összes adatot egybe rakja a szoftver és így hozza létre a végső képet. Renderelés előtt meghatároztuk, hogy mekkora felbontásban szeretnénk megkapni a képet-képeket és azt rendereléskor szabványos méretekre szeleteli fel: bucketekre.

Egy egy ilyen bucketet, ha kiszámolt a render engine, a háttértáron vagy a rendszer memóriában tárolja el. Amennyiben olyan render engine-t alkalmazunk ami támogatja a GPU-val való renderelést, mint például az Nvidia CUDA vagy az ATI Firepro technológiát akkor a GPU számolja a bucketeket és a tárolásuk a fentebb említett módon történik.

Dolgozatomban megpróbáltam többféle engine-t alkalmazni, hogy minél több adatot gyűjtsek az egy gépen való renderelésről, az egy gépen de GPU-val számított renderelésről illetve a Clusteres renderelésről. Az alábbi alpontokban mutatom be a működést, majd a végén táblázatba szedve az adatokat, elemzem azokat.

Ebben a fejezetben bemutatott render engineknél mutatott képek mind saját munkák, általam készített geometriák, textúrák és shaderek, jelenetek.

Mental-Ray v I-ray

Az első render engine amit alkalmaztam az a Mental-Ray illetve az I-ray az Nvidiatól. Fő különbség a két engine között, hogy amég a mental-rayt alkalmazhatjuk Nvidia-s videókártya nélkül addig az I-ray csak CUDA-s kártyával hajlandó kommunikálni.

A mental ray esetén tehát beszélhetünk arról, hogy a számítógép CPU-ja számolja a különböző iterációkat és azt a rendszer memóriájában tárolja azt. Természetesen a final render végeztével a rendszermemóriában tárolt adatokból készíti el a képet. Támogatja az úgynevezett distributed renderinget, tehát clusteres megvalósításban is alkalmazható. Ilyenkor egy Host gép van és egy vagy annál több kliens gép, nevezzük őket slaveknek. A slavek működéséhez szükséges elindítanunk a gyári satelite services-t, mert ezen keresztül kommunikálnak.

A distributed renderingnél két lehetőségünk van az adataink megosztására.

a, Ebben az esetben a HOST gépre bízunk mindent és az szét osztja a slave-ekre. Ez egy slave esetén gigabites hálózaton még nem okoz komoly lassulást, de több slave esetében már érezhetően megnő az az idő amíg eljuttatja a megfelelő adatokat.

b, Ebben az esetben mi mozgatjuk az adatokat az összes slave-re .

A renderelés indításakor maga a render engine ellenőrzi, hogy az ip cím alapján beállított gépek készen állnak-e vagy még nem. Ekkor gyakorlatilag üres csomagokat küld a services-nek és amikor az, válaszol, hogy készen áll a futatásra. Nincs felső korlát, hogy hány db slavet alkalmazunk tehát nincs mennyiségi licensz.

Előnye az engine-nek, hogy könnyen átlátható, könnyen felkészíthető a renderelésre az újabb verziókban pedig már nem magunknak kell állítani a slavek ip-címét. Saját materialokkal dolgozik, de használható a gyári standard material is.

Hátránya: Ha az egyik slave kiesik menet-közben, valamilyen hiba folytán (áramszünet, operációs rendszer hiba stb..) nincs hibaellenőrző algoritmusa, tehát azt a bucketet amit kiosztott az adott slave-nek, már többé nem osztja ki ilyenkor, így az adott bucket üresen marad.

Az iray a fentebb említett módon működik azzal a különbséggel, hogy itt már a GPU-t használja a számításnál, illetve az iray-nek más a material adatbázisa mint a mental-raynek. Hátránya ugyanaz.




Nevesebb filmek ahol ezt az engine-t alkalmazták:
- Hulk
- Mátrix: Újratöltve és Revolúció
- Star Wars Epsiode II : Klónok Támadása
- Holnapután

Beállítások alkalmazása, saját mérések során bebizonyított optimális konfiguráció mental-ray esetében :




A mental-ray esetében is alkalmazható a GI azaz a Global Illumination ezért előtte szükséges a megfelelő beállításokat megtalálni.
A final gather-t bekapcsolva sokkal élettelibb képet kapunk, de ezt a kapcsolót nincs értelme nagyobbra állítani, mint medium. Ezt a saját méréseimből állapítottam meg, természetesen a Global Illumination-t bekapcsolva a szorzót 1-esen hagyva teljesen optimálisan fut, felette nincs értékelhető különbség ellenben a render időt növeljük meg feleslegesen. Tehát az alábbi konfigurációt ajánlom mental-ray alkalmazása esetén, ezt a beállítást több mérés alapján állapítottam meg!

- Enable Final Gather: Medium Multiplie: 1.0
- Enable Global Illumination Multiplier : 1.0
- Soft Shadows Precision Multiplier : 4
- Sampling Quality: Min: 4 Max: 64
- Bucket order: Hilbert (best)
- Frame buffer type : float
- RayTrace Acceleration : BSP2

A fenti beállítást több mint 3 éves kutató munka segítségével találtam meg, bizonyos opciókat még be lehet kapcsolni, annak függvényében, hogy a jelenet beltéri vagy kültéri. Ezeket a beállításokat egyszerre nem lehet alkalmazni így a mérések szempontjából irrelevánsak voltak.

V-ray adv 2.00.3 és V-ray RT 2.00.3

A fejlesztő a ChaosGroup, létezik kipróbálható verziója is, de 3DS MAX-hoz nem jár alapból, külön megvásárolható. Alapból két engine-t kapunk, ha megvásároljuk, az adv. és az rt-t. Az adv. változat használható minden gépen, nem igényel GPU-t. Az RT csak és kizárólag a megfelelő GPU-val kommunikál. Működése hasonlóképpen zajlik a mental-ray-hez azzal a nagy különbséggel, hogy az adatok tárolásánál van lehetőségünk a háttértár választására mely bizonyos szempontokból előnyös. Több iterációval éri el a végső képet és támogatja a distributed renderinget. Szintén nem tartalmaz hiba felismerést, tehát, ha distributed rendering alatt kiesik az egyik gép, onnan már nem vár adatot és nem osztja újra ki az adott bucketet.




Nevesebb filmek ahol ezt az engine-t alkalmazták:
- Halálos iramban (részek)
- TED

A méréseim alapján megállapított optimális beállítások az alábbiak, bizonyos esetekben ettől el lehet térni pl : kültér-beltér megvilágítása, volumetrikus fények alkalmazása.

Image sampler: Adaptive DMC
Anti Alialiasing filter on : Mitchel-Netravali
V-ray adaptive DMC image sampler: Min subdivs: 1 Max subdivs : 4
GI environment (skylight ) override: on
Depth on field: on
Indirect Illumination (GI): on , reflective: on, refractive: on
Primary bounces: 1.0 Irradiance map
Secondary bounces: 1.0 Light Cache
Irradiance map:
Min rate : -3 Max rate : -1 HSP. subdivs : 50 Interp. samples : 20
Clr Tresh: 0,4 Nrm Tresh. : 0,2 Dist. Tresh: 0,1
Detail Enchancement : on Scale : Screen
Light cache:
Subdivs: 15 Sample Size : 0,02 Scale : Screen

A fenti konfigurációban a Light Cache-nél a Subdivs emelésével érhetünk el kültéri jeleneteknél szebb képeket, amennyiben beltéri jeleneteket készítünk ennek az emelése nagy mértékben megnöveli a render időt és emberi szem által értékelhető különbség nem keletkezik.

Cebas Final Render 3.5 Sp5 és Sp7

A Cebas stúdió fejleszti ezt a render engine-t. A kiszámított bucketeket hasonló módon tárolja, mint a fentebb említett két engine, szintén támogatja a GPU-val való számolást, mind a két nevesebb gyártótól (Nvidia, ATI). Az engine támogatja a distributed renderinget, de csak 10 számítógépen, amibe bele kell érteni a HOST-ot is! Az engine nagy előnye, hogy képes a hibajavításra, tehát, ha distributed rendering alatt valamelyik gép nem válaszol az adott bucketet újra kiosztja. Ez nagyon nagy előnyt jelent a többi engine-hez képest.




Nevesebb filmek ahol ezt az enginet alkalmazták:

A méréseim alapján megállapított optimális beállítások az alábbiak, bizonyos esetekben ettől ellehet térni pl : kültér-beltér megvilágítása, volumetrikus fények alkalmazása.

Anti-Aliasing : on default 50%
Filter : Mitchel-Netravali
Bucket size: 256
Bucket order : Hilbert
Frame buffer options : Clear : Clear Buffer Storage : float (32bpc)
Dynamic bitmap pager:
Textures : Mode ? Memory Memory usage: Ez a számítógépben található memória mennyiségétől függ!

Gbuffer: Mode - Memory Memory usage: Ez a számítógépben található memória mennyiségétől függ!

Global-Illumination : on Bounces :4
Engine: ImageGI Multiplier : 0,4
Sec.Engine: Harmonics GI Multiplier: 0,5
Details Detection: on
Image GI:
Use prepass Min : -3 Max: -1

Rh-rays : 64
Sec-rays: 32

7.Distributed rendering

A distributed rendering nem más, mint számítógépek Cluster-be való szervezése. A render engine-ek többsége támogatja ezt a fajta renderelési munkát; ehhez stabil hálózat szükséges, mert a nem megfelelő válasz idő után a Host gép az adott géptől többet már nem vár adatot és a rá kiosztott bucketet többé már nem osztja újra így az adott frame hibás lesz, adatvesztéssel jár.

Ezt az adatvesztést elkerülhetjük, ha V-ray esetében futatjuk a háttérben a V-ray spawnert és scriptből indítjuk a Job-okat ekkor úgynevezett forced rendering indul el V-ray alatt és így már képes figyelni a kieső számítógépeket. A final render esetében pedig újra kiosztja az adott bucketet, de ha a hálózat instabil, a slave-ek a host pingjére kerülhetnek olyan idle állapotba, amiből többé külső beavatkozás nélkül nem tudnak újra indulni.

Distributed rendering megvalósítható LAN-on ( Local Area Network), ha figyelembe vesszük, hogy egy switch-en vagy routeren keresztül csatlakozunk. Ez a legbiztonságosabb, de ezenkívül van rá mód, hogy VPN-en keresztül alakítsunk ki zárt rendszert, esetleg az internet segítségével, dinamikus DNS-sel is. A felsorolt sorrendben alakul a stabilitás.




8.Mérési környezet

Az alábbi méréséket a 12th Students? Science Conference, Surface Models, Computer Generated Imagery and Cluster based rendering című cikkemben használtam, amiket jelenleg is releváns értékeknek vesznek. Az alábbi táblázat a cikk ideje óta még több javított értéket tartalmaz. Ezenkívül tartalmazza azon render enginek mért értékeit amit azon cikkben nem használtam fel, de ezen dolgozatomban értékes információt ad.

Az alábbi táblázat adatai, három különböző konfigurációról származnak.

a, PC Cuda-s kártya nélkül : Intel Core I3 -3220 CPU, 8GB DDR 3 RAM, Sapphire 5770 Vapor-x 1 GB GDDR5 RAM. A mért adatok 10.1-es táblázatban.

b, PC Cuda-s kártyával : Intel Core I3- 2120 CPU, 4GB DDR3 RAM , Nvidia GT430
A mért adatok a 10.2-es táblázatban.
c, Cuda cluster : a b-vel jelölt opciót kell tekinteni ami 4 gépből állt, 3 slave és 1 host gépből. A mért adatok a 10.3-as táblázatban

A fenti konfigurációktól eltérően, más-más gépeken is teszteltem, a Single renderinget, már nem csak a Cuda-s kártyákkal való renderelést, hanem önmagában a GPU-val való renderelést illetve a clusteres renderelést is teszteltem. Összesen 9 másik gépet alkalmaztam az alábbi konfigurációkkal.

1. Intel G2030 CPU ? 2GB DDR3 memória
2. Intel G620 CPU ? 2GB DDR3 memória
3. Intel G620 CPU ? 2GB DDR3 memória
4. Intel G620 CPU- 2GB DDR3 memória
5. Intel G620 CPU -2GB DDR3 memória
6. Intel G620 CPU ? 2GB DDR3 memória
7. Intel G620 CPU ? 2GB DDR3 memória
8. Intel G620 CPU ? 2GB DDR3 memória
9. Intel Xeon E5440 2CPU- 8GB DDR3 RAM [HOST]

A 13.4-es táblázatban láthatjuk a Final Render engine által mért renderer időt, egy gépes rendszeren.
A 13.5-ös táblázatban láthatjuk a Mental-ray engine által mért render időt, egy gépes rendszeren. A 13.6-os táblázatban láthajuk a V-ray engine által mért render időt , egy gépes rendszeren.

A mérések alapján megállapítható, hogy a legoptimalizáltabb működést a V-ray engine adta, de sajnos a túlzott optimalizálásból fakadóan a fény-árnyék viszony nem eléggé élethű. A mérésből azt is megállapíthatjuk, hogy a legoptimalizálatlanabbul a Cebas Final Render áll, itt viszont a megvilágítás közel az élethűség határát súrolja. A beépített, Mental-ray, pedig a kettő között áll ugyanazon dolgokat viszonyítva.

A 13.7-es táblázatban láthatjuk a Final Render engine által mért render időt, Clusteren való renderelés esetén.
A 13.8-as táblázatban láthatjuk a Mental-ray engine által mért renderer időt, Clusteren való renderelés esetén.
A 13.9-es táblázatban láthatjuk a V-ray engine által mért render időt, Clusteren való renderelés esetén.

Az eredményekből ugyanazt állapíthatjuk, meg mint amit megállapítottunk egy gépes rendszeren, illetve látható, hogy mekkora gyorsulás érhető el 9 gép esetén, ami 1 server 8 slave megosztásban dolgozott.

9.Az adatok elemzése

Jól megfigyelhető az adatokból, hogy az egygépes rendszeren, ahol nem számoltunk GPU-val mennyivel lassabb, mint azon a gépen, ahol alkalmaztunk GPU-val való számítást, de az is jól megfigyelhető az adatokból, hogy a GPU-val való számolás és a Cluster között már nincs akkora %-os csökkenés. Ennek a jelenségnek két oka van.

Elsőként a render engine-ek adattárolási szisztémája, illetve az, hogy ha GPU-val számoltatunk akkor a render engine-ek úgy alkotják meg a végső képet, hogy a rendszer memóriából vagy a háttértárról visszamásolják az adatokat a GPU memóriájába. Másrészt azért is lassabb ez a megoldás, mert az otthoni számítógépeink UMA architektúrára épülnek és a memória elérési idő sokkal hosszabb, mint ha NUMA-s architektúra lenne. A mérés során bebizonyosodott, hogy a GPU-val való renderelés nagy mértékben csökkenti a renderelési időt és természetesen megfigyelhető ez a clusternél is.

A magyarázat arra, hogy miért nem érhető el Clusteren nagyobb sebesség azaz, hogy miért nem lehet jobban lecsökkenteni a rendererelési időt, az a számítógép architektúrából és a renderer engine-ek működéséből tevődik össze. A dolgozatban említett render engine-ek utólag rakják össze a végső képet, így az adatok vissza másolásával lassul a számítás, ha a NUMA-s PC-ket ( Non Unifrom memory access) szoftveresen UMA-vá alakítjuk, mégpedig azzal a megoldással, hogy a render engine és a tárolás közé helyezünk egy köztes réteget és onnan állítja vissza az adatokat nagy mértékben meggyorsítja illetve csökkenti a renderelési időt, így akár a Clusteren is elérhető akkora sebesség növekedés, mint a PC és PC+GPU között.

10.Köztes réteg

A köztes réteg megvalósításához egy SSD-t alkalmaztam és méréseim során megállapítható vált, hogy ezzel a megoldással, Clusteren való rendereléskor elérhető a kívánt teljesítmény növekedés. A megoldás a Host gép teljes futattása SSD alól, azaz: operációs rendszer ( Windows 7 Ultimate Edition 64bit), szoftver (3ds Max 2012 64 bit) illetve a tárolás. Az SSD (Solid-State-Drive) kiválasztásnál fontos tényező volt a TBW (Total Byte Written) adat azaz a összes írt bájt. A gyártó a megadott érték szerint a 240 GB-os SSD-nél 128TB-ig garantálja, hogy működő képes marad. A méréséket egyhetes renderelési időszakból gyűjtöttem, amit a táblázatban fel is tűntettem.




11.Megoldás kis- és középvállalkozásoknak

Dolgozatomban megpróbáltam rámutatni arra, hogy kis- és középvállalkozásoknak milyen megoldással lehetne meggyorsítani a látványterv készítéséhez szükséges időt. Általában kisvállalkozásoknál 1-5 PC található esetleg 1 szerver, míg a középvállalkozásoknál ez a szám 5-20 PC és 2-3 szerver esetleg. A dolgozatomban rámutattam, hogy a meglévő géppark elegendő teljesítményt nyújthat a sebesség növekedésére, hiszen a renderelést elindítva akár időzíteni is lehet így a felhasználó azon időben visszakaphatja gépének teljes forrását, mikor arra szűksége van. Animáció készítésnél egy teszt képkocka mérése után meg lehet becsülni a szükséges időt, így lehet előre tervezni a foglalási időt.

Mivel az animációt érdemesebb tömörítetlen formátumú képként menteni, majd a végén előállítani belőle a filmet, így előre számítható az is, hogy hány olyan nap kell amikor éppen nem használják a felhasználók a gépeiket. A formátum legyen BMP illetve, plugin alkalmazásával akár RAW formátum, mert ezeket a formátumokat könnyebben lehet szerkeszteni, felkészíteni post processnél.

Post-processek lehetnek: színkorrekció, fényerő állítás, renderelési szemét (bizonyos pixeleknél előfordulhat olyan, mint a fényképezésnél a vörös szem effektus). A vállalkozásoknak érdemes Clusterbe szervezni a gépparkot, hiszen a Cluster nem igényli a GPU meglétét, tehát nem szükséges többlet költségekbe bonyolódni.

Jelenleg a kereskedelmi forgalomban kapható legolcsóbb CUDA magos videókártya az MSI 720N-1GD5HLP GT720 ami bruttó 13.612 FT és ebből annyi kell, ahány gépen futatnák a Cluster-t.

Kisvállalkozásnál egy középértéket számítva ez 3 PC-t érintene ami 40.838FT-ot jelentene, míg a középvállalkozásoknál 10 számítógépre vetítve, 136.120FT-ot jelent. A fogyasztás 1 kártyára vetítve folyamatos működés mellett 3192Wh ami megközelítőleg 3.2 kWh, 3 gép esetén ez már 9,6kWh , 10 esetén pedig 32kWh; az első esetben 350Ft míg a második esetben 1120 Ft-ot jelent hetente. A GT720-as videókártya ráadásul teljesítményben sokkal jobban elmarad ,mint amin elvégeztem CUDA-s GPU-s renderelést.

A videókártya az Nvidia GTX420, de ez 2014 november 5-én már nem kapható kereskedelmi forgalomba a vele egyenértékű kártya teljesítményben pedig GTX720. A köztes rétegben alkalmazott SSD a Kingston KC300-as volt melynek kereskedelmi ára 38.240 FT a fogyasztása a legrosszabb esetben is 2,5Wh ami egy hétre vetítve 420Wh ami 0,42 megközelítőleg 0,5kWh tehát 14,7Ft. Tehát kijelenthető, hogy GPU-val való renderelés sokkal nagyobb költséggel jár, mint a meglévő gépeket clusterbe szerverzni, a HOST-ba pedig SSD-t rakni.

Kijelenthető, hogy nagymértékben csökkenteni lehet ezzel a megoldással a renderelési időt.

Az alábbi táblázatban feltűntettem a pontos mérésemet a fogyasztásokról.

12.Konklúzió

A dolgozatomban összevetettem az egygépes rendszereket a GPU-val támogatott rendszerekkel illetve a Cluster-rel, a Clusternél pedig volt alkalmam GPU-s és nem GPU-s változatott is tesztelni. Méréseim alapján megállapítható volt, hogy egyértelműen a leggyorsabb a GPU-s Cluster rendszer míg a leglassabb az egygépes rendszer. Gazdaságilag megkérdőjelezhető a kis és középvállalkozások számára ez a fajta beruházás az ár/érték arányt és a fogyasztást figyelembe véve illetve a beruházás idejének megtérülését.

A második leggyorsabb rendszer a GPU nélküli Cluster rendszer volt, ahol egy köztes réteget raktam a Host alá így a 10-es fejezetben taglalt hiba mérséklődni tűnt. Az SSD használata sokkal gazdaságosabb, mint a videokártyás megoldás illetve az SSD élettartama is igen magas, ha a gyári adatokat vesszük figyelembe. Az élettartamra való mérést a 10.2-es táblázatban fejtettem ki.

Dolgozatomban több konfigurációt is kipróbáltam, több render engine-t is, a beállításokat a 6-os fejezetben a render engine-ek alatt leírtam, hogy a mérések újra produkálhatóak legyenek. Render engine-ként 10-15 fajta beállítás alapján választottam ki az optimálisat.

Ezenkívül egyéb vizsgálatokat is elvégeztem, mint például az általam modellezett objektumok más szoftverekben való alkalmazása, akár anyagvizsgálatra felkészítve akár 3D nyomtatásra is felkészítve.

A 3D-s objektumok ezenkívül 3D-s bemutató termekben is kiállíthatók a Unity Engine alkalmazásával, így a vevő nem csak képen láthatja a terméket, hanem 3D-ben akár weboldalon, akár PC/MAC-en önállóan futatható programként, akár mobil készüléken (Android, Windows Phone, IOS) is megtekintheti, körbe forgathatja a modellt, ránagyíthat stb.

Nézd nagyban ezt a videót!

#video#//www.youtube.com/v/Tnq_YyQBR7Y?rel=0#videoforras#//www.youtube.com/v/Tnq_YyQBR7Y?rel=0#videovege#

Nézd nagyban ezt a videót!