THESE
PAGES ARE FREE OF
JAVA
JAVASCRIPT
FRAMES
STORED ON A LINUX SERVER, AND RUNNING SPACEHAWKS' OWN LINUX BASED VOTING
AND MESSAGE BOARD CGI.
NO MICROSOFT RELATED PROGRAMS WERE USED TO CREATE THIS SITE.
|
![](../../images/v4design/left2.jpg) |
![](../../images/v4design/left3.jpg) |
![](../../images/v4design/left4.jpg)
![](../../images/globe.gif) |
|
SPACEHAWKS
WORLDNEWS
ISSUE 17 |
|
|
|
Hierarchikus
animáció
Tornado 3D-ben
|
![](../../images/9909/t3dtank.gif)
DOWNLOAD
MPEG ANIMATION
Lévén Simca
az AmigaVilág oldalain meglehetôsen kimerítôen látott neki a Tornado3D-vel
való foglalkozásnak, rohamtempóban számolja fel azokat a területeket benne,
amelyrôl még leírás készíthetô, kénytelen voltam kicsit elôrébb ugrani mint
eredetileg gondoltam, megpróbálva azért nem eltávolodni a kezdô szinttôl.
Ezért esett választásom olyan gyermekien egyszerű dologra, mint a hierarchikus
animáció.
Ez tulajdonképpen
nem különbözik sokban a szabvány animációtól, amikor egy golyó egyik helyrôl
a másikra vándorol. Az egyetlen különbség tulajdonképpen azzal a példával
jellemezhetô legjobban, ahol animációként egy bolygó mozog egy ellipszisen.
Ennek hierarchikus animáció változata például az, ha nem csupán a bolygó ezen
ellipszisen leírt mozgását modellezzük, hanem a bolygó körül kering mondjuk
egy hold is.
Tudom nem
a legjobb példa volt, viszont könnyen átlátható: egyébként hierarchikus az,
ha a tárgyak között szülô-gyermek viszony áll fenn, azaz groupba vannak kötve.
Ekkor a szülô elfordulása például maga után vonja a gyermek object szülô object
körüli elfordulását, míg a gyermek objektum elfordulásának nincsen kihatása
a szülô objektumra. Minden transzformáció tehát csupán a hierarchiában az
adott objektumra és az annál a hierarchiában kisebb helyet elfoglaló objektumokra
lesz hatással.
A példában
ezt igyekeztünk megmutatni, ahol is egy lánctalpas légvédelmi jármű az igazi
fôszereplô. Lévén az objektum még annak idején Imagine 4-ben készült (de rég
is volt ez), a példa különösen jól mutatja a Tornado 3D használhatóságát.
Csapjunk is a lovak közé...
Aki mélyrehatóbban
használt már Imagine-t, és próbálta már objektumait más programokba átvinni,
az alighanem tudja, hogy nem született még tökéletes konverter. Ennek csak
egy része az, hogy a raytracerek többsége agresszíven normálisokra épülô,
míg az Imagine köztudottan nem. Ezt már csak tetézi, hogy group rendszerét
még mindig nincs konverter ami tökéletesen tudná olvasni.
Egyszóval
nem könnyű az Imagine felhasználó élete, ha valahova máshova kell vinnie munkáját.
Nincs ez másként ebben az esetben sem, annak ellenére, hogy a Tornado 3D képes
Imagine objektumok importjára, azonban ez sem jobb, mint bármely másik konverter.
A kielégítô
eredmény érdekében tehát a theendônk a következôk. A munkát elôször is Imagine-ben
fogjuk kezdeni. Van egy különbözô objektumokból álló groupunk, amit lehetôleg
így egyben kellene átszállítani Tornado 3D-be. Elsô dolgunk elôször is látszólag
ezzel gyökeresen ellentétes: ugyanis a teljes group csoportot fogjuk, és megszüntetjük
közöttük a kapcsolatot közöttük. (UnGroup) Ahhoz, hogy a csoportunkat hibátlanul
tudjuk átvinni, minden egyes gyermekobjectumot, valamint az ôsszülôt is külön-külön
kell átvinnünk . Minden objektumot, amelyek csak és kizárólag együtt fognak
mozogni, csak eddig mondjuk groupként voltak összekötve a Join parancs segítségével
egyesítsünk, hogy leegyszerűsítsük az átvitel műveletét. A megmaradt objektumokat
ne mozgassuk, hagyjuk eredeti helyükön ôket, majd egyesével mentsük el ôket.
Ha ez megtörtént,
egymás után Tornado 3D-ben import segítségével betöltve az objektumokat tapasztalhatjuk,
hogy a méretük és pozíciójuk megmaradt ugyanannak, mint amit még Imagine-ben,
a csoporton belül elfoglaltak. Objektumaink egyike-másika azonban (sokszor
egyik sem) nem úgy néz ki ahogy kellene. Lyukak vannak rajtuk, face-k hiányoznak,
stb. Ez csak látszólag végzetes hiba, arról van szó, hogy a normális orientált
render környezetekben a face-knek csupán egy oldaluk van, míg Imagine-ben
alapból 2 oldala van minden létrejövô face-nek. (A normálisokra épülô gyorsabb,
a kétoldalas normálisabb. Van itt képzavar rendesen...) Egyesével flipelgetni
a normálisokat ugyan lehet, csak nem érdemes. Egy nem zárt test például egy
másik nézetbôl lehet, hogy megint lyukasnak fog látszani. Szerencsére azonban
Tornado 3D-ben (is) van lehetôség arra, hogy az objektumot alkotó face-eknek
mindkét oldala megrajzolásra kerüljön. Ehhez jelöljük ki egyesével objektumainkat,
és tulajdonságaik között (F7) x-eljük ki a Two Faces opciót.
Ezt követôen
ki kell jelölgetnünk ismét a csoportokat. Csakúgy mint Imagine-ben a szülô
objektumot jelöljük ki elôször, ehhez csatoljuk a shift gomb nyomvatartása
mellett a gyermekét, majd a Modify/Structure/Group segítségével hozzuk létre
közöttük a csoportkapcsolatot.
Ha végeztünk,
elvileg ugyanazt a csoportot kell kapjuk, mint amit Imagine-ben szétszedtünk.
Ha tulajdonságaikat, és kinézetüket is beállítottuk, akkor immár hozzá is
láthatunk az animáció megalkotásához.
Mivel a dolog
lényegében hasonlítani fog egy normális animációhoz, nem árt ha elolvassuk
az AmigaVilágban Simca cikkének ide vonatkozó részét, bár köszönhetôen a Tornado
3D-nek, ez leírás nélkül is legalább egy gyerekjáték egyszerűségével bír:
persze oda kell figyelnünk egy két apró stiklire is.
Elôször is
nézzük meg objektumunkat. Mint láthatjuk, áll egy lánctalpas hordozófelületbôl,
egy azon található tartórészbôl, amely teljesen a hordozófelületen teljesen
körbeforgatható, valamint ezen a tartórészen van egy rakétaállvány, amely
a tartórészhez képest felemelhetô.
Célanimációnkon
annyi lesz látható, hogy a rakéták felemelkednek. Ha animációnk nem tartaná
be a hierarchia és a kapcsolódó pontok körüli forgás szabályait, akkor a kezdeti
és végállapot között a rakéták és a tartórész függetlenül mozognának, messze
nem realisztikus látványt tárva elénk. (Nyugodtan készíthetünk egy ilyen verziót
is csoportba nem kötött objektumainkkal, olyan lesz, mintha egy varázsló reptetné
ôket a helyükre.)
Animációnk
megvalósításához úgy fogunk hozzá, hogy rögzítjük a kiindulási állapotot.
Mozgassuk a megfelelô helyre tankunkat, majd váltsunk át animáció módba (TAB),
és rögzítsük a rakétatank helyzetét. (piros, REC gomb).
Igen ám,
de ezzel csak a csoport helyzetét rögzítettük, a csoport tagjainak egymáshoz
viszonyított helyzetét nem.
Mivel animációnkban
forgatást fogunk alkalmazni, válasszuk ki a tartórészt, majd a forgatás gombot
nyomvatartva bökjünk valahova az editor részbe. Na ekkor kapjuk az arcunkba
a következô kérdést:
Request
- Editing children during an animation requires a link pose keyframe. Create
one now? OK/Cancel
Ami közli,
hogy a csoporton belüli objektumok egymáshoz viszonyított helyzetének tárolásához
a Tornado 3D-nek nem elég a normal keyframe, szüksége van egy "link pose keyframe"-re,
ami körülbelül kapcsolt elhelyezkedés kulcsfázisának fordítható. Ezzel a kérdezôvel
ajánlja fel, hogy megcsinálja-e helyettünk?
Természetesen
igen a válasz. Ha ezt elfelejtenénk, és késôbbi kulcsfázisok (keyframe) alatt
mégis módosítanánk a csoporton belüli elhelyezkedésen, akkor sajnos vissza
kellene jönnünk, és újra beállítani az eredetit, mert elállítódna.
Ismételjük
meg ezt a rakétákat tartó vázzal is, majd hozzunk létre a következô kulcsfázist.
Taszajgáljuk elôre tankunkat, valamint változtassunk a tartórész és a rakétaállvány
helyzetén is.
Tulajdonképpen
nem trükk, csupán egyszerűen végiggondolható szükségszerűség, hogy ha tankunk
elôrehaladását folyamatosnak szeretnénk látni, akkor a második kulcsfázis
elkészítése elôtt az utolsó frame-en állítsuk be végsô helyzetét, és az ezt
megelôzô kulcskockákban a már kiszámított helyzetét rögzítsük. Lépjünk tehát
mondjuk a 75-dik frame-re (mivel alapból 25 frame egy másodperc, ezért 00:00:03:00-ra),
és az állapotokat a REC segítségével rögzítsük.
![](../../images/9909/t3dsnap.gif)
Mehetünk
vissza 25-re (00:00:01:00), és rögzítsük ismét a tank helyzetét. Most pedig
fordítsuk el a tartórészt az Y tengely körül. (az ismét feltett kérdésre ismét
csak válaszoljunk igennel) Láthatjuk, hogy míg a tank lánctalpas hordozófelülete
mozdulatlan maradt, a tartórész és gyermeke, tehát a rakétaállvány is elfordult.
Rögzítsük helyzetét ennek, majd fordítsuk el az X tengely mentén (emeljük
fel) a rakétákat az állványukkal együtt. Jól láthatóan a group csatlakozási
pont körül fordulnak el, ahogy kell, ha azt jól helyeztük el (tulajdonképpen
ez a tárgy axis-a). Rögzítsük ezt a változtatásunkat is, majd lépjünk vissza
00:00:00:01-re, és játsszuk le animációnkat.
Ha mindent
jól csináltunk, akkor az elsô 25 frame során a hordozófelületen elfordul a
tartórész, vele együtt fordul és felemelkedik a rakétaállvány is - csakúgy
mint a valóságban. És éppen ez volt ugye a célunk, gratulálhatunk magunknak,
megy ez mint a karikacsapás...
Ahhoz pedig,
hogy ezzel barátaink elôtt is jól felvághassunk miután a többi kulcsfázist
is megfelelôen beállítottuk, nincs más dolgunk, mint hogy a Render menüben
(F10) egyszerűen a current frame kapcsolót bökjük át sequence állásba, és
ha van elég ramunk, már mehet is a render, ha nincs túl sok, akkor az Output
részben az elérési utat állítsuk át Ram diskrôl a vincseszterünk valamelyik
partíciójára. Legvégül pedig IFX-ben vagy UltraConverterben a tga/iff képek
sorozatát konvertáljuk át animációba, ami lehet mondjuk csakúgy mint jelen
esetünkben MPEG.
És hogy mi
lesz a végeredmény... Hát amit a download részben letölthet akárki. Remélem
egyszerűsége dacára is jól példázza a cikk tartalmát... (Az MPEG-re való konverzió
ideje többszöröse volt a render idônek... Pedig az is PPC procival történt...)
Emeric SH
|