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