Tutorial Manipulasi Sistem Partikel di Delta 3D

Tutorial Manipulasi Sistem Partikel di Delta 3D

Semua efek partikel dapat dilakukan melalui PSE, dan dimasukkan dalam model. Saat ini, kontrol yang tersedia hanya untuk menghidupkan dan mematikan emitor. Mengendalikan partikel, memungkinkan pengguna untuk merasa lebih tenggelam dalam permainan atau simulasi. Seperti kecepatan angin, suhu, bahkan kehadiran suara bisa memicu suatu peristiwa yang menyebabkan partikel tersebut bertindak secara berbeda. Tutorial ini akan membantu anda melakukan itu, seperti mengubah warna, kecepatannya, masa hidup, massa, dan masih banyak lagi.

Untuk demonstrasi, kita akan mengubah partikel kecil yang berada di belakang tank sesuai dengan kecepatan tank. Ini akan membuat debu partikel tinggal di udara lebih lama ketika anda mengemudi dengan cepat, seperti dalam kehidupan nyata! Ini adalah partikel editor yang digunakan untuk menciptakan efek.

Bagaimana mendapatkan data partikel?

Catatan: Kode berikut ini sudah ada di dtCore:: fungsi ParticleSystem SetupLayers. Ini menunjukkan bagaimana mengaksesnya dan memberikan pengertian yang lebih baik dari apa yang kita peroleh. Setelah partikel diinisialisasi, pengguna akan berhadapan dengan setiap lapisan yang terpisah melalui GetSingleLayer ("Layer 0"), pemanggilan fungsi.

Untuk memperoleh data partikel mengharuskan kita untuk bekerja secara langsung dengan kode OpenSceneGraph (OSG). Mungkin lebih mudah mengatakan daripada dilakukan, jadi mari kita lakukan!

Pertama kita akan mendeklarasikan sebuah kelas yang akan memiliki semua informasi tentang partikel, untuk setiap layer dari setiap sistem partikel. Kelas akan mengikuti anggota variabel yang berisi kelas sistem partikel. Kelas ini akan disebut dengan ParticleLayer.

From dtCore::ParticleSystem (h and cpp)

/**

* geode yang memiliki sistem partikel dapat ditarik,

* dan diberi nama layer.

*/

RefPtr mGeode;

/**

* Sistem partikel aktif.

*/

RefPtr mParticleSystem;

/**

* Transformasi yang mengontrol posisi dari emitter.

*/

RefPtr mEmitterTransform;

/**

* Emitter aktif.

*/

RefPtr mModularEmitter;

/**

* Program aktif.

* Dapat membuat modular dan cairan

*/

RefPtr mProgram;

/**

* nama layer

*/

std::string mstrLayerName;

Semua variabel di atas digunakan di fungsi SetupParticleLayers. Mereka masing-masing mempunyai tujuan yang dapat memanipulasi dan mengatur efek partikel. Pengisian kelas ini dari luar tidak sulit, tetapi kode ini tidak diatur dalam bentuk hirarki yang anda inginkan. 

Metode berikut ini dipanggil saat anda membuat sistem partikel dengan metode LoadFile, dan tidak perlu dipanggil secara langsung. Setelah LoadFile selesai, Anda dapat menggunakan kelas ParticleLayer untuk mengubah nilai yang berbeda. Anda tidak perlu menulis kode ini, namun disediakan untuk membantu anda memahami isi sistem partikel OSG.

dtCore::ParticleSystem (h and cpp)

/**

 *  Memanggil fungsi LoadFile(), sebaiknya tidak memanggilnya 

 *  dari user

 */

void ParticleSystem::SetupParticleLayers()

{

  osg::Group* newParticleSystemGroup = (osg::Group*)mLoadedFile.get();

   osg::Node*  searchingNode = NULL;

   unsigned int i = 0;

Catatan: kita akan melakukan looping melalui semua children sebanyak dua kali, yang pertama dilakukan untuk setup sistem partikel awal, dan yang kedua untuk mengatur variabel lain, kemudian disatukan. Hal ini dilakukan, sejak kita mendapatkan perintah children yang lain, tapi perlu mengetahui variabel layer sistem partikel yang lain.

   for(i=0;igetNumChildren();i++)

   {

      searchingNode = newParticleSystemGroup->getChild(i);

      ParticleLayer layer;

      if(dynamic_cast(searchingNode))

      {

    //Ini terjadi ketika mengimpor beberapa file osg dalam satu sistem.

// Satu untuk setiap file dapat diambil, untuk memberitahu sistem //segala sesuatu yang lain ada di sini.

      }

      // Jika ini adalah sistem partikel yang geode      if(dynamic_cast(searchingNode))

      {

         // sebuah geometrinya node.

         layer.mGeode = (osg::Geode*)searchingNode;

         for(unsigned int j=0;jgetNumDrawables();j++)

         {

             osg::Drawable* drawable    = layer.mGeode->getDrawable(j);

   // Tampak seperti kami menemukan sistem partikel, lanjutkan!             if(dynamic_cast(drawable))

             {

                layer.mParticleSystem = (osgParticle::ParticleSystem*)drawable;

                layer.mstrLayerName     = layer.mGeode->getName();

               // We're done setting values up, push it onto the list

               mlLayers.push_back(layer);

             }

         }

      } // akhir if                        

   }// akhir dari perulangan for

   for(i=0;igetNumChildren();i++)

   {

      searchingNode = newParticleSystemGroup->getChild(i);

      if(dynamic_cast(searchingNode))

      {

       osg::MatrixTransform* newEmitterTransform = 

            (osg::MatrixTransform*)searchingNode;

         for(unsigned int j=0;jgetNumChildren();j++)

         {

            osg::Node* childNode = newEmitterTransform->getChild(j);

             if(dynamic_cast(childNode))

             {

    osgParticle::ModularEmitter* newModularEmitter = 

                   (osgParticle::ModularEmitter*)childNode;

               for(std::list::iterator layerIter = mlLayers.begin();

               layerIter != mlLayers.end(); layerIter++)

               {

                  if(layerIter->mParticleSystem == newModularEmitter->getParticleSystem())

                  {

                     // mengatur data dalam layer

                     layerIter->mEmitterTransform    = newEmitterTransform;

                     layerIter->mModularEmitter      = newModularEmitter;

                  }

               }

            }

         } // akhir dari perulangan for

      } // akhir dari perintah if

      else if(dynamic_cast(searchingNode))

      {

         osgParticle::ModularProgram* newModularProgram = (osgParticle::ModularProgram*)searchingNode;

         for(std::list::iterator layerIter = mlLayers.begin();

         layerIter != mlLayers.end(); layerIter++)

         {

            if(layerIter->mParticleSystem == newModularProgram->getParticleSystem())

            {

               // mengatur data di layer

               layerIter->SetModoluarProgram(true);

               layerIter->mProgram  = newModularProgram;

               break;

            }

         } // akhir dari perulangan loop

      } // akhir dari perintah if

      // memeriksa dan melihat apakah ini adalah sebuah program fluida      else if(dynamic_cast(searchingNode))

      {

         osgParticle::FluidProgram* newFluidProgram = (osgParticle::FluidProgram*)searchingNode;

         for(std::list::iterator layerIter = mlLayers.begin(); 

               layerIter != mlLayers.end(); layerIter++)

         {

            if(layerIter->mParticleSystem == newFluidProgram->getParticleSystem())

            {

               // mengatur data di layer

               layerIter->SetFluidProgram(true);

               layerIter->mProgram  = newFluidProgram;

               break;

            }

         } // akhir dari perulangan for 

      } // akhir dari perintah if

   } // akhir dari perulangan for 

}// akhir dari pemanggilan fungsi

Dari sini, kita memiliki semua daftar partikel layer yang dimuat di file OSG. Setiap efek dalam file pada ParticleLayer dengan di std::list berbeda. Untuk mendapatkan layer kembali dan mengubah semua efek yang dimasukkan, sama sederhananya seperti memanggil GetSingleLayer() dan mengirim sebuah string dari nama yang Anda inginkan.

Ini akan mengembalikan sebuah referensi ke ParticleLayer, yang pada gilirannya akan memberikan Anda akses untuk mengubah apa pun yang Anda inginkan dengan efek partikel. Yang kami inginkan adalah default partikel.

Ikhtisar Hierarchal:

Sebagian besar, segala sesuatu dalam kelas berada di bagian bawah Processor Partikel. Ini adalah dasar bagi antarmuka kelas yang melakukan sesuatu pada partikel. Contoh kelas yang untuk emitor contoh (generasi partikel) dan program (animasi partikel). Kela

s ini memiliki beberapa sifat, seperti bingkai referensi dan referensi ke ParticleSystem; partikel harus di proses dengan kelas-kelas turunan dengan mempertimbangkan kerangka acuan, komputasi transformasi yang tepat bila diperlukan.

OpenScene Graph Documentation For the Overview

Sistem Partikel OSG:

sistem partikel osg sebagian besar adalah kelas utilitas. Kelas ini dapat memberitahu Anda untuk membekukan seluruh sistem, mengembalikan jumlah partikel, menentukan apa jenis permukaan, dll. Memanfaatkan sistem yang akan bekerja keras pada sebuah permainan dengan menggunakan frame membekukan / menghentikan animasi, dan Anda dapat membekukan sistem partikel Anda untuk memberikan efek yang baik.

OpenScene Graph Documentation For the particle system

Partikel Default:

Semua Partikel terbuat dari partikel Template.

Artinya, pengaturan yang pertama kali dimuat di file, membuat default Template Partikel. OSG Template Default sama seperti Partikel lain, kecuali digunakan sebagai template untuk membuat partikel baru. Sekarang mari kita lanjutkan.

Untuk mendapatkan akses ke partikel default kita harus melalui Sistem Partikel dan mendapatkannya di sana. Akibatnya ketika Anda selesai, Anda harus menempatkan partikel default kembali ke dalam Sistem Partikel dan semua partikel baru mengambil keuntungan dari perubahan. Karena kita akan kembali. Namun, dalam situasi ini, Anda tidak akan kembali ke dalam sistem.

Berikut ini daftar beberapa anggota yang dapat mengubah partikel Default:

void setLifeTime (double t) mengatur waktu hidup partikel.

void setSizeRange (const rangef &r) mengatur angka minimum dan maksimum ukuran polygon.

void setAlphaRange (const rangef &r) mengatur angka minimum dan maksimum alpha.
void setColorRange (const rangev4 &r) mengatur nilai minimum dan maksimum warna.
void setSizeInterpolator (Interpolator *ri) mengatur interpolator untuk komputasi nilai-nilai ukuran.
void setAlphaInterpolator (Interpolator *ai) mengatur interpolator untuk komputasi nilai alpha.
void setColorInterpolator (Interpolator *ci) mengatur interpolator untuk komputasi nilai-nilai warna
void setRadius (float r) Atur radius fisik partike

l.

void setMass (float m) Mengatur massa partikel.
void setPosition (const osg::Vec3 &p) Mengatur posisi vektor.
void setVelocity (const osg::Vec3 &v) Mengatur vektor kecepatan.

Untuk daftar lengkap sebuah partikel, ikuti link ini:

OpenScene Graph Documentation for a particle class

Setelah Anda selesai mengubah nilai, masukkan kembali ke dalam partikel Template Default, dan semua partikel baru yang dibuat dari template / emitor yang memiliki efek yang diinginkan. Catatan ini tidak akan mengubah partikel saat ini. Biasanya, partikel lama dan baru berbaur bersama-sama secara alami.

Modular Emitter:

modular emitor digunakan untuk menentukan jumlah partikel yang bisa dibuat. Mengubah jumlah partikel ini akan memberikan pengaruh pemijahan partikel kurang ataun lebih. Hal ini akan menjadi besar untuk digunakan pada api dan meredakan dari waktu ke waktu.

Emitor ini memiliki Shooter dan Placer objek di dal

amnya. Placers adalah di mana partikel-partikel tersebut dilakukan dengan menembakan kontrol di mana mereka pergi setelah mereka telah "Ditempatkan".

OpenScene Graph Documentation for a modular emitter

Emitter Transform:

Emitor Transformasi digunakan untuk memindahkan emitor sekitar dan dari posisinya. Cara agar bisa menggunakannya, adalah jika Anda memiliki kapal berlayar menyusuri sungai dan ingin menciptakan efek gelombang yang berbeda dari offset kapal.

OpenScene Graph Documentation for a transform

Mengatur layer:

Ketika kami menangkap variabel melalui GetSingleLayer() semua perubahan akan dibuat tanpa memanggil metode yang ditetapkan. Namun, jika dalam kode, Anda merasa perlu untuk mengatur kembali layer, anda dapat memanggil SetSingleLayer ().

Berinteraksi dengan simulasi tangki:

Melalui program simulasi tangki, kita akan menguba

h jejak asap berdebu yang melekat pada tangki, untuk memberikan kenyataan lebih didasarkan pada kecepatan tangki. Singkatnya, kita akan membuat Seumur Hidup dari partikel pendek atau didasarkan pada kecepatan tangki.

Pada fungsi MoveTheTank tangki, saya menambahkan sebagai berikut:

if(mDust.valid() && mIsEngineRunning && mVelocity != 0)

{

   // Mendapatkan layer yang diinginkan

   dtCore::ParticleLayer& pLayerToSet = *mDust->GetSingleLayer("Layer 0");

    osgParticle::Particle& defaultParticle = pLayerToSet.GetParticleSystem().getDefaultParticleTemplate();

   // melakukan perubahan funky

   float lifetime = max(2.0f, abs(mVelocity) * .4f);

   defaultParticle.setLifeTime(lifetime);

pLayerToSet.GetModularEmitter().setNumParticlesToCreateMovementCompenstationRatio(abs(mVelocity) * 0.10f);    

}

Sekarang ketika Anda memindahkan tangki yang memiliki partikel, maka partikel tersebut akan berubah sesuai dengan kecepatan kendaraan Anda. Keren!

Referensi:

http://www.delta3d.org/article.php?story=20060622140124995&topic=tutorials

Game Komputer

Computer Game


Personal Computer Game (juga dikenal sebagai permainan komputer atau game PC) adalah permainan yang dimainkan di komputer pribadi, bukan pada video game konsol atau mesin arcade. permainan komputer telah berevolusi dari grafis sederhana dan game dari judul awal seperti Spacewar, dengan berbagai judul yang lebih visual canggih.!

game PC yang dibuat oleh pengembang satu atau lebih permainan, biasanya bersama dengan spesialis lainnya (seperti seniman permainan) dan dipublikasikan baik secara mandiri atau melalui penerbit pihak ketiga. Mereka kemudian dapat didistribusikan pada media fisik seperti DVD dan CD, sebagai internet-download, mungkin dapat didistribusikan secara bebas, perangkat lunak, atau melalui jasa pengiriman online seperti Direct2Drive dan Uap. game PC sering membutuhkan hardware khusus di komputer pengguna untuk bermain, seperti generasi spesifik unit pemrosesan grafik atau koneksi internet untuk bermain online, meskipun persyaratan sistem ini bervariasi dari satu pertandingan ke pertandingan.


Pengertian Game Engine

Game Engine adalah system perangkat lunak yang dirancang untuk menciptakan dan pengembangan video game. Ada banyak mesin permainan yang dirancang untuk bekerja pada konsol permainan video dan sistem operasi desktop seperti Microsoft Windows, Linux, dan Mac OS X. fungsionalitas inti biasanya disediakan oleh mesin permainan mencakup mesin render ( “renderer”) untuk 2D atau 3D grafis, mesin fisika atau tabrakan (dan tanggapan tabrakan), suara, script, animasi, kecerdasan buatan, jaringan, streaming, manajemen memori, threading, dukungan lokalisasi, dan adegan grafik. Proses pengembangan permainan sering dihemat oleh sebagian besar menggunakan kembali mesin permainan yang sama untuk menciptakan permainan yang berbeda.


3 Game Engine

Delta3D adalah open-source game / mesin simulasi. Desain modular Delta3D's mengintegrasikan lain terkenal proyek Open Source seperti OpenSceneGraph, Open Dynamics Engine, Cal3D, dan OpenAL, mengintegrasikan mereka dalam sebuah API yang mudah digunakan. Daripada mengubur modul yang mendasari, Delta3D mengintegrasikan mereka bersama-sama, memungkinkan akses ke komponen penting yang mendasari. Ini memberikan tingkat-tinggi API sementara masih memungkinkan pengguna akhir fungsi, opsional tingkat rendah.


Ogre (Object-Oriented Graphics Rendering Engine) adalah sebuah adegan yang berorientasi fleksibel rendering engine 3D (sebagai lawan mesin permainan) ditulis dalam C + + dirancang untuk membuatnya lebih mudah dan intuitif bagi pengembang untuk menghasilkan aplikasi yang menggunakan grafis 3D hardware-accelerated. The abstrak perpustakaan kelas rincian menggunakan sistem perpustakaan yang mendasari seperti Direct3D dan OpenGL dan menyediakan sebuah antarmuka berbasis pada objek lain kelas dunia dan tingkat tinggi.


Irrlicht adalah sebuah mesin 3D open source yang ditulis dalam C + +. Ini adalah cross-platform, secara resmi berjalan pada Windows, Mac OS X, Linux dan Windows CE dan karena open port alam untuk sistem lain termasuk Xbox, PlayStation Portable, SymbianOS dan iPhone yang tersedia . Irrlicht dikenal karena ukurannya yang kecil dan kompatibilitas dengan perangkat keras baru dan tua sama, kurva belajar dangkal dan masyarakat yang ramah besar. Unofficial binding untuk banyak bahasa yang ada termasuk NET,. Jawa, perl, Ruby, Python, FreeBASIC, Lua, Delphi, C + + Builder dan bahkan Game Maker. Irrlicht pembangunan mulai tahun 2003 dengan hanya satu pengembang, Nikolaus Gebhardt. Hanya setelah rilis 1.0 dari Irrlicht pada tahun 2006 tim tumbuh untuk saat ini sepuluh anggota, pengembang kebanyakan dari mereka.


Jenis-jenis Game

Terdapat berbagai macam game, yaitu antara lain:


1. Fun Games


Fun games adalah permainan seperti : skate board, bilyard, catur, puzzle, tetris, golf, Windows Entertainment Pack Games dan semua permainan yang animasinya sedikit dan pembuatannya relatif mudah. Permainan semacam ini terlihat mudah dari segi grafiknya tetapi biasanya sulit dalam algoritma.


2. Arcade Games


Arcade games adalah semua permainan yang mudah dimengerti, menyenangkan dan grafiknya bagus walau biasanya sederhana. Pengertian mudah dimengerti dan menyenangkan dikarenakan permainan ini hanyalah berkisar pada hal-hal yang disenangi umum seperti pukul memukul, tembak menembak, tusuk menusuk, kejar mengejar dan semua yang mudah dan menyenangkan. Yang termasuk kedalam permainan jenis ini adalah Prince of Persia, Street Fighter, Golden Axe, Grand Prix, Robocop.


3. Strategic Games


Strategic games biasanya permainan strategi perang atau bisa juga permainan lain tetapi tetap saja memerlukan strategi untuk memenangkannya seperti startegi bisnis dan strategi politik.


4. Adventure Games


Adventure games terbagi atas tiga macam yaitu petualangan biasa (Multi Layered Adventur), Dungeon-Underworld Adventure (3D Adventure) dan Roll Playing Game Adventure. Biasanya algoritma untuk membuat game ini adalah sedang-sedang saja sampai sulit. Tapi grafik jenis permainan ini benar-benar sulit. Contoh beberapa permainan jenis ini adalah Space Quest IV, Labyrinth of Word, War II dan Diablo.



5. Simulation Games


Dari semua jenis permainan yang ada, masing-masing memiliki tingkat kesulitan dan kemudahannya, jika bukan algoritmanya maka akan mudah dalam hal animasinya, akan tetapi games simulasi bisa disebut sebagai jenis permainan yang paling sulit, baik algoritma pembuatannya maupun animasinya. Permainan jenis ini juga yang paling membuat pusing dibandingkan dengan permainan jenis lainnya. Algoritmanya sangat sulit sebab harus memperhitungkan semua kejadian dalam kondisi sebenarnya. Berbagai efek animasi yang dibuat tidak cukup bermodalkan ahli grafik dan algoritma saja, tetapi sedikitnya harus mengerti persoalan matematika, teknik dan fisika. Contoh permainan jenis ini adalah Stellar7, F-15 Strike Eagle, Flight Simulator 98, F-14 Tomcat, F-16 Falcon, Jet Fighter.

Creating Actor

Creating an Actor Tutorial, Part 1 – Overview and Concepts

So you’ve gotten the hang of STAGE. You’ve made some interesting worlds by placing and arranging static meshes. But, to finish your application, you need something more. After all, a few Static Meshes and a Sky Box doesn't make a game. You need trucks that move, game inventory objects, motion sensitive guards, or maybe even a rocket launcher. In short, you need the ability to make your own custom Actors! This tutorial teaches you all you need to know to make your own Actors. By following this 3 part tutorial, you will learn how to create a waving flag that you can use right in the editor. You will learn how to create a complex tessellated Actor, expose its size, speed, and height properties via an ActorProxy, and even make your flag accessible to the editor. This tutorial assumes you have already worked with STAGE. If not, please see the ‘Getting to Know the Editor’ tutorial. Note - this tutorial uses the word ‘Game’, ‘Simulation’, and ‘Training Application’ interchangeably. Part 1 – Actors and Proxies and Properties, Oh My! Before you can get started building that cool waving flag, there are a few things you need to know about how STAGE was built. The Delta3D Editor sits on top of a very dynamic architecture. In fact, STAGE was designed from the ground up to encourage customization. Since we could never anticipate what types of objects you’d need, we built an architecture that is completely generic and let you build your own game objects! Below are 3 key concepts you need to know. Actor – An Actor is any game object that has properties you want to work with in the Editor. An Actor can truly be anything you can imagine, from flying planes to pulsing lights to droppable guns to scaly green monsters. Actors are the specialized objects that help define your game or simulation. In part 2 of this tutorial, you will create your first Actor called ‘TesselationActor’. ActorProxy – An ActorProxy is a wrapper for an Actor. Proxies are simple, data oriented classes that have two main jobs. First, they provide a common, uniform class that the editor understands. Second, they know everything about the Actor they wrap, especially the properties. In part 2, you will create an ActorProxy for our flag called ‘TesselationActorProxy’. ActorProperties – ActorProperties are the properties of an Actor that show up in the PropertyEditor. Actor properties allow level designers to tweak and change how an object works. The more properties you expose, the more useful your object becomes. When you expose numerous important properties for your object, you allow level designers to take full advantage of your Actors without changing your code. In part 2, you will expose Actor properties for ‘Width’, ‘Height’, ‘Number of Steps’, ‘Period’, ‘Amplitude’, ‘Phase’, and ‘Texture’. By changing the values of these properties, you can change the size of your flag, make it move faster, give it more ripples, or even change the texture. The following picture shows some of the properties in the editor. Figure 1 – Tesselation Actor Properties Now that you know the basics about Actors and ActorProxies, there is one final step to address. Since the editor can’t magically find your ActorProxy classes, we need to tell it about our new object. What you need to do is put your ActorProxy into a library that the editor can find. Once you create this library you will be able to import it directly into the editor. Fortunately, this sounds harder than it is. In fact, as you’ll see in part 3 of this tutorial, it takes about 5 lines of actual code to do this. Plus, you will only need 1 library for ALL of your actors. OK. So, let’s sum up! To create any new Actor for STAGE, you will need to do the following steps: 1) Create your Actor – this is your specialty! 2) Create your Actor Proxy – simple data wrapper 3) Create an Actor Library - ONE time only 4) Add your Proxy to the Library – about 5 lines of code Now, you know enough about the basic architecture of STAGE to get started. Seriously, stop here! If you just want to know how to do something by example, it’s time to move on to Part 2 of the tutorial. However, if you’re the technical type and really want to know what’s going on, then you’ll be happy to know that we’ve got some great information ahead. As it happens, the Dynamic Actor Layer (DAL) was thoroughly designed before we ever wrote a line of code. Below is some of the detailed design material used in the construction of the DAL. 2. Dynamic Actor Layer (DAL) The Dynamic Actor Layer (DAL) provides a flexible, non-intrusive mechanism for generically exposing the properties of game actors in C++. The two primary components of this design are ActorProxies and ActorProperties. The proxy component is a wrapper for the underlying game actor and holds a collection of the individual properties. The property component exposes the data for a single game actor property via a getter and setter function object; similar to the Java bean specification. The proxy knows about its properties and the properties know how to access their data. These two components are used to generically expose all underlying data without ever modifying the original game actor code. Use of these data driven components, instead of the underlying game actor, promotes data encapsulation and code re-usability. Figure 2 - Overview The Dynamic Actor Layer and editor architecture overview is noted in Figure 2. The main purpose of the Editor is to allow for the manipulation of actors in a given scene. To support this, the DAL exposes a generic template allowing STAGE to work with actors as generic objects. The core of this concept is that each actor should be treated generically using only its name, id, and a collection of properties. A detailed description of the components of the DAL follows. 3. ActorProxy As mentioned above, Actors are any objects in your training application that have behavior and need to be manipulated in STAGE. Since the Actor classes can be anything, the editor must be protected from the internal workings of any one object. To make this happen each Actor must have a corresponding Proxy class that allows access to the internal properties. In essence, the ActorProxy is a conduit for actors to communicate their behavior to external applications or to ensure a consistent communications protocol among actors. Figure 3 shows a class diagram of the ActorProxy, Actor (DeltaDrawable), and ActorProperty. Figure 3 - ActorProxy Class Diagram The following is a description of the classes portrayed by the class diagram in Figure 3. DeltaDrawable This is the base class for all Actors in the system. The DeltaDrawable (dtCore::DeltaDrawable) is the base class of all Delta3D objects that are in the scene. In addition, it has tracking information like a tag name and a unique ID. MyTruck This is an example of a user built Actor class. Some of these will be built internally as part of the Editor, but many of these will be built by end developers and may be known only to their own particular application. Actor classes can be pretty much anything. They can have lighting, articulated parts, movement, AI, meshes, sounds, triggers, and anything else that you can do with Delta3D. They can draw themselves in anyway they sit fit within the Delta3D architecture. They can have many or zero properties, can have references to shared resources, and can be anything from a square billboard to a full blown landscape. ActorProxy This is the base class for all Actor Proxies. The Proxy’s main purpose is to expose the attributes of an Actor class as a series of properties. It has interface methods for getting and setting properties, getting its actor, and getting the actor’s type. Each actor must have a Proxy. The editor will periodically ask for properties by name or even change the value of the property using the setValue() method. MyTruckProxy This is an example of an actual user built Actor Proxy. In this case, the truck has a property called speed, so the Truck Proxy might expose a property called ‘speed’ to the editor. Then, Truck proxy could handle a request such as setProperty(“speed”, value) by calling myTruck.setSpeed (value). In this case, the TruckProxy knows the inner workings of the Truck class. It knows that speed is actually a floating point value. Many times the proxy will be a simple pass through for data. However, sometimes, the proxy will need to do manipulation of data. For instance, speed might have been represented by a vector of floats (xspeed, yspeed, and zspeed). In that case the proxy might have exposed 3 properties to the editor where there is only one underlying actual value. It might alternately have used a vec3. In either case, the proxy is responsible for knowing how to handle a setProperty(“xSpeed”, value) request and setting the internal speed value of the truck. 4. ActorProperty As stated above, the ActorProperty class provides a getter/setter mechanism for accessing properties of a class similar to the Java beans programming paradigm. Figure 4 depicts a more detailed view of the ActorProperty class including a subset of the property classes for a particular data type. Figure 4 - ActorProperty Class Diagram The getter and setter portions of the ActorProperty class are Functors (Function Objects) which reference a getter and a setter method on a given property class. Therefore, when an ActorProperty is created, it knows how to store and retrieve the data it represents. The ActorProperty class is also used to pass information about the properties of an Actor up to the Editor. It has a name, a display name, a description, and a type enumeration. The property class may also have a list of enumerations if the property is itself an enumeration. For example, a property of truck may be speed and it may support Slow, Medium, and Fast or a light may have a type property with settings of Directional, Strobe, Pulse, Omni, etc… 5. ActorLibraries Actor libraries are distributable components that serve to package groups of related actors and actor proxies. Actor libraries are dynamic libraries of C++ code that are loaded into the editor or other application. Figure 5 shows an overview class diagram of the Actor Library subsystem. A detailed description of each component is given below. Figure 5 - Dynamic Actor Layer Components LibraryManager This class is the main class in the Library Manager. It has a list of the libraries that are registered with the Manager as well as a list of which Actor Types each of the libraries can create. It is also the main vehicle for creating a new Actor Proxy. The Manager uses the singleton pattern. ActorPluginRegistry This is the base class that developers extend to build their own registry. The most important behavior in the registry is the ability to take an Actor Type and create a new Actor via the Actor Proxy. A registry is responsible for knowing which Actor types it can build. Since the Editor doesn’t know anything about object classes, the registry is responsible for figuring it out. The registry base class also exposes an object factory which provides most, if not all, of the ActorPluginRegistry’s Actor Type to Actor mapping capabilities. MyPluginRegistry This is a 3rd party implementation of the Registry. The developer will need to create and track which Actor Types it understands as well as be able to take an Actor Type and create a new Actor Proxy. This is likely a very simple class which creates and registers its actor types with the factory so that they are available at run-time. ActorType This is a simple data class that has information describing a particular Actor type. There will be one Actor Type for each unique Actor class like ‘BouncyTruck’ or ‘AgressiveSoldier’. For each actor class, there must be an Actor Type with a name, a category, and a description. The category is of particular note because it is used to visually sort classes in the editor. It follows a hierarchical dot notation (ex. “Vehicles.Trucks.NeatTrucks”) used to group related classes in some of the UI panels. It can also be used to search for objects. 6. Project / Map The project context is basically the “home” directory of your map. It is responsible for storing resources imported into the Editor; such as static meshes, particle systems, textures, and sounds. All of the imported actors in a map are stored and referenced relative to the project context of the map. The details of the Project and Map class interactions are beyond the scope of this tutorial; however Figure 6 shows a class diagram which depicts the basic interactions available to the Project and Map classes. Figure 6 - Project - Map Class Diagram

Animasi Mobil bergerak 3D

Gambar 1










Gambar 2









Gambar 3










Gambar 4









Gambar 5









Gambar 6










Gambar 7










Gambar 8










Gambar 9









Gambar 10









Gambar 11

Gambar 12










Gambar 13


TUTORIAL ANIMASI MOBIL

Di sini adalah mobil kita akan menghidupkan. Ini dapat yang sederhana seperti kotak untuk chassis, sebuah kotak untuk tubuh mobil, dan empat silinder untuk roda. Membangun mobil Anda dengan membuat kotak di viewport perspektif, seperti menghadap ke kiri, seperti ditunjukkan pada gambar di atas. Alasan untuk ini adalah bahwa ia akan menyelamatkan Anda kesulitan pada rotasi roda nanti. Melakukannya dengan cara ini menjamin roda anda akan berada dalam orientasi yang tepat untuk Y rotasi dengan persamaan. Setelah tubuh dan sasis mobil dibuat, membuat roda kiri depan dengan menggambar sebuah silinder dengan AutoGrid dihidupkan (AutoGrid memungkinkan Anda untuk menggambar 3d geometri pada geometri lain seperti badan mobil). Kemudian salin roda pertama untuk membuat roda belakang, lalu salin kedua roda kiri ke sisi kanan dari mobil.

Berikut adalah hirarki untuk mobil – nama benda-benda sehingga Anda dapat memberitahu apa yang dihubungkan dengan apa. Anda akan perlu menggunakan alat Pilih dan Link pada Standard Toolbar untuk menghubungkan bagian-bagian ini bersama-sama. Semuanya, yaitu, semua empat roda dan badan mobil, semuanya diasuh ke casis. Jika Anda belum pernah menggunakan Schematic Lihat antarmuka, mencobanya. Ini adalah cara terbaik untuk berurusan dengan link hirarkis.

Berikut ini adalah jalan bagi mobil kami – sebuah garis sederhana digambar dengan halus ditetapkan sebagai tipe default. Untuk realistis berubah, kebutuhan mobil kami jalan yang halus.

Pilih mobil chassis dan kemudian pergi ke menu dan pilih Animasi Path Kendala seperti yang ditunjukkan di atas. Kemudian klik pada jalur mobil. Ini akan menempatkan mobil chassis, dengan semua anak-anak, di jalan. The chassis akan pindah ke ketinggian jalan, sehingga Anda mungkin perlu memindahkan jalan yang lebih tinggi sehingga mobil tidak berada di bawah permukaan jalan Anda dengan asumsi Anda memiliki jalan.

Anda akan perlu untuk membuat beberapa penyesuaian dalam Motion Panel. Mengatur chassis untuk Ikuti Jalan di Path Pilihan. Juga, menyesuaikan Axis dan Flip sampai mobil bergerak ke arah yang benar di jalan. Perhatikan di sini bahwa kita menggunakan Timne Slider di bagian bawah Max antarmuka untuk melihat apa yang dilakukan mobil di berbagai bingkai dari animasi.

Ketika mobil berjalan di sepanjang jalan, apakah itu tampaknya memiliki kecepatan yang tepat? Mobilku tampaknya akan sedikit cepat, jadi aku Timne Konfigurasi mengklik tombol di bagian paling bawah layar – terlihat seperti sedikit stopwatch. Dalam kotak dialog Konfigurasi Timne, klik Re-skala Sisa (jangan kamu berharap kami bisa melakukan itu dalam kehidupan nyata?). Dalam skala Re Timne kotak dialog, klik End Time nilai dan mengubahnya ke 150 frame (atau apa pun yang Anda butuhkan). Dengan mengubah jumlah frame 100-150, dan kemudian menekan OK pada kedua kotak dialog, akhirnya aku membuat gerakan mobil di sekitar jalan 50% lebih lambat, hanya apa yang dibutuhkan.

Di sini kita di Top tampilan. Ini adalah perspektif yang baik untuk memutar badan mobil pada chassis untuk menciptakan realistis bersandar ketika mobil menabrak kurva. Di sini, di frame 29, kita mendorong mobil 5 derajat dan kemudian segera kembali lagi ke 0. Mengapa? Untuk membuat bingkai yang membuat mobil dari berputar sampai kita melewati langsung. Kemudian, ketika kita menambahkan ke mobil rotasi tubuh pada frame 35, itu tidak akan memulai aktual mobil rotasi tubuh sampai frame 29. Jadi kecil ini “dorongan” adalah penting. Perhatikan bahwa sudut alat Snap dihidupkan, sehingga kita bisa tepat dalam rotasi. Juga perhatikan di sini bahwa metode rotasi tubuh mobil diatur ke Lokal (lihat Standar Toolbar – ini penting). Jika Anda tidak menetapkan sistem koordinat Anda untuk Lokal, Anda akan berakhir dengan sebuah mobil yang berputar pada sumbu XYZ lain daripada sendiri, dan tidak akan beres.

Sekarang kita berada di jantung belokan kanan pertama kami. Mobil harus bersandar. Mobil memutar badan 15 derajat ke luar jalan. Pergi melalui proses ini, semua jalan di trek. Untuk saat berbelok, memutar badan mobil kiri, dan untuk bergantian kiri, memutar tubuh mobil kanan. Pastikan untuk menggunakan sebuah “dorongan” jika Anda ingin mengontrol ketika mobil berputar.

Selanjutnya kita akan membuat roda berbelok dengan menggunakan suatu persamaan, yang lebih mudah daripada memutar roda dengan tangan dengan Auto Key diaktifkan. Dalam rangka untuk melihat roda berbelok dengan benar, mereka membutuhkan bahan pada mereka. Kami akan menerapkan bahan kotak-kotak ini contoh sederhana. Pilih sebuah roda dan meluncurkan Material Editor dengan menekan tombol M. Pilih bahan gratis slot, dan nama Checkered materi Anda. Klik tombol di sebelah baur parameter, dan ketika anda melihat Material / Map Browser, klik-ganda pada Checker. Ini akan menghasilkan bahan checker untuk Anda.

Ketika menerapkan suatu bahan untuk suatu objek, pastikan objek yang dipilih, dan kemudian tekan tombol Apply Material to Selection tombol untuk menerapkan materi. Pastikan anda juga mengaktifkan tombol yang disebut “Tunjukkan Bahan dalam Viewport”. Perhatikan dalam gambar ini bahwa roda depan tampak cukup bagus, tetapi bahan roda belakang kurang tepat. Itu karena roda Anda memerlukan UVW Map. Screenshot berikutnya akan alamat ini.

Pilih roda belakang, dan dari daftar Modifiers, pilih UVW Map. Peta default jenis planar akan bekerja dengan baik di sini.

Sekarang untuk membuat roda gilirannya, pilih roda, pergi ke Motion Panel, dan klik di bawah Mentransformasi on Y Rotasi seperti yang ditunjukkan di atas. Kemudian klik “?” sebagaimana ditunjukkan. Ketika Tetapkan Controller muncul kotak dialog, pilih Float Expression. Ini seharusnya memunculkan Expression Controller, ditunjukkan di bawah ini.

Dalam Expression Controller di atas, masukkan rumus 360 * sin (S * 5) atau sesuatu yang mirip dengan sesuai dengan kebutuhan anda. Dalam persamaan ini, 360 adalah untuk derajat, dosa adalah untuk ekspresi trigonometri yang disebut sinus, yang kapitol S adalah untuk detik, dan angka 5 atau apa pun yang Anda gunakan untuk putaran tiap detik. Kemudian, tekan tombol Evaluasi pada kotak dialog Expression Controller. Jauhkan kotak terbuka dan menjalankan animasi untuk melihat seberapa baik kerjanya. Apakah anda memerlukan sedikit rotasi? Menurunkan angka 5 ke bawah untuk sesuatu seperti 2. Apakah roda salah jalan? Meletakkan – di depan 5 atau 2. Ketika gerakan satu roda terlihat bagus, salin persamaan dan ulangi proses ini untuk 3 roda yang lain.

Review Game

Sonic Unleashed

Sisa-sisa kejayaan konsol PlayStation2 tampaknya bisa diwakilkan oleh game terbaru keluaran SEGA ini, Sonic Unleashed (atau lebih dikenal Sonic World Adventure untuk versi Jepangnya) sebagai kisah lanjutan dari Sonic the Hedgehog. Dalam game ini, Sonic berusaha mengembalikan keadaan dunia menjadi normal setelah musuh bebuyutannya, Dr. Eggman, membuat dunia terpecah menjadi dua bagian besar menggunakan senjata baru ciptaannya beserta kekuatan Chaos Emerald yang dimilikinya.

Dampak dari dunia yang terbelah dua, Sonic Unleashed pun memiliki dua level yang berlainan, yakni saat siang hari dan malam hari. Suatu kejutan besar yang disisipkan oleh Sonic Team Japan sebagai developer game ini untuk membuat seakan dua game berbeda dibaur dalam satu kemasan apik. Kala siang hari, Sonic seperti biasa melaju kencang ke sana kemari, bahkan kini Sonic diberikan kemampuan untuk bisa mencapai kecepatan 300 mil/jam. Selebihnya mungkin agak berbau seri Sonic and the Secret Rings, dengan beberapa pengecualian, seperti penggunaan Hedgehog Engine untuk pertama kalinya yang memungkinkan tampilan grafis maksimal pada konsol PS3 dan Xbox 360. Meski, versi Wii dan PS2 juga menggunakan engine yang sama, tetap kualitasnya belum sebanding dengan kedua konsol yang disebut pertama. Begitu dengan PC.

Nah di malam hari, Sonic berubah menjadi sesuatu yang berbeda, dikarenakan pengaruh dari emerald yang dimiliki oleh Dr. Eggman maka setiap bulan muncul Sonic akan bertransformasi menjadi Werehog. Dalam bentuk ini, Sonic kehilangan kecepatan yang dia miliki, tapi sebagai gantinya Sonic menjadi super kuat. Jadi di sini kamu tidak lagi beradu cepat di tiap levelnya tapi justru mengandalkan kekuatan fisik untuk mengalahkan musuh-musuhmu. Jadi kesimpulannya, kalau di siang hari kamu bergantung pada kecepatan, maka saat malam hari intinya lebih ke eksplorasi dan unsur petualangan.

Kalau menilik tanggal rilis Sonic Unleashed yang agak beragam di beberapa tempat berdasarkan konsolnya, maka cukup diasumsikan saja game ini bakal rilis akhir tahun ini. Yang pasti game ini pertama kali akan muncul untuk konsol Wii dan PlayStation2 secara resmi mulai tanggal 18 November, kemudian versi Xbox 360 dan PS3 berbarengan rilis di Korea Selatan tanggal 20 November, baru yang paling terakhir di Jepang sekitar bulan Maret 2009.