TA : Rancang Bangun Framework Rendering Engine Untuk Pengembangan Aplikasi Berbasis Tiga Dimensi.

RANCANG BANGUN FRAMEWORK RENDERING ENGINE UNTUK PENGEMBANGAN APLIKASI BERBASIS TIGA DIMENSI

TUGAS AKHIR

Nama : Tivan Arnaz

NIM : 06.41010.0317

Program : S1 (Strata Satu)

Jurusan : Sistem Informasi

SEKOLAH TINGGI

MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA

2013

STIKOM

vi

ABSTRAK

Komputer Grafis 3D merupakan teknologi yang dipakai untuk pengembangan aplikasi berbasis 3D, yang mencakup bidang yang cukup luas. Permasalahan dalam mengembangkan aplikasi tersebut adalah pemrograman yang

kompleks menggunakan pipeline API grafis 3D, kurangnya dukungan perhitungan

matematika dan algoritma 3D untuk meningkatkan efisiensi dan efektifitas rendering, serta tidak adanya sistem manajemen untuk mengelola sumber daya 3D.

Berdasarkan permasalahan diatas, diusulkan perancangan framework

rendering engine untuk pengembangan aplikasi berbasis 3D dengan menyediakan modul-modul pengembangan untuk mengelola sistem rendering beserta manajemen verteks dan manajemen skinnya, modul-modul algoritma dan

matematika 3D seperti vektor, matriks, ray, plane, AABB, OBB, Octre dan BSP

Tree, dan juga menyediakan modul-modul lainnya seperti kamera, kontrol pergerakan dan informasi proses rendering grafis 3D.

Sebagai hasil implementasi dan uji coba sistem, framework rendering engine ini dapat menghasilkan sistem yang lebih efektif dan efisien pada beragam pengembangan aplikasi berbasis 3D. Dan dengan adanya sistem manajemen scene membantu meningkatan performa dari proses rendering, disertai dengan teknologi SIMD (Single Instruction Multiple Data) sehingga dapat meningkatkan nilai frame rate per second sebesar antara 24% sampai dengan 40%.

Kata Kunci: Framework, Rendering Engine, Tiga Dimensi

STIKOM

ix

DAFTAR ISI

Halaman

ABSTRAK ... vi

KATA PENGANTAR ... vii

DAFTAR ISI ... ix

DAFTAR TABEL ... xiv

DAFTAR GAMBAR ... xv

BAB I ... 1

1.1. Latar Belakang Masalah ... 1

1.2. Perumusan Masalah ... 3

1.3. Pembatasan Masalah ... 4

1.4. Tujuan ... 4

1.5. Sistematika Penulisan ... 5

BAB II ... 7

2.1. Software Framework... 7

2.2. Komputer Grafis 3D ... 9

2.3. Rendering Engine ... 9

2.4. Direct3D API ... 11

2.5. Teknologi SIMD ... 13

2.6. Matematika 3D ... 14

2.6.1. Vektor ... 14

2.6.2. Sistem Koordinat Kartesius ... 16

2.6.3. Matriks dan Transformasi ... 18

2.6.4. Orientasi Euler Angle dan Quaternion ... 19

STIKOM

x

2.6.5. Plane dan Ray ... 21

2.6.6. Bounding Volume ... 23

2.7. Octree ... 26

2.8. BSP Tree ... 27

2.9. Pemrograman C++ ... 29

2.10. UML... 30

2.11. Pengujian Perangkat Lunak ... 31

BAB III ... 33

3.1. Analisa Identifikasi Permasalahan ... 33

3.2. Algoritma Manajemen Scene... 36

3.2.1. Algoritma Octree ... 36

3.2.2. Algoritma BSP Tree ... 39

3.3. Perancangan Sistem ... 43

3.4. Class Diagram ... 45

3.4.1. Class TumozRenderer ... 48

3.4.2. Class TumozRenderDevice ... 49

3.4.3. Class TumozVertexCacheManager ... 50

3.4.4. Class TumozSkinManager ... 50

3.4.5. Class TumozD3D ... 51

3.4.6. Class TumozD3DSkinManager ... 53

3.4.7. Class TumozD3DVCManager ... 54

3.4.8. Class TumozD3DVCache ... 56

3.4.9. Class TumozVector ... 57

3.4.10. Class TumozMatrix... 57

STIKOM

xi

3.4.11. Class TumozQuat ... 58

3.4.12. Class TumozRay ... 59

3.4.13. Class TumozPlane... 60

3.4.14. Class TumozAabb ... 61

3.4.15. Class TumozObb... 62

3.4.16. Class TumozPolygon ... 63

3.4.17. Class TumozPolylist ... 64

3.4.18. Class TumozBSPTree ... 65

3.4.19. Class TumozOctree ... 66

3.4.20. Class TumozMovementController ... 67

3.4.21. Class TumozMCEgo ... 69

3.4.22. Class TumozMCFree ... 69

3.4.23. Class TumozTimer ... 70

3.5. Flowchart Diagram ... 71

3.5.1. Flowchart Operasi Create Device() ... 72

3.5.2. Flowchart Operasi Init() ... 73

3.5.3. Flowchart Operasi Go() ... 75

3.5.4. Flowchart Operasi OneTimeInit() ... 77

3.5.5. Flowchart Operasi UseWindow() ... 79

3.5.6. Flowchart Operasi InitStage() ... 80

3.5.7. Flowchart Operasi CreateVShader() ... 81

3.5.8. Flowchart Operasi AddSkin()... 83

3.5.9. Flowchart Operasi AddTexture() ... 85

3.5.10. Flowchart Operasi CreateStaticBuffer() ... 88

STIKOM

xii

3.5.11. Flowchart Operasi CreateFont() ... 90

3.5.12. Flowchart Operasi BeginRendering() ... 91

3.5.13. Flowchart Operasi EndRendering() ... 92

3.5.14. Flowchart Operasi UseShaders() ... 93

3.5.15. Flowchart Operasi DrawText() ... 94

3.5.16. Flowchart Operasi SetAmbientLight() ... 94

3.5.17. Flowchart Operasi SetWorldTransform() ... 95

3.5.18. Flowchart Operasi ActivateVShader()... 96

3.5.19. Flowchart Operasi Render()... 98

3.6. Component Diagram ... 101

3.6.1. Component Diagram TumozRenderer ... 103

3.6.2. Component Diagram TumozD3D ... 104

3.6.3. Component Diagram Tumoz3D ... 105

3.6.4. Component Diagram TumozGeneral ... 107

BAB IV ... 109

4.1. Kebutuhan Sistem ... 109

4.1.1. Kebutuhan Perangkat Keras ... 109

4.1.2. Kebutuhan Perangkat Lunak ... 109

4.2. Pembuatan Framework Rendering Engine ... 110

4.3. Implementasi Framework Rendering Engine ... 111

4.3.1. Instalasi Framework Rendering Engine ... 111

4.3.2. Pembuatan Referensi Framework Rendering Engine... 112

4.3.3. Insialisasi Framework Rendering Engine ... 114

4.3.4. Siklus Rendering ... 116

STIKOM

xiii

4.3.5. Rendering Obyek Tiga Dimensi ... 119

4.3.6. Transformasi dan Pencahayaan ... 121

4.3.7. Implementasi Shader ... 123

4.4. Pengujian Sistem Rendering ... 125

4.4.1. Pengujian Perbandingan Inisialisasi Sistem ... 126

4.4.2. Pengujian Perbandingan Pembuatan Obyek 3D ... 127

4.4.3. Pengujian Perbandingan Rendering Obyek 3D ... 131

4.5. Pengujian Implementasi Manajemen Scene ... 132

4.6. Evaluasi Sistem ... 136

4.6.1. Hasil Uji Coba Inisialisasi Framework Rendering Engine... 136

4.6.2. Hasil Uji Coba Pengaturan Scene... 137

4.6.3. Hasil Uji Coba Rendering Obyek Tiga Dimensi ... 137

4.6.4. Hasil Uji Coba Transformasi dan Pencahayaan ... 138

4.6.5. Hasil Uji Coba Implementasi Shader ... 139

BAB V ... 140

5.1. Kesimpulan ... 140

5.2. Saran ... 141

DAFTAR PUSTAKA ... 142

LAMPIRAN ... 144

STIKOM

1

BAB I PENDAHULUAN

1.1. Latar Belakang Masalah

Komputer Grafis 3D (tiga dimensi) merupakan teknologi yang dipakai untuk pengembangan aplikasi berbasis 3D yang meliputi bidang yang cukup luas mulai dari industri film, pengembangan game, berbagai simulasi pelatihan bahkan sampai penggunaan Computer-Aided Design (CAD) untuk konstruksi bangunan dan tata kota. Banyaknya developer yang berminat mengembangkan aplikasi perangkat lunak berbasis 3D tersebut maka dikembangkanlah dukungan perangkat lunak dalam bentuk API (Application Programming Interface) Grafis 3D seperti Direct3D dan OpenGL. Selain itu juga adanya dukungan pengembangan perangkat keras berupa kartu grafis yang ikut membantu dalam perkembangan teknologi tersebut.

Walaupun telah didukung oleh API Grafis 3D, pengembangan aplikasi berbasis 3D oleh pihak developer ternyata memiliki banyak permasalahan. API Grafis 3D sejak awal memang dikembangkan sebagai antarmuka yang mewakili semua fitur perangkat keras sehingga menjadi terlalu kompleks bagi pihak developer dalam menggunakannya terutama dalam pengembangan program aplikasi berskala kecil maupun juga yang besar. Permasalahan lain yang timbul adalah kurangnya dukungan algoritma-algoritma pendukung dalam pemrograman 3D dan fitur matematika 3D pada API sehingga pihak developer terpaksa harus mengembangkan sendiri fitur tersebut. Dan tidak adanya manajemen untuk mengelola sumber daya yang saling terintegrasi dalam API Grafis 3D.

STIKOM

Framework adalah kerangka kerja. Juga dapat diartikan sebagai

sekumpulan komponen pemrograman (terutama class dan function) yang siap

re-use yang membantu developer dalam menangani masalah-masalah pemrograman,

sehingga developer lebih fokus dan lebih cepat dalam membangun aplikasi.

Sedangkan Engine merupakan sistem yang didesain untuk membantu

pengembangan aplikasi dengan melakukan fungsionalitas tertentu, menjalankan fungsi-fungsi mulai dari tingkat rendah seperti komunikasi dengan antarmuka, dan mengelola sumber daya secara realtime.

Dengan adanya framework tersebut diharapkan memberikan kerangka kerja dalam pengembangan aplikasi berbasis 3D yaitu dalam bentuk komponen-komponen pemrograman untuk persiapan dan menjalankan proses rendering, modul untuk algoritma-algoritma yang dibutuhkan dalam pemrograman 3D, fungsi-fungsi matematika 3D, dan serta modul-modul lainnya yang membantu proses rendering grafis 3D. Berlaku juga untuk engine diharapkan untuk mengelola sumber daya secara efektif dan efisien mulai dari manajemen memori dan buffer, material, lighting, texturing, dan file-file yang dibutuhkan agar proses rendering berjalan dengan lancar.

Agar hal tersebut dapat terwujud, maka perlu dibuat suatu sistem aplikasi framewok rendering engine untuk pengembangan aplikasi berbasis 3D. Dengan adanya aplikasi tersebut pihak developer dapat menggunakan komponen-komponen yang tersedia yang memfokuskan pengembangan rendering grafis 3D pada aplikasinya sendiri dan bukan pada detil-detil yang ada di dalam antarmuka sistem rendering yang kompleks. Aplikasi framework rendering engine ini juga memberikan fitur-fitur algoritma dan matematika 3D yang kompatibel dan

STIKOM

terintegrasi sehingga pihak developer dengan leluasa menggunakan komponen tersebut agar aplikasinya menjadi semakin optimal. Dan aplikasi framework rendering engine juga menyediakan manajemen pengelolaan sumber daya sehingga pihak developer dapat dengan mudah mengatur sumber daya rendering tersebut secara realtime dan terintegrasi.

Aplikasi framework rendering engine ini memiliki kelebihan dengan adanya fasilitas fitur teknik operasi perhitungan matematika cepat yaitu SIMD (Single Instruction Multiple Data) sehingga dapat meningkatkan kinerja dari proses rendering engine. Kelebihan lainnya yaitu adanya algoritma seperti BSP tree, Octree, Quaternion, dan Euler Angle sehingga pengembangan rendering grafis 3D diharapkan bisa menjadi semaksimal mungkin dan mencakup area seluas mungkin.

1.2. Perumusan Masalah

Berdasarkan batasan masalah diatas dapat diambil kesimpulan bahwa permasalahan yang ada adalah:

1. Bagaimana merancang dan membangun sistem rendering grafis 3D yang

terpisah dari perhitungan matematika dan algoritma dalam membantu memudahkan pengembangan aplikasi bebasis 3D bagi developer, dengan fungsi-fungsi antara lain mengelola perangkat rendering (render device), manajemen verteks (vertex cache manager) dan serta manajemen skin (skin manager) secara efektif dan efisien?

2. Bagaimana merancang dan membangun sistem perhitungan matematika dan

algoritma-algoritma 3D yang terintregrasi dan kompatibel menggunakan

STIKOM

teknologi SIMD untuk membantu kelancaran proses rendering grafis 3D yang sesuai dengan harapan pihak developer?

3. Bagaimana merancang dan membangun sistem untuk manajemen scene,

kamera, kontrol pergerakan dan juga beserta informasi-informasi tentang proses rendering grafis 3D?

1.3. Pembatasan Masalah

Batasan masalah yang yang dilakukan adalah sebagai berikut:

1. Aplikasi yang dibuat meliputi pengembangan rendering grafis 3D yang

memakai API DirectX.

2. Aplikasi ini menggunakan algoritma dan perhitungan matematika 3D yaitu meliputi Vektor, Matriks, Ray, Plane, Polygon, Polylist, Euler Angle,

Quaternion, AABB, OBB, Octree dan BSP Tree.

3. Aplikasi ini terbatas hanya dapat digunakan untuk membantu pengembangan

aplikasi berbasis 3D dalam rendering grafis 3D.

1.4. Tujuan

Dengan batasan masalah diatas maka tujuan yang akan dicapai dalam penyusunan tugas akhir ini adalah:

1. Merancang dan membuat suatu aplikasi rendering grafis 3D untuk membantu

pengembangan aplikasi berbasis 3D, yang berfungsi mengelola perangkat rendering, manajemen verteks dan serta manajemen skin secara efektif dan efisien

STIKOM

2. Merancang dan membuat suatu aplikasi sistem perhitungan matematika dan algoritma 3D menggunakan teknologi SIMD yang terintegrasi dan kompatibel dengan sistem rendering grafis 3D.

3. Merancang dan membuat suatu aplikasi untuk manajemen scene, kamera,

kontrol pergerakan dan menampilkan informasi yang dibutuhkan dalam proses rendering grafis 3D.

1.5. Sistematika Penulisan

Laporan Tugas Akhir (TA) ini ditulis dengan sistematika penulisan sebagai berikut:

BAB I PENDAHULUAN

Pada bab pertama ini akan dijelaskan mengenai latar belakang masalah dan penjelasan masalah secara umum, perumusan masalah serta batasan masalah yang dibuat, tujuan dari pembuatan tugas akhir dan sistematika penulisan dari buku ini.

BAB II LANDASAN TEORI

Pada bab kedua ini berisi tentang pembahasan landasan teori yang berhubungan dan mendukung dalam pembuatan tugas akhir. Landasan teori yang digunakan antara lain: software framework, komputer grafis 3D, Direct3D API, matematika 3D, vektor, sistem koordinat kartesius, matriks dan transformasi, orientasi euler angle,

plane dan ray, dan bounding volume.

BAB III PERANCANGAN SISTEM

Bab ini berisi penjelasan mengenai analisa identifikasi

permasalahan, algoritma manajemen scene, perancangan sistem

STIKOM

class diagram, component diagram, dan flowchart fungsi rendering.

BAB IV IMPLEMENTASI DAN EVALUASI

Bab keempat ini berisi tentang implementasi dari framework rendering engine. Serta melakukan pengujian terhadap sistem rendering, pengujian implementasi manjemen scene, dan evaluasi sistem untuk mengetahui bahwa aplikasi tersebut telah dapat menyelesaikan permasalahan yang dihadapi sesuai dengan harapan.

BAB V PENUTUP

Bab ini berisi kesimpulan dan saran. Saran yang dimaksud adalah saran terhadap kekurangan dari aplikasi yang ada kepada pihak lain yang ingin meneruskan topik TA ini. Tujuannya adalah agar pihak lain tersebut dapat menyempurnakan aplikasi sehingga bisa menjadi lebih baik dan berguna.

STIKOM

7

BAB II LANDASAN TEORI

2.1. Software Framework

Menurut Johnson (1992) framework adalah desain reusable dari sebuah program atau bagian dari sebuah program yang diekspresikan sebagai sekumpulan kelas. Dengan demikian, maka software framework dapat diartikan sebagai

sekumpulan kode atau library yang menyediakan fungsionalitas umum yang

digunakan untuk menghasilkan aplikasi spesifik sesuai kebutuhan user. Biasanya

satu library normal akan menyediakan satu fungsi tertentu, tetapi berbeda dengan framework yang menawarkan jangkauan yang lebih luas yang seringkali digunakan untuk pengembangan salah satu jenis aplikasi. Daripada membuat

ulang logika yang sudah umum, programmer dapat memanfaatkan framework

dimana biasanya menyediakan fungsi-fungsi yang sering digunakan, mengurangi waktu yang dibutuhkan untuk membangun sebuah aplikasi dan serta mengurangi kemungkinan penambahan error atau bug baru.

Software framework dapat terdiri dari progam pendukung, kompiler, kode library, application programming interface (API), dan sekumpulan alat (tool) yang menggabungkan semua komponen yang berbeda untuk menjalankan pengembangan suatu proyek aplikasi. Sebagai contoh framework apilkasi web mungkin menyediakan manajemen user session, penyimpanan data, dan sistem

template. Sedangkan framework aplikasi dekstop mungkin menyediakan fungsi

user interface dan widget (elemen GUI umum). Hampir semua framework

mengontrol setidaknya beberapa aspek dari alur eksekusi aplikasi.

STIKOM

Framework memiliki fitur kunci pembeda yang memisahkan mereka dari library normal yaitu:

1. Inversi dari kontrol: Tidak seperti library atau aplikasi user yang biasanya, alur kontrol dari program secara keseluruhan tidak diatur oleh pemanggil (caller), melainkan oleh framework (Riehle 2000).

2. Default behavior: Framework memiliki default behavior yaitu suatu perilaku atau aturan operasi yang selalu sama dalam setiap penggunaannya sehingga akan memudahkan user dalam mengembangkan aplikasi. Default behavior harus merupakan suatu operasi yang bermanfaat bukan serangkaian operasi yang tidak melakukan apa-apa.

3. Ekstensibilitas: Framework dapat diperluas oleh user biasanya dengan cara

melakukan overriding secara selektif atau spesialisasi kode user yang menghasilkan fungsionalitas spesifik.

4. Kode framework Non-Modifiable: Secara umum kode framework tidak

diijinkan untuk dimodifikasi. User dapat menambah framework tetapi bukan memodifikasi kodenya.

Ada berbagai jenis dari framework bahkan di dalam satu klasifikasi dari aplikasi. Beberapa menawarkan sedikit lebih banyak dari fungsi utilitas dasar dari suatu aplikasi. Dan yang lainnya menawarkan hampir menjadi sebuah aplikasi lengkap dan memerlukan organisasi kode yang baku dan beberapa aturan-aturan lainnya. Memilih framework yang terbaik untuk suatu proyek seringkali membutuhkan programmer untuk menyeimbangkan seberapa banyak fungsi-fungsi yang mereka dapatkan dari framework terhadap fleksibilitas yang mereka harapkan.

STIKOM

2.2. Komputer Grafis 3D

Menurut Santosa (1994:2), “Grafika komputer (komputer grafis) pada dasarnya adalah suatu bidang ilmu komputer yang mempelajari tentang cara-cara untuk meningkatkan dan memudahkan komunikasi antara manusia dengan mesin (komputer) dengan jalan membangkitkan, menyimpan dan memanipulasi gambar

model suatu obyek menggunakan komputer”. Berdasarkan penjelasan diatas

aplikasi yang berbasis komputer grafis 3D menggunakan representasi tiga dimensi dari data geometris (biasanya menggunakan sistem koordinat Kartesius) yang tersimpan pada komputer yang ditujukan untuk melakukan kalkulasi dan rendering gambar 2D.

Dalam pembuatan komputer grafis 3D dibagi menjadi 3 tahapan yaitu sebagai berikut:

1. Pemodelan 3D: Proses pembentukan model komputer dari bentuk obyek.

2. Layout dan animasi: Pergerakan dan penempatan dari obyek dalam scene.

3. Rendering 3D: Perhitungan komputer yang berdasarkan pada penempatan

cahaya, jenis permukaan, dan kualitas lainnya dalam pembuatan gambar.

2.3. Rendering Engine

Dalam pemrograman komputer grafis, proses rendering engine hampir sama dengan cara kerja mesin pada umumnya yaitu merupakan bagian dari proyek dimana menjalankan fungsionalitas tertentu dari program. Dimulai dari memanggil fungsi menyalakan engine untuk melakukan persiapan. Kemudian engine akan mencari adapter grafis yang siap dijalankan. Ketika engine dikendalikan seperti memasukkan model 3D kedalam adapter grafis, maka rendering engine dengan segera menampilkannya kedalam layar. Rendering

STIKOM

engine melakukan semua pekerjaaan tingkat rendah seperti melakukan komunikasi dengan adapter grafis, mengatur render states, transformasi model, dan berurusan dengan matematika yang rumit seperti matriks rotasi. Pekerjaan-pekerjaan kotor ini sangat diperlukan akan tetapi seperti pengemudi kendaraan dalam hal ini sebagai developer tidak perlu harus memahami cara kerja mesin didalamnya dan yang terpenting adalah agar dapat digunakan untuk mencapai tujuannya.

Kebanyakan rendering engine dibangun dari application programming interface (API) grafis seperti Direct3D, Java3D atau OpenGL dimana menyediakan abstraksi software dari graphics processing unit (GPU). Menurut Bao dan Hua (2011), Seringkali rendering engine menyediakan setidaknya satu

modul yaitu scene graph manager (rendering engine yang lain mungkin memiliki

nama yang berbeda) untuk membantu memanipulasi grafis di dalam scene seperti membuat, memodifikasi, mereferensi, menduplikasi, mencari, menghapus node dari scene graph.

Gambar 2.1. Contoh struktur dari Rendering Engine [Sumber: Bao dan Hua, 2011]

STIKOM

Zerbst dan Dü_{val (2004) menyimpulkan bahwa rendering engine harus}

melakukan kegiatan-kegiatan sebagai berikut:

1. Memanajemen semua data dan wilayah tanggung jawabnya.

2. Melakukan komputasi semua data berdasarkan tugas wilayahnya.

3. Menyampaikan semua data menuju instansi berikutnya, jika diperlukan.

4. Menerima semua data untuk dikelola dan untuk dikomputasi dari instansi

sebelumnya.

2.4. Direct3D API

Direct3D merupakan subset atau bagian dari Microsoft DirectX

application programming interface (API). Menurut Luna (2003) Direct3D adalah API grafis tingkat rendah yang memungkinkan kita untuk merender dunia 3D menggunakan akselerasi hardware. Direct3D dapat digambarkan sebagai mediator antara aplikasi dan graphics device (hardware 3D). Sebagai contoh, untuk menginstruksikan graphics device untuk membersihkan layar, aplikasi akan memanggil fungsi Direct3D IDirect3DDevice9::Clear. Gambar dibawah ini menunjukkan hubungan antara aplikasi, Direct3D, dan hardware grafis.

Gambar 2.2. Hubungan antara Aplikasi, Direct3D dan Hardware [Sumber: http://www.codeproject.com/KB/graphics/DirectX_Lessons_2_

/device.jpg Time Download: 31/07/2013 11:38:34]

STIKOM

Bagian Direct3D pada gambar diatas mendefinisikan sekumpulan interface dan fungsi yang dipaparkan ke aplikasi atau programmer. Interface dan fungsi tersebut mewakili seluruh fitur dimana mendukung versi Direct3D saat ini. Seperti yang ditunjukkan gambar tersebut, disana juga ada langkah penengah antara Direct3D dan graphics device yaitu HAL (Hardware Abstraction Layer). Direct3D tidak dapat berinteraksi secara langsung dengan graphics device karena karena terdapat bergam kartu grafis yang beredar di pasaran, dan masing-masing kartu tersebut memiliki beragam kemampuan dan cara dalam implementasinya. Sebagai contoh, dua kartu grafis yang berbeda mungkin mengimplementasikan operasi membersihkan layar secara berbeda. Dengan demikian Direct3D membutuhkan manufaktur device untuk mengimplementasikan HAL. HAL adalah sekumpulan kode spesifik device yang menginstruksikan device untuk melakukan operasi. Dengan cara ini Direct3D dapat menghindari untuk mengetahui secara detil spesifik dari device, dan spesifikasinya dapat dibuat secara independen dari hardware device.

Manufaktur device mengimplementasikan semua fitur yang mereka dukung kedalam HAL. Fitur yang dipaparkan oleh Direct3D tetapi tidak didukung oleh device tidak akan diimplementasikan kedalam HAL. Pemanggilan fungsi Direct3D yang tidak diimplementasikan oleh HAL akan menghasilkan kegagalan (failure), kecuali operasi pemrosesan verteks, dimana fungsionalitas yang

diharapkan dapat diemulasi di dalam software, jika menggunakan software vertex

processing oleh Direct3D runtime.

Dengan dukungan dari kartu grafis yang mengimplementasikan HAL

tersebut Direct3D dapat memaparkan kemampuan grafis tingkat lanjut (advanced)

STIKOM

dari hardware grafis 3D, antara lain z-buffering, anti-aliasing, alpha blending,

mipmapping, atmospheric effect, dan perspective-correct texture mapping.

2.5. Teknologi SIMD

SIMD merupakan singkatan dari Single Instruction Multiple Data. Umumnya unit prosesing (CPU) mengolah data dan melakukan instruksi pada data tersebut dalam sekuensial linear yang disebut sebagai operasi skalar, akan tetapi dengan menggunakan SIMD dapat melakukan sebuah instruksi pada beberapa data sekaligus secara paralel (Cockshott dan Renfrew 2004). Seperti gambar dibawah ini:

Gambar 2.3 Perbedaan (a) operasi skalar, dan (b) operasi SIMD [Sumber:

https://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/CellProgrammingTutorial/CellProgrammingTutorial.files/image008.jpg Time Download: 19/07/2013 10:02:34]

Seandainya ada sebuah vektor yang memiliki tiga buah data floating

point masing-masing sebesar 32 bit dengan total 96 bit. Jika menggunakan teknologi SIMD seperti SSE dengan register 128-bit, maka vektor tersebut dapat melakukan instruksi misalnya penambahan hanya sekali saja. Sedangkan menggunakan register normal seperti 64-bit atau 32-bit membutuhkan instruksi

STIKOM

sebanyak 2 atau 3 kali. Dengan demikian SIMD mampu meningkatkan performa dari operasi terhadap vektor tersebut secara signifikan.

2.6. Matematika 3D

Matematika 3D biasanya berhubungan dengan komputasi geometri, dimana berurusan dengan pemecahan permasalahan geometri secara algoritma (Dunn dan Parberry 2002). Matematika 3D dan komputasi geometri memiliki aplikasi dalam bidang yang sangat beragam yang menggunakan komputer untuk memodelkan atau hal-hal yang mendasari dunia dalam 3D, seperti grafis, game, simulasi, robotik, virtual reality, dan sinematografi.

2.6.1. Vektor

Vektor merupakan entitas matematika formal yang biasanya digunakan untuk melakukan perhitungan matematika 2D dan 3D. Kata vektor memiliki arti yang berbeda tapi saling berhubungan. Definisi secara matematika vektor adalah daftar bilangan (kumpulan bilangan) atau dalam komputer sebagai array dari bilangan. Vektor memiliki dimensi mulai 1D (atau disebut skalar), 2D, 3D dan seterusnya contoh penulisan vektor: [1, 2, 3]. Sedangkan secara geometri vektor adalah segmen garis berarah yang memiliki besaran (magnitude) dan arah (Gambar 2.4.), akan tetapi vektor juga dapat mewakili suatu titik (point) di dalam ruang koordinat walaupun secara konseptual memiliki arti yang berbeda.

Gambar 2.4. Vektor 2D memiliki magnitude dan arah

STIKOM

Vektor memiliki beragam operasi-operasi yang sangat bermanfaat untuk matematika tiga dimensi. Secara geometri operasi negasi pada vektor akan menghasilkan magnitude yang sama tetapi memiliki arah yang berlawanan, contoh penulisan: - [3, 5, -4] = [-3, -5, 4]. Vektor memiliki magnitude (besaran) atau juga disebut panjang vektor (norm), dan persamaan yang digunakan untuk mencari magnitude tersebut adalah sebagai berikut (Lengyel 2004):

√∑

Untuk mempermudah perhitungan matematika 3 dimensi terkadang kuantitas vektor berkosentrasi pada arahnya bukan magnitude, dengan demikian vektor tersebut dijadikan vektor unit. Vektor unit adalah vektor yang memiliki nilai magnitude 1, yang juga dikenal sebagai normalisasi vektor (normal). Untuk membuat normalisasi vektor persamaannya adalah sebagai berikut:

Operasi produk (perkalian) pada 2 vektor bersamaan ada dua jenis yaitu

dot product dan cross product. Dot product diambil dari simbol titik pada notasinya: a . b yang menghasilkan nilai skalar. Persamaannya adalah sebagai berikut:

∑

STIKOM

Sedangkan cross product hanya dapat digunakan pada vektor 3 dimensi.

Hasil produknya akan menghasilkan vektor 3 dimensi juga, dengan notasi: a × b

persamaannya adalah sebagai berikut:

2.6.2. Sistem Koordinat Kartesius

Menurut Dunn dan Parberry (2002), Matematika Kartesian ditemukan oleh dan diberi nama sesuai dengan matematikawan dan filsuf terkenal Perancis

yang bernama RenéDescartes yang hidup antara tahun 1596 sampai dengan tahun

1650. Dia juga terkenal dengan merevolusi matematika yang menyediakan hubungan secara sistematik pertama kali antara geometri dan aljabar.

Sistem koordinat Kartesius digunakan untuk menentukan tiap titik dalam bidang dengan menggunakan dua bilangan yang biasa disebut koordinat x dan koordinat y dari titik tersebut. Sistem koordinat Kartesius dapat pula digunakan pada dimensi-dimensi yang lebih tinggi, seperti 3 dimensi, dengan menggunakan tiga sumbu (sumbu x, y, dan z).

Gambar 2.5. Menentukan lokasi pada 3D [Sumber: Dunn dan Parberry, 2002]

STIKOM

Dalam menentukan lokasi suatu titik dalam ruang tiga dimensi ditentukan dengan tiga angka x, y, dan z yang masing-masing memiliki jarak terhadap bidang yz, xz, dan xy (Gambar 2.5.). Akan tetapi tidak seperti pada ruang 2 dimensi yang memiliki hasil setara bila dibalik, sedangkan pada ruang tiga dimensi ada permasalahan dalam menentukan suatu posisi, jika kordinat z ditentukan maka ada dua kemungkinan yang terjadi dan mengarah kearah yang berbeda. Ini menyimpulkan bahwa semua ruang koordinat tidak setara, dan ada dua tipe berbeda dari koordinat ruang tiga dimensi yaitu ruang koordinat tangan kiri ( left-handed) dan ruang koordinat tangan kanan (right-handed). Direct3D menggunakan sistem ruang koordinat tangan kiri sebagai acuan dalam penggunaan dan penentuan lokasi dalam ruang tiga dimensinya.

Masing-masing obyek dalam dunia virtual 3D memiliki ruang koordinat beserta titik asal dan dan sumbunya masing-masing yang disebut dengan ruang obyek (object space). Dengan koordinat ruang obyek yang independen maka dapat mudah melakukan perubahan pada obyek tersebut seperti memperbesar atau memperkecil obyek. Jika semua obyek sudah siap selanjutnya obyek itu akan

digabung kedalam satu ruang koordinat yaitu world space. Di dalam world space

masing-masing ruang koordinat obyek tersebut akan ditransformasikan terhadap koordinat obyek lain seperti ukuran, orientasi, bahkan jarak antar masing-masing obyek. Dan terakhir world space akan ditransformasikan lagi ke ruang koordinat kamera (camera space). Pada tahapan ini akan menentukan obyek-obyek mana yang masuk kedalam luang lingkup yang terlihat oleh kamera. Dalam ruang kamera sumbu positif x akan mengarah kekanan, sumbu positif y keatas dan

STIKOM

sumbu positif z mengarah kedalam untuk sistem koordinat tangan kiri (atau sistem koordinat tangan kanan sumbu negatif z mengarah kedalam).

2.6.3. Matriks dan Transformasi

Transformasi adalah sebuah operasi yang membutuhkan entitas seperti titik, vektor, atau warna dan mengkonversi mereka dalam beberapa cara (Möller, Haines dan Hoffman 2008). Dengan tranformasi dapat memposisikan, mengubah

bentuk, dan melakukan animasi pada obyek, cahaya (light), dan kamera. Dan juga

dapat memastikan bahwa semua perhitungan dilakukan dalam sistem koordinat yang sama, dan melakukan proyeksi pada objek kedalam suatu bidang dengan cara yang berbeda.

Secara umum matriks bujur sangkar (square matrix) dapat

mendefinisikan setiap transformasi linear. Secara geometri dapat dikatakan bahwa transformasi linear mempertahankan garis lurus dan paralelnya, dan tidak melakukan translasi, yang berarti bahwa titik asal tidak berubah. Ketika tansformasi linear mempertahankan garis lurusnya, sifat-sifat yang lain dari geometri seperti panjang, sudut, luas, dan volumenya kemungkinan dapat berubah oleh transformasi, contohnya antara lain seperti rotasi, scaling, refleksi, proyeksi

orthogonal, dan shearing.

Transformasi rotasi adalah tranformasi yang memutar vektor (baik posisi atau arah) berdasarkan sudut yang diberikan disekitar sumbu melalui titik asal. Persamaan dari transformasi rotasi bedasarkan sudut θ untuk masing-masing sumbu x, y dan z adalah sebagai berikut:

STIKOM

)

)

)

Selain transformasi linear juga ada bermacam-macam transformasi lainnya seperti transformasi affine untuk melakukan translasi (memindahkan posisi obyek dari titik asal) dengan menggunakan matriks homogen 4x4. Dengan memakai matriks homogen 4x4, translasi dapat dikombinasikan dengan transformasi linear lainnya. Persamaan dari matriks homogen 4x4 untuk melakukan translasi dalam tiga dimensi berdasarkan vektor t = (tx, ty, tz) adalah

sebagai berikut:

)

2.6.4. Orientasi Euler Angle dan Quaternion

Seperti yang dibahas sebelumnya transformasi rotasi menggunakan matriks dapat mewakili orientasi dari obyek, akan tetapi ketika melakukan rotasi menggunakan matriks ada beberapa kelemahan yaitu membutuhkan lebih banyak memori, sangat sulit untuk digunakan secara intuitif, dan nilainya bisa cacat (akibat gabungan antar transformasi dan data eksternal). Maka ada teknik lain

STIKOM

selain matriks dalam mewakili orientasi yaitu menggunakan sudut Euler (Euler angle), dan Quaternion.

Sudut Euler merupakan teknik yang ditemukan oleh matematikawan terkenal yang bernama Leonhard Euler (1707-1783) yang membuktikan bahwa perpindahan sudut berurutan setara dengan perpindahan sudut tunggal. Ide dasarnya adalah untuk mendefinisikan perpindahan sudut berurutan dari tiga rotasi terhadap tiga sumbu yang saling tegak lurus. Tiga rotasi itu disebut heading,

pitch, bank masing-masing terhadap sumbu positif x kekanan, positif y keatas, dan positif z kedepan (menggunakan sistem koordinat tangan kiri). Dengan cara tersebut akan lebih intuitif bagi manusia dalam melakukan rotasi terhadap suatu obyek, contohnya untuk mengukur rotasi navigasi pesawat terbang. Tapi teknik ini juga memiliki kelemahan yaitu terjadinya Gimbal Lock. Gimbal lock adalah hilangnya satu derajat kebebasan dalam ruang tiga dimensi yang terjadi ketika dua sumbu didorong kedalam konfigurasi paralel, sehingga sistem akan terkunci kedalam rotasi yang menurun ke dua dimesi.

Möller, Haines dan Hoffman (2008) menjelaskan bahwa quaternion

adalah alat yang sangat ampuh untuk membangun transformasi dengan fitur yang menarik, dan dalam beberapa hal lebih unggul dari sudut Euler dan matriks, terutama mengenai rotasi dan orientasi (termasuk mengatasi gimbal lock). Pertama kali ditemukan oleh Sir William Hamilton pada tahun 1843 sebagai perluasan dari bilangan kompleks, dengan persamaan matematika sebagai berikut:

̂

STIKOM

Variabel qw merupakan bagian real dari quaternion ̂. Sedangkan bagian

imajiner adalah qv, dan i, j, dan k dinamakan unit imajiner.

Dengan persamaan diatas maka proses perhitungan matematika menjadi lebih luas sehingga terbuka untuk terbentuknya rumus-rumus perhitungan matematika yang baru, tidak terkecuali pada perhitungan ruang tiga dimensi. Quaternion memiliki mempunyai beragam operasi antara lain seperti mencari negasi, magnitude, identitas, perkalian, konjugasi, invers dan sebagainya. Untuk

menentukan rotasi vektor terhadap sumbu vektor uq

berdasarkan sudut θ, dan diasumsikan bahwa unit quaternion ̂ , maka persamaannya sebagai berikut:

̂ ̂

Rotasi dengan menggunakan matriks, sudut Euler dan quaternion masing-masing memiliki kelebihan dan kelemahan tersendiri. Akan tetapi teknik-teknik tersebut dapat dikonversikan antara satu dengan yang lain sehingga dapat digunakan secara optimal sesuai kondisi dan kebutuhan.

2.6.5. Plane dan Ray

Plane (bidang) dalam 3D adalah sekumpulan dari titik-titik yang berjarak sama (equidistant) dari dua titik (Dunn dan Parberry 2002). Secara geometri plane adalah permukaan 2 dimensi yang datar, tidak memiliki ketebalan, dan melebar tak terbatas. Persamaan dari plane umumnya ditulis sebagai berikut:

dimana komponen x, y, z merupakan bagian dari titik p = (x, y, z), yang berada di dalam plane, serta komponen vektor normal n = [A, B, C] yang tegak lurus

STIKOM

dengan plane. Berdasarkan persamaan tersebut maka untuk menentukan jarak ke titik asal D, adalah dengan persamaan di bawah ini:

Cara lain untuk mendefinisikan plane adalah dengan memberikan 3 titik

noncollinear yang tidak pada garis lurus yang sama. Untuk mencari vektor normal

n dari ketiga titik noncollinear p1, p2, dan p3 adalah dengan persamaan sebagai berikut:

Sedangkan untuk mencari jarak ke titik asal D yaitu menggunakan rumus yang

sama seperti sebelumnya akan tetapi titik p digantikan oleh titik p1.

Gambar 2.6. Plane berdasarkan titik dan vektor normal

[Sumber: http://mathworld.wolfram.com/images/eps-gif/Plane_1001.gif Time Download: 19/07/2013 15:54:12]

STIKOM

Jika ingin menghitung jarak a antara suatu titik q yang tidak berada di dalam plane dengan plane, berdasarkan titik p yang saling tegak lurus dengan titik

q, dan vektor normal n adalah dengan rumus sebagai berikut:

apabila a hasil perhitungan rumus diatas adalah positif maka titik q berada di depan plane (front face), dan sebaliknya bila negatif maka berada di belakang plane (back face).

Ray adalah garis yang memiliki titik asal (origin) dan memanjang tak terbatas dalam satu arah (Dunn dan Parberry 2002). Ray didefinisikan secara matematika dengan persamaan sebagai berikut:

dimana S mewakili posisi awal dari ray dan V mewakili arah dimana ray menuju. Sedangkan parameter t pada kasus tertentu memiliki nilai dari 0..l, dan l sebagai panjang dari ray.

2.6.6. Bounding Volume

Bounding volume dibangun agar dapat menutupi semua verteks milik dari

sebuah triangle mesh (sekumpulan segitiga yang membentuk obyek tiga dimensi),

maka dengan demikian dapat memastikan bahwa setiap segitiga di dalam mesh tersebut masuk ke dalam bounding volume (Lengyel 2004). Bounding volume digunakan untuk meningkatkan efisiensi dari operasi geometri dengan menggunakan volume yang sangat sederhana untuk melingkupi obyek tiga dimensi yang lebih kompleks. Biasanya, volume yang lebih sederhana memiliki

STIKOM

cara yang juga lebih sederhana untuk menguji obyek yang saling tumpang tindih (overlap).

Salah satu bounding volume yang paling umum digunakan adalah Axially

Aligned Bounding Box (AABB). Dalam 3D AABB adalah kotak bersegi enam sederhana, dimana masing-masing sisinya paralel ke salah satu cardinal plane yaitu suatu plane (bidang) dimana titik pusatnya melewati seperti ketika individu berdiri di posisi anatomis. Gambar di bawah ini menunjukkan gambar obyek 3D sederhana berserta dengan AABBnya.

Gambar 2.7. Obyek 3D dan AABBnya. [Sumber: Dunn dan Parberry, 2002]

Apabila suatu titik berada di dalam AABB, maka koordinatnya berada di dalam persamaan di bawah ini:

STIKOM

Berdasarkan dari persamaan diatas maka dapat menentukan 2 titik ekstrim yang menandakan batas dari AABB dengan persamaan sebagai berikut:

[ ] [ ]

Dengan demikian titik pusat c dari AABB tersebut dapat dihitung dengan persamaan di bawah ini:

(

Berbeda dengan teknik OBB (Oriented Bounding Box), bahwa OBB

harus menyimpan vektor lokalnya (sebagai sumbu) agar dapat mengetahui orientasinya (Zerbst dan Dü_{val 2004). Vektor tersebut harus menjadi vektor arah}

yang dinormalisasi. Kemudian menyimpan separuh dari perpanjangan bounding box pada masing-masing sumbunya. Dan informasi terakhir yang dibutuhkan dari OBB adalah titik pusatnya.

Apabila sebuah OBB didefinisikan berdasarkan titik pusat c, dengan sumbu right-handedorthonomalA0, A1, A2, dan perpanjangan a0 > 0, a1 > 0, a2 >

0, maka dapat digambarkan ke delapan verteks dari OBB tersebut dengan persamaan di bawah ini:

∑

diimana | | untuk semua i

Walaupun AABB sangat mudah untuk dibuat dan mampu meningkatkan kemampuan untuk menguji obyek yang saling tumpang tindih, akan tetapi AABB

STIKOM

bukan merupakan solusi bounding volume yang optimal. Hal ini dibuktikan oleh OBB, walaupun memerlukan perhitungan yang lebih banyak sehingga dapat mempengaruhi performanya, akan tetapi OBB menghasilkan bounding volume yang lebih erat dengan obyek 3D yang dilingkupinya sehingga meminimalisir tingkat kesalahannya. Contoh perbedaan AABB dan OBB dapat dilihat pada gambar dibawah ini:

Gambar 2.8. Perbedaan bounding volume (a) AABB, dan (b) OBB [Sumber: http://portal.ku.edu.tr/~cbasdogan/Tutorials/imageU21.JPG

Time Download: 19/07/2013 15:20:09]

2.7. Octree

Foley, van Dam, Feiner, dan Hughes (1996), menyimpulkan bahwa octree merupakan varian secara hirarki dari enumerasi penempatan spasial, pendekatan tersebut dirancang untuk ditujukan mengatasi kebutuhan persyaratan

penyimpanan. Octree merupakan turunan dari konsep quadtree, yang merupakan

representasi dua dimensi dari format yang digunakan untuk encoding gambar. Sebuah kotak akan dibagi secara simultan disepanjang semua ketiga sumbunya, dan titik pemotongan harus berada pusat dari kotak. Ini akan membuat delapan kotak baru, sehingga dinamakan octree (diagram pohon dengan delapan simpul anak).

STIKOM

Ketika membagi kotak (dalam hal ini adalah ruang tiga dimensi),

obyek-obyek berdasarkan kotak tersebut dimasukkan kedalam simpul (node) pada

diagram pohon (tree). Untuk menempatkan obyek kedalam octree, dimulai dari simpul akar (root). Jika obyek sepenuhnya di dalam satu simpul anak (child), maka turunkan kedalam simpul anak tersebut. Lanjutkan penelusuran kebawah dari diagram pohon selama obyek sepenuhnya berada di dalam simpul anak atau sudah mencapai simpul daun (leaf). Jika sebuah obyek tercakup diantara dua bidang yang terpisah, maka penurunan kebawah dihentikan dan mendaftarkan obyek tersebut kedalam simpul berdasarkan pada tingkatannya (level).

Gambar 2.9. Mengelompokkan Obyek dengan Octree

Ketika obyek dimasukkan atau didaftarkan kedalam simpul, maka octree menjadi alat yang sangat ampuh dalam mencari lokasi obyek dalam radius tertentu dari titik yang tentukan, atau untuk melakukan culling (penyisihan) pada obyek untuk rendering dan collision detection (deteksi benturan).

2.8. BSP Tree

BSP merupakan kependekan dari binary space partitioning. Seperti yang

dapat dibayangkan berdasarkan namanya, BSP adalah struktur diagram pohon

STIKOM

dimana setiap simpulnya memiliki dua anak. BSP tree secara rekursif membagi ruang kedalam sepasang sub-ruang, dan masing-masing dipisahkan oleh bidang (plane) dengan orientasi dan posisi yang sewenang-wenang (arbitrary) (Foley, van Dam, Feiner, dan Hughes 1996). Tidak seperti octree bidang pemisah BSP tree tidak harus sejajar sumbu (axially aligned).

Sebagai contoh dari BSP tree yang ditunjukkan pada gambar 2.10, ketebalan pada garis mewakili bidang pemisah dengan tingkatan yang lebih lebih tinggi dalam diagram pohon.

Gambar 2.10. Hirarki dari BSP Tree [Sumber: Dunn dan Parberry, 2002]

Dalam gambar tersebut simpul diberi label beserta struktur diagram pohon yang sebenarnya. Simpul interior memakai angka dan simpul daun memakai huruf, akan tetapi sangat penting untuk dipahami bahwa masing-masing simpul mewakili sebuah area dari ruang, bahkan termasuk simpul interior. Dalam praktek untuk melacak simpul anak depan dan belakang dari bidang pemisah,

ditentukan dengan menggunakan normal dari bidang.

STIKOM

Seperti octree obyek disimpan kedalam simpul-simpul BSP tree yang menurun sejauh mungkin. Untuk memproses obyek dalam diagram pohon, dimulai dari simpul akar dan memproses semua obyek di dalam simpul tersebut. Kemudian menentukan apakah area yang diinginkan (untuk rendering, collision detection dll) berada sepenuhnya pada satu sisi dari bidang pemisah atau pada sisi yang lainnya. Jika hanya menginginkan isi volume dari ruang pada satu sisi bidang pemisah, maka isi seluruh cabang pada sisi lainnya dapat dihiraukan. Dan jika area yang diinginkan terbentang diantara bidang pemisah, maka kedua simpul anak tersebut harus diproses.

Menggunakan BSP tree ketika telah dibangun sangatlah mudah. Kuncinya adalah menentukan penempatan bidang pemisah. Dan dalam menentukan bidang pemisah tersebut jauh lebih fleksibel daripada menggunakan octree.

2.9. Pemrograman C++

C++ dimulai sebagai versi perluasan dari bahasa C. C++ pertama kali ditemukan oleh Bjarne Stroustrup pada tahun 1979 di Laboratorium Bell Murray Hill, New Jersey (Schildt 2003). C++ seringkali dinamakan sebagai bahasa komputer tingkat menengah, karena mengkombinasikan elemen-elemen terbaik dari bahasa tingkat tinggi dengan kontrol dan fleksibilitas dari bahasa assembly. C++ mampu melakukan manipulasi secara langsung dari bit, byte dan alamat memori (pointer) dari elemen dasar beserta fungsi komputer, sehingga sangat cocok untuk pemrograman level sistem.

Pemrograman C++ juga merupakan bahasa pemrograman yang memiliki sifat pemrograman yang berorientasi obyek. Untuk menyelesaikan masalah, C++

STIKOM

melakukan langkah pertama dengan menjelaskan class-class yang merupakan anak class yang dibuat sebelumnya sebagai abstraksi obyek-obyek fisik. Class tersebut berisi keadaan obyek, anggota-anggotanya dan kemampuan dari obyeknya. Setelah beberapa class dibuat kemudian masalah akan dipecahkan dengan class. Gambar dibawah ini merupakan contoh sintaks program yang menggunakan bahasa C++.

Gambar 2.11. Contoh sintaks bahasa C++

2.10. UML

“Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan

pemrograman berorientasi obyek (OO).” (Fowler 2005:1). UML mulai

diperkenalkan Object Management Group, sebuah organisasi yang telah

mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP.

UML terdiri dari sejumlah elemen grafis yang dikombinasikan untuk membentuk diagram. Karena merupakan bahasa, UML memiliki aturan untuk mengkombinasikan elemen tersebut. Macam-macam dari diagram UML tersebut antara lain:

STIKOM

1. Class Diagram

Class diagram mendeskripsikan jenis-jenis obyek dalam sistem dan berbagai macam hubungan statis yang terdapat diantara mereka. Class diagram juga menunjukkan properti dan operasi sebuah class dan batasan-batasan yang terdapat dalam hubungan-hubungan obyek tersebut.

2. Component Diagram

Component diagram mendeskripsikan bagaimana sebuah sistem perangkat lunak dibagi menjadi komponen-komponen dan menjelaskan hubungan antar komponen tersebut.

2.11. Pengujian Perangkat Lunak

Pengujian perangkat lunak merupakan suatu investigasi yang dilakukan untuk mendapatkan informasi mengenai kualitas dari produk atau layanan yang sedang diuji. Pengujian perangkat lunak juga memberikan pandangan mengenai perangkat lunak secara obyektif dan independen, yang bermanfaat dalam operasional bisnis untuk memahami tingkat resiko pada implementasinya.

Teknik-teknik pengujian mencakup, namun tidak terbatas pada, proses mengeksekusi suatu bagian program atau keseluruhan aplikasi dengan tujuan

untuk menemukan bug perangkat lunak. Teknik-teknik pengujian perangkat lunak

yang paling sering dipakai yaitu: 1. White-box Testing

White-box testing merupakan metode pengujian perangkat lunak yang

menguji struktur internal dari sebuah aplikasi, bukan pada

fungsionalitasnya. White-box testing meramalkan cara kerja perangkat lunak secara rinci, karenanya jalur logika perangkat lunak akan diuji

STIKOM

dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik.

2. Black-box Testing

Black-box testing adalah metode pengujian perangkat lunak yang menguji fungsionalitas dari sebuah aplikasi. Pengujian ini bertujuan untuk menguji fungsionalitas dari operasi dari sebuah sistem, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.

STIKOM

33

BAB III

PERANCANGAN SISTEM

3.1. Analisa Identifikasi Permasalahan

Dalam mengembangkan aplikasi berbasis tiga dimensi pihak pengembang biasanya memerlukan suatu alat (tool) yang dapat berupa API yang berfungsi untuk menghubungkan antara perangkat lunak yang dikembangkan dengan perangkat keras untuk mengolah data tiga dimensi yang diinginkan. API tersebut merupakan kumpulan interface atau perintah untuk menjalankan hal-hal yang dibutuhkan dalam melakukan pengolahan data tiga dimensi yaitu antara lain: enumerasi device rendering, pengaturan tampilan, mengolah data primitif tiga dimensi, menghitung posisi model, menampilkan gambar ke layar, memproses file tekstur, dan sebagainya.

API tersebut dari awal ditujukan sebagai antarmuka (interface) untuk perangkat grafis tiga dimensi. Dengan demikian tahapan-tahapan dalam pengolahannya menyesuaikan urutan proses yang panjang dalam hardware grafis tiga dimensi tersebut. Contohnya pada gambar tahapan proses pada API Direct3D (Direct3D Graphics Pipeline) dibawah ini:

Gambar 3.1. Direct3D Graphics Rendering Pipeline [Sumber: http://www.viznet.ac.uk/files/d39pipeline.gif

Time Download: 15/01/2013 14:38:10]

STIKOM

Berdasarkan gambar diatas prosedur pipeline dimulai dari membuat data primitif (primitive data) berupa titik, garis, segitiga dan poligon serta mendefinisikan data verteks (vertex data) beserta parameternya sesuai kebutuhan. Setelah itu tesselator unit akan mengkonversi urutan dari atas ke bawah data primitif, displacement maps, dan mesh patches ke lokasi verteks lalu menyimpan lokasi tersebut ke dalam verteks buffer dan proses ini dinamakan Tesselation. Kemudian pada tahapan Vertex Processing transformasi data Direct3D diaplikasikan ke verteks yang kemudian disimpan di verteks buffer. Selanjutnya

tahap Geometry Processing akan melakukan beberapa proses yang meliputi

clipping, backface culling, evaluasi atribut, dan rasterization yang kemudian

digunakan pada verteks yang sudah ditransformasikan. Tahapan Pixel Processing

akan melakukan operasi pixel shader menggunakan data geometri untuk

memodifikasi input nilai verteks dan data tekstur sehingga menghasilkan output

berupa nilai warna pixel (pixel color values). Dan terakhir pada tahapan Pixel Rendering merupakan proses rendering akhir yang memodifikasi warna pixel dengan nilai alpha, depth (kedalaman), stencil testing, blending dan fog lalu semua hasil nilai pixel akan ditampilkan ke output display (layar). Tahapan-tahapan pipeline grafis tersebut harus dilalui untuk menghasilkan gambar tiga dimensi sekecil apapun agar dapat di proses ke dalam layar.

Berdasarkan penjelasan diatas maka pengembang akan sulit untuk mengembangkan aplikasi berbasis tiga dimensi dikarenakan oleh proses yang panjang dan kompleks dari prosedur tahapan-tahapan pipeline grafis dari API. Permasalahan lainnya adalah banyaknya fungsi-fungsi teknis yang rumit pada API seperti fungsi persiapan device beserta parameternya, pengaturan tipe data

STIKOM

verteks, pengaturan buffer-buffer untuk perangkat grafis tiga dimensi dan sebagainya. API grafis tiga dimensi juga memiliki keterbatasan yaitu kurangnya dukungan algoritma-algoritma untuk efisiensi dan efektifitas dalam proses rendering, dan perhitungan matematika dalam mengolah data tiga dimensi. Serta tidak adanya manajemen untuk mengelola sumber daya yang saling terintegrasi antara perangkat lunak yang dikembangkan oleh pihak pengembang dengan perangkat keras grafis tiga dimensi yang disediakan.

Untuk mengatasi permasalahan diatas maka perlu dirancang suatu sistem framework rendering engine yang membantu pihak pengembang dalam mengembangkan aplikasi berbasis tiga dimensi yang diinginkan. Konsep framework dinilai dapat sangat bermanfaat untuk pengembangan aplikasi karena fungsi dan perintah dari API grafis seperti Direct3D berserta algoritma-algoritma dan perhitungan matematika akan dikelompokkan ke dalam modul-modul subsistem yang saling terintegrasi antara satu dengan yang lain. Kemudian akan menyediakan class-class yang berisi perintah dan fungsi-fungsi yang hanya dibutuhkan oleh pihak pengembang untuk membuat suatu aplikasi berbasis tiga dimensi. Sedangkan rendering engine berfungsi sebagai manjemen pengelolaan sumber daya dari aplikasi yang dibuat ketika ditampilkan di layar (secara realtime). Rendering engine juga melakukan fungsi-fungsi tertentu (khusus) seperti enumerasi adapter grafis, mengolah data dan model tiga dimensi, berkomunikasi dengan kartu grafis, mengelola memory (buffer), melakukan komputasi perhitungan matematika dan pekerjaan-pekerjaan tingkat rendah lainnya. Selain itu pada framework rendering engine ini menggunakan teknologi SIMD atau perhitungan matematika cepat dengan bantuan hardware seperti MMX

STIKOM

dan SSE untuk mengolah komputasi algoritma dan perhitungan matematika. Dengan adanya framework rendering engine tersebut pihak pengembang akan lebih mudah mengelola dan menjalankan aplikasi berbasis tiga dimensi yang dikembangkannya sesuai dengan yang diharapkan.

3.2. Algoritma Manajemen Scene

Dalam proses rendering algoritma manajemen scene merupakan instrumen yang sangat penting jika ingin menampilkan menampilkan lebih dari ratusan ribu polygon segitiga yang membentuk obyek-obyek 3D ke dalam layar. Hal ini dikarenakan keterbatasan dari pengolahan yang dapat dilakukan oleh kartu grafis yang ada saat ini. Algoritma tersebut membantu memilih polygon yang diperlukan terhadap lokasi dan orientasi tertentu dari penonton agar dapat dikeluarkan dari seluruh anggota ratusan ribu lebih polygon dari scene. Karena kebanyakan dari polygon tersebut tidak terlihat oleh user. Metode algoritma manajemen scene yang akan digunakan oleh framework rendering engine ini adalah Octree dan BSP Tree.

3.2.1. Algoritma Octree

Octree merupakan salah satu algoritma manajemen scene yang umumnya digunakan untuk area outdoor. Algoritma tersebut akan membagi menjadi 8 kelompok simpul kecil dari kelompok polygon secara rekursif, yang kemudian dapat diuji persimpangannya dan melakukan traversal agar dapat ditampilkan pada layar. Berikut adalah pembuatan algoritma Octree berdasarkan inputan polygon.

STIKOM

Gambar 3.2 Flowchart Pembuatan Algoritma Octree

Mulai

Load seluruh polygon

Buat obyek Octree

Set Octree menjadi Root

Daftarkan polygon & jumlahnya ke dalam

Octree

Kalkulasi Bounding Box Root

Cek apakah jumlah polygon > 10

Inisialisasi Child berdasarkan ID dan Parentnya sebanyak 8

bagian

Proses memisahkan polygon berdasarkan

Bounding Box Child Ya

Rekursif Pembuatan Child

Selesai Tidak

STIKOM

Berikut adalah penjelasan langkah-langkah pembuatan algoritma Octree:

1. Pertama-tama diawali dengan seluruh memuat (load) seluruh polygon baik

yang berasal dari file atau sumber lainnya (data polygon disimpan menjadi pointer array TumozPolygon).

2. Proses selanjutnya adalah membuat obyek Octree yang ditujukan untuk membangun tree baru berdasarkan polygon yang ada.

3. Polygon-polygon yang telah di muat kemudian didaftarkan pada Octree yang baru dibuat dan juga memasukkan jumlahnya sebagai parameter. 4. Octree yang baru dibuat tersebut kemudian dijadikan root (simpul akar)

atau parent (simpul induk) dari tree (diagram pohon). Hal ini dilakukan agar menjadi acuan bagi semua child (simpul anak).

5. Setelah di atur menjadi root, maka dilanjutkan dengan proses

mengkalkulasi bounding box root tersebut. Setiap obyek simpul di dalam Octree harus mengkalkulasikan bounding boxnya (menggunakan AABB) agar nanti dapat dikelompokkan berdasarkan posisisnya dan untuk mengetahui ruang lingkup dari tiap simpul.

6. Setelah itu melakukan pemeriksaan jumlah anggota simpul yaitu

polygon-polygon yang telah didaftarkan, apabila melebihi batas jumlah yang ditentukan maka akan dilanjutkan ke proses selanjutnya (sistem ini memberikan batas 10 polygon per simpul). Dan jika sebaliknya maka akan menjadi simpul daun (leaf) sehingga proses pembuatan child akan diakhiri. 7. Root atau parent akan di bagi menjadi 8 child dan melakukan proses inisialisasi. Inisialisasi tersebut merupakan proses pemberian ID untuk masing-masing child, lalu mengkalkulasi ulang bounding box berdasarkan

STIKOM

posisinya, serta menyimpan data parentnya. Kedelapan ID atau Posisi dari child tersebut adalah Timur Laut Atas (UP_NE), Barat Laut Atas (UP_NW), Tenggara Atas (UP_SE), Barat Daya Atas (UP_SW), Timur Laut Bawah (LW_NE), Barat Laut Bawah (LW _NW), Tenggara Bawah (LW _SE), dan Barat Daya Bawah (LW _SW).

8. Apabila child telah diinisialisasi maka dilanjutkan dengan proses

memotong atau mengelompokkan polygon-polygon berdasarkan ruang lingkup bounding box dari child tersebut. Setelah selesai maka akan dilakukan proses rekursif kembali ke langkah ke 6, dan menjadikan child tersebut menjadi root atau parent bagi child dibawahnya secara terus menerus sampai memenuhi kondisi dimana jumlah polygon tidak melebihi batas yang telah ditentukan yaitu 10 polygon pada langkah ke 6.

3.2.2. Algoritma BSP Tree

Berbeda dengan Octree, BSP Tree (Binary Space Partitioning Tree) merupakan algoritma manajemen scene yang sangat efektif digunakan untuk area

indoor. Prinsip dari BSP Tree adalah membagi menjadi 2 kelompok simpul kecil dari kelompok-kelompok polygon secara rekursif. Dan hampir sama dengan Octree hasil dari BSP Tree tersebut dapat diuji persimpangannya dan juga dapat melakukan traversal ke dalam simpul-simpul agar dapat ditampilkan ke layar. Berikut adalah pembuatan algoritma BSP Tree berdasarkan inputan polygon.

STIKOM

Mulai

Load seluruh polygon

Buat obyek BSP Tree

Daftarkan polygon & jumlahnya ke dalam

BSP Tree

Set BSP Tree menjadi Root & Parent = NULL

Kalkulasi Bounding Box simpul ini

Mengklasifikasikan kelompok polygon dan mendaftarkan ke

Front dan Back Child Membuat obyek child

baru BSP Tree Front dan Back Rekursif Front & Back Child

Splitter terbaik ditemukan?

Ya

Selesai Tidak

Gambar 3.3 Flowchart Pembuatan Algoritma BSP Tree

STIKOM

Berikut adalah penjelasan langkah-langkah pembuatan algoritma BSP Tree: 1. Seluruh polygon baik yang berasal dari file atau sumber lainnya di muat

terlebih dahulu sebagai inputan (biasanya disimpan menjadi pointer array TumozPolygon).

2. Membuat obyek BSP Tree yang ditujukan untuk membangun tree baru

berdasarkan polygon yang ada atau polygon yang di muat sebelumnya. 3. Polygon-polygon yang telah di muat tersebut kemudian didaftarkan pada

BSP Tree yang baru dibuat dan sekaligus memasukkan jumlahnya sebagai parameter.

4. BSP Tree yang di buat tersebut kemudian dijadikan simpul root dan simpul parent di set menjadi NULL yang menandakan bahwa simpul tersebut tidak memiliki induk.

5. Pada tahapan ini merupakan awal dari proses pembuatan simpul child dan

proses yang dilakukan adalah melakukan kalkulasi bounding box (AABB) pada simpul ini. Tujuan dari proses tersebut adalah untuk mengetahui ruang lingkup dari tiap simpul.

6. Proses selanjutnya adalah mencari splitter terbaik dari simpul ini. Splitter tersebut merupakan plane pemisah yang nanti digunakan untuk memisahkan daftar polygon-polygon dari simpul ini. Berdasarkan daftar polygon yang ada splitter dapat di cari dengan cara sebagai berikut. Pertama-tama membuat perulangan pada seluruh daftar polygon ke dalam

outer loop (perulangan luar). Untuk setiap iterasi dari perulangan, pilih polygon terpilih saat ini dari daftar dan asumsikan sebagai splitter. Kemudian jalankan inner loop (perulangan dalam) yang juga melakukan

STIKOM

perulangan terhadap polygon dari daftar, dan klasifikasikan masing-masing polygon terhadap polygon yang sebelumnya dianggap sebagai splitter. Hitung berapa banyak polygon yang berada di sisi depan, di sisi belakang, dan berapa banyak polygon yang terpisah. Ketika inner loop selesai, hitung skor dari polygon yang seharusnya menjadi splitter dan bandingkan skor tersebut terhadap skor terbaik (terendah) yang dapat ditemukan. Dan arahkan pointer ke skor terendah karena semakin tinggi skor, maka semakin buruk polygon tersebut untuk menjadi splitter. Apabila splitter tidak ditemukan maka proses akan menjadikan simpul ini menjadi leaf (simpul daun) dan mengakhiri proses pembuatan tree.

7. Setelah itu dilanjutkan dengan membuat obyek child BSP Tree baru yaitu

front (simpul depan) dan back (simpul belakang) dan mengatur simpul ini sebagai parentnya.

8. Berdasarkan splitter terbaik yang telah ditemukan, maka proses

selanjutnya adalah mengklasifikasikan splitter tersebut terhadap daftar polygon yang ada pada simpul ini. Apabila polygon ada di depan dari spliter, maka masukkan ke dalam daftar polygon dari child front. Untuk yang di belakang, polygon dimasukkan ke dalam daftar polygon dari child back. Apabila polygon berpotongan dengan splitter, maka polygon di clipping (dipotong atau dibelah) dan masing-masing hasil polygon depan dan belakangnya dimasukkan ke daftar child front dan back. Dan Terakhir apabila polygon berada pada posisi splitter, maka periksa sudut antara normalnya dengan normal splitter. Jika hasil sudutnya sama dengan 0 atau positif maka normal dari polygon tersebut searah dengan normal splitter

STIKOM

dan dimasukkan ke dalam daftar polygon dari child front. Dan sebaliknya jika hasilnya negatif maka polygon tersebut dimasukkan ke dalam daftar polygon dari child back. Setelah proses klasifikasi dan pendaftaran polygon selesai maka masing-masing child front dan back akan melakukan proses rekursif kembali ke langkah ke 5, dan menjadikan child tersebut menjadi parent bagi child dibawahnya secara terus menerus sampai memenuhi kondisi tidak menemukan splitter terbaik pada langkah ke 5.

3.3. Perancangan Sistem

Berdasarkan analisa identifikasi permasalahan yang telah dilakukan sebelumnya bahwa Framework rendering engine ini dibangun menggunakan API Direct3D dari Microsoft DirectX SDK dan diprogram dengan bahasa pemrograman C++. Sedangkan desain sistemnya menggunakan UML dan flowchart pada masing-masing fungsi framework. Garis besar desain sistem rancang bangun yang akan dibuat digambarkan seperti gambar di bawah ini:

Aplikasi Berbasis 3D Static Library

Tumoz3D.lib untuk Matematika &

Algoritma 3D

Static Library TumozGeneral.lib untuk

Kontrol Pergerakan, Kamera dsb

Static Library TumozRenderer.lib

untuk interface Sistem Rendering

Dynamic Library TumozD3D.dll untuk implementasi Sistem

Rendering Render Interface

Buat Obyek Beri Device

Load Implemen

Gunakan

Gunakan Gunakan

Gunakan Gunakan

Gambar 3.4. Gambaran Umum Rancang Bangun Sistem

STIKOM

Pada gambar diatas sistem dijelaskan menjadi beberapa tahapan sebagai berikut:

1. Pihak developer yang mengembangkan aplikasi berbasis 3D dapat

menggunakan tiga library yang disediakan dari framework ini antara lain TumozRenderer.lib, Tumoz3D.lib, dan TumozGeneral.lib.

2. Aplikasi pengembangan membuat obyek dari TumozRenderer.lib sebagai

library utama untuk menjalankan engine. Kemudian aplikasi tersebut memberikan permintaan device yang dibutuhkan berdasarkan API.

3. TumozRenderer.lib berfungsi sebagai interface dan class abstrak

sedangkan fungsi-fungsi utama rendering engine dalam melakukan komunikasi dengan API berada didalam TumozD3D.dll. Dengan demikian ketika obyek dibuat pada aplikasi pengembangan secara otomatis TumozRenderer.lib memuat (load) TumozD3D.dll.

4. TumozD3D.dll melakukan implementasi pada obyek Render Device

sehingga fungsi-fungsinya dapat digunakan oleh aplikasi pengembangan. Tugas dari render device tersebut antara lain insialisasi rendering, menentukan resolusi, penggunaan shader, melakukan proses-proses yang dibutuhkan pada tahapan rendering pipeline, dan sebagainya.

5. TumozRenderer.lib dan TumozD3D.dll juga berisi 2 obyek engine

tambahan yaitu TumozSkinManager dan TumozVertexCacheManager. TumozSkinManager berfungsi untuk mengelola penggunaan warna, material dan tekstur berdasarkan implementasi pada API. Sedangkan TumozVertexCacheManager berfungsi sebagai manajemen verteks dan indeks buffer dalam melakukan proses rendering.

STIKOM

6. Aplikasi pengembangan dapat menggunakan class-class didalam Tumoz3D.lib yang terpisah dari TumozRenderer.lib. Class-class tersebut merupakan perhitungan matematika dan algoritma yang diperlukan untuk mengembangkan aplikasi berbasis 3D.

7. Selain Tumoz3D.lib aplikasi pengembangan juga dapat menggunakan

library TumozGeneral.lib yang berisi class dan fungsi untuk manajemen scene, kontrol pergerakan dan informasi yang dibutuhkan dalam proses rendering.

8. TumozD3D.dll juga menggunakan library Tumoz3D.lib dan

TumozGeneral.lib dalam melakukan perhitungan matematika dan algoritma serta fungsi-fungsi yang diperlukan lainnya untuk memproses dan menjalankan sistem rendering engine.

3.4. Class Diagram

Class diagram atau diagram kelas digunakan untuk menampilkan kelas-kelas atau paket-paket di dalam sistem dan relasi antar mereka. Relasi antar kelas-kelas pada Framework Tumoz Rendering Engine diilustrasikan sebagai berikut:

STIKOM

Gambar 3.5. Class Diagram Tumoz Rendering Engine TumozMCEgo (from TumozGeneral) TumozTimer (from TumozGeneral) TumozMCFree (from TumozGeneral) TumozSkinManager (from TumozRenderer) TumozVertexCacheManager (from TumozRenderer) TumozRenderer (from TumozRenderer) TumozRenderDevice (from TumozRenderer) 1 1 ₁

1 ₁₁ 11

dibuat oleh TumozD3DSkinManager (from TumozD3D) TumozD3DVCManager (from TumozD3D) TumozD3DVCache (from TumozD3D) 1 * 1 * TumozPolylist (from Tumoz3D) TumozOctree (from Tumoz3D) TumozPolygon (from Tumoz3D) 1 * 1 * membangun TumozBSPTree (from Tumoz3D) membangun TumozD3DEnum (from TumozD3D) TumozPlane (from Tumoz3D) memotong membagi TumozAabb (from Tumoz3D) membatasi membatasi membatasi TumozObb (from Tumoz3D) TumozRay (from Tumoz3D) TumozMovementController (from TumozGeneral) TumozD3D (from TumozD3D) 1 1 1 1 digunakan TumozVector (from Tumoz3D) digunakan mengatur bersimpangan bersimpangan bersimpangan menghitung TumozQuat (from Tumoz3D) TumozMatrix (from Tumoz3D) digunakan mentrasformasi dirubah ke

STIKOM

SURABAYA

Gambar 3.5. menunjukkan bahwa Framework Tumoz Rendering Engine menyediakan 3 kelas abstrak utama yang berfungsi sebagai interface yaitu TumozRenderDevice, TumozSkinManager, dan TumozVertexCacheManager. Implementasi dari masing-masing interface tersebut mengarah pada kelas implementasi yang mengacu pada referensi API Direct3D yaitu TumozD3D, TumozD3DSkinManager, dan TumozD3DVCManager. Karena interface tersebut bersifat dinamis (dynamic link library) maka kelas TumozRenderer bertugas untuk membuat dan menentukan hubungan antara kelas interface dengan kelas implementasi yang sesuai. Dan Kelas TumozD3DVCache menjadi bagian yang membentuk (agregasi) dari kelas TumozVertexCacheManager, begitu juga pada kelas TumozD3DEnum yang merupakan bagian dari TumozD3D.

Kelas TumozD3D menggunakan beberapa kelas untuk algoritma dan perhitungan tiga dimensinya antara lain: TumozVector, TumozMatrix, dan TumozPlane. Sedangkan kelas lainnya yang tersedia untuk perhitungan geometri dan algoritma tiga dimensi adalah: TumozQuat, TumozRay, TumozPolygon, TumozAabb, TumozObb, TumozBSPTree, dan TumozOctree. Juga berserta kelas TumozPolylist yang memiliki anggota dari kelas TumozPolygon.

Kelas TumozVector memiliki beberapa peranan penting dalam penggunaan algoritma dan perhitungan tiga dimensi. Salah satunya adalah kelas TumozVector merupakan dasar untuk menghitung transformasi (seperti rotasi dan pergerakan obyek tiga dimensi) pada kelas TumozMatrix. TumozVector juga

digunakan untuk menghitung persimpangan (intersection) pada kelas TumozRay,

TumozAabb, dan TumozObb. Pada kelas TumozPlane untuk mengatur bidang yang akan dibentuk membutuhkan kelas TumozVector. Dan peran kelas

STIKOM

TumozVector lainnya adalah untuk membantu perhitungan geometri pada kelas TumozMovementController contohnya seperti letak kamera, sudut pandang dan sebagainya. Selain kelas TumozVector peranan penting lainnya juga terdapat pada kelas TumozQuat yang dapat mengubah (konversi) nilai-nilai dari kelas TumozMatrix untuk menghitung rotasi obyek tiga dimensi.

Seperti yang terlihat pada gambar 3.5, kelas TumozMovementController mempunyai dua kelas turunan yaitu kelas TumozMCEgo dan TumozMCFree. Sedangkan kelas TumozTimer tidak memiliki relasi dengan kelas manapun, akan tetapi TumozTimer memiliki referensi dengan library standar C++ (stdlib). Berdasarkan gambar relasi antar kelas diatas, maka selanjutnya adalah penjelasan secara detil fungsionalitas dari masing-masing kelas di dalam Framework Tumoz Rendering Engine.

3.4.1. Class TumozRenderer

Kelas TumozRenderer mempunyai beberapa atribut dan operasi untuk menentukan jenis API yang ingin dijadikan implementasi agar dapat dibuatkan obyeknya dan dihubungkan ke dalam interface. Untuk lebih jelasnya dapat dilihat pada gambar 3.6.

Gambar 3.6. Class TumozRenderer

STIKOM

3.4.2. Class TumozRenderDevice

Kelas TumozRenderDevice merupakan interface yang ditujukan untuk menjadi acuan (prototype) bagi kelas implementasi yang paling utama yang bertugas dalam mengelola perangkat rendering. Acuan itu berupa atribut dan operasi-operasi virtual yang berhubungan dengan pengolahan perangkat rendering seperti inisialisasi perangkat grafis rendering, menjalankan dan menghentikan proses rendering, mengatur pencahayaan, membuat obyek manajer verteks dan manajer skin dan sebagainya. Untuk lebih jelasnya dapat dilihat pada gambar 3.7.

Gambar 3.7. Class TumozRenderDevice

STIKOM

3.4.3. Class TumozVertexCacheManager

Kelas TumozVertexCacheManager memiliki peranan yang hampir sama dengan kelas TumozRenderDevice yaitu sebagai interface yang berfungsi sebagai prototype bagi kelas implementasi yang memanajemen pengelolaan hal-hal yang berhubungan dengan verteks. Operasi-operasi yang ada terdiri dari pembuatan buffer (memory penyimpanan) verteks statis dan buffer indeks, merender masing-masing verteks baik dalam bentuk titik, garis, ataupun polygon, mengirim konten verteks dan indeks dari buffer ke perangkat rendering agar dapat di gambar, validasi kondisi atau status verteks, dan lain-lain. Untuk lebih jelasnya dapat dilihat pada gambar 3.8.

Gambar 3.8. Class TumozVertexCacheManager

3.4.4. Class TumozSkinManager

Kelas TumozSkinManager juga merupakan interface yang berfungsi sebagai prototype atau acuan bagi kelas implementasi yang memanajemen hal-hal yang berkaitan dengan pemberian warna atau tekstur pada lapisan terluar atau

STIKOM

disebut skin (kulit) dari obyek tiga dimensi. Bentuk struktur dari kelas TumozSkinManager adalah sebagai berikut:

Gambar 3.9. Class TumozSkinManager

Seperti pada gambar 3.9. operasi-operasi yang tersedia pada kelas TumozSkinManager antara lain menambah dan mengganti skin atau tekstur dari obyek tiga dimensi, mengubah warna material, membandingkan warna material, dan sebagainya.

3.4.5. Class TumozD3D

Kelas TumozD3D merupakan kelas implementasi paling penting dan paling utama yang merupakan turunan dari interface TumozRenderDevice. Fungsi dari kelas ini adalah mengelola perangkat rendering dengan menggunakan

STIKOM

referensi dari API Direct3D. Kelas TumozD3D mengelola hampir seluruh proses penting yang ada di dalam Framework Tumoz Rendering Engine. Dan struktur dari kelas TumozD3D digambarkan oleh gambar di bawah ini:

Gambar 3.10. Class TumozD3D

Atribut dari kelas TumozD3D terdiri dari pointer dari obyek-obyek API

Direct3D yang berhubungan dengan perangkat rendering seperti Direct3D9,

Direct3DDevice9, D3DXFont, dan lain-lain. Selain itu atribut-atribut pada kelas TumozD3D juga berisi status atau kondisi dari jalannya sistem rendering.

STIKOM

Sedangkan operasi-operasi yang ada di dalam kelas TumozD3D sama dengan operasi-operasi virtual yang ada di dalam interface TumozRenderDevice dengan tambahan fungsi-fungsi bantuan (helper function) untuk proses internal contohnya fungsi OneTimeInit(), Go(), Log(), dan sebagainya.

3.4.6. Class TumozD3DSkinManager

Kelas TumozD3DSkinManager adalah kelas implementasi dari interface TumozSkinManager yang menggunakan API Direct3D. Fungsi dari kelas TumozD3DSkinManager sama dengan interface TumozSkinManager yang telah dijelaskan sebelumnya disertai dengan atribut dan operasi tambahan untuk penerapan internal sistem. Untuk lebih jelasnya dapat dilihat pada gambar 3.11.

Gambar 3.11. Class TumozD3DSkinManager

STIKOM

3.4.7. Class TumozD3DVCManager

Seperti kelas TumozD3D dan TumozD3DSkinManager bahwa TumozD3DVCManager juga merupakan kelas implementasi API Direct3D dari interface TumozVertexCacheManager. Struktur kelasya adalah sebagai berikut:

Gambar 3.12. Class TumozD3DVCManager

STIKOM

Konsep manajemen verteks pada API Direct3D menggunakan sistem

Flexible Vertex Format (FVF) sehingga bebas untuk menentukan sendiri secara fleksibel format dari verteks yang sesuai dengan kebutuhan. Akan tetapi pada kelas TumozD3DVCManager hanya menyediakan 6 pilihan pada atribut format verteks yaitu:

1. Position Untransformed Vertex (PS) adalah format verteks yang hanya berisi data posisi saja tanpa adanya transformasi.

2. Unstransformed and Unlit Vertex (UU) yaitu merupakan format verteks yang berisi data posisi, vektor normal, dan koordinat tekstur. Biasanya digunakan untuk menggambarkan benda tanpa disertai efek pancahayaan.

3. Unstransformed and Lit Vertex (UL) yaitu merupakan format verteks yang

paling umum dipakai yang berisi data posisi, warna material diffuse, dan koordinat tekstur. Benda yang digambar menggunakan format verteks ini dapat dipengaruhi oleh efek pencahayaan.

4. Character Animation (CA) adalah format verteks yang berisi data posisi, vektor normal, dan koordinat tekstur. Biasanya digunakan untuk menggambarkan animasi karakter.

5. Three Texture Coordinat (3T) adalah format verteks yang berisi data posisi, vektor normal, dan 3 koordinat tekstur. Biasanya digunakan untuk efek-efek spesial atau khusus seperti detail map, heightmap dan lain-lain. 6. Tangent Vector (TV) adalah format verteks yang berisi data posisi, vektor

normal, koordinat tekstur, dan vektor tangen. Biasanya juga digunakan untuk spesial efek seperti bump mapping, dan sebagainya.

STIKOM

8 Membuat obyek tiga dimensi berdasarkan verteksnya Enumeration TUMOZVERTEXID, array verteks, dan array indeks

ID obyek tiga dimensi

yang telah di buat Sukses

9

Melakukan rendering obyek tiga dimensi pada scene

ID obyek tiga dimensi

Menampilkan gambar obyek tiga dimensi pada scene

Sukses

4.6.4. Hasil Uji Coba Transformasi dan Pencahayaan

Hasil uji coba proses transformasi dan pencahayaan untuk pergerakan dinamis dan beragam efek pencahayaan dapat dilihat pada tabel 4.5.

Tabel 4.5. Hasil Uji Coba Transformasi dan Pencahayaan Test

Case Tujuan Input

Output yang

diharapkan Status

10 Melakukan proses transformasi obyek tiga dimensi pada scene TumozMatrix yang merupakan hasil gabungan transformasi pada seluruh scene

Menampilkan transformasi dan pergerakan obyek tiga dimensi pada saat rendering Sukses 11 Melakukan efek pencahayaan secara merata pada scene

3 nilai float untuk merah, hijau, dan biru

Scene akan diterangi oleh cahaya secara merata Sukses 12 Melakukan beragam efek pencahayaan secara khusus pada stage tertentu Structure TUMOZLIGHT, dan indeks stage yang di tuju

Scene akan diterangi bermacam-macam efek pencahayaan seperti efek cahaya lampu sorot, dsb

Sukses

STIKOM

139

4.6.5. Hasil Uji Coba Implementasi Shader

Hasil uji coba implementasi shader untuk pemrograman vertex dan pixel shader dapat dilihat pada tabel 4.6.

Tabel 4.6. Hasil Uji Coba Implementasi Shader Test

Case Tujuan Input

Output yang

diharapkan Status 13

Membuat obyek vertex dan pixel shader

Nama file atau stream data shader, boolean file, dan boolean kompilasi

ID shader yang telah

di buat Sukses

14

Mengatur variabel konstan untuk

membantu proses shader

Enumeration

TUMOZSHADERTYPE, TUMOZDATATYPE, indeks register awal, jumlah array data, dan data array nilai variabel

Menyediakan variabel konstan yang akan digunakan pada proses shader

Sukses

15

Mengaktifkan shader pada saat proses rendering

ID shader yang telah dibuat, dan enum TUMOZVERTEXID untuk verteks shader

Beragam efek shading pada proses rendering

Sukses

STIKOM

140 BAB V PENUTUP

5.1. Kesimpulan

Kesimpulan yang di dapat dari hasil pembuatan Rancang Bangun Framework Rendering Engine Untuk Pengembangan Aplikasi Berbasis Tiga Dimensi setelah dilakukan analisa, perancangan, implementasi dan serta evaluasi uji cobanya adalah sebagai berikut:

1. Framework rendering engine ini dapat digunakan dan diintegrasikan pada beragam pengembangan aplikasi berbasis tiga dimensi, baik hanya sebagai fitur tambahan maupun sebagai fitur utama dari aplikasi tersebut. Dan berdasarkan hasil evaluasi sistem bahwa software pengembangan ini sudah menghasilkan output yang diharapkan.

2. Berdasarkan dari hasil pengujian sistem rendering dapat disimpulkan bahwa menggunakan framework rendering engine jauh lebih efektif dan efisien dalam pemanggilan fungsi-fungsi kode pengembangan aplikasi dibandingkan dengan menggunakan API lainnya seperti DirectX dan juga memudahkan pengembang untuk membuat aplikasi 3D.

3. Sistem manajemen scene membantu meningkatan performa dari proses rendering yaitu menggunakan algoritma Octree dan BSP Tree, perhitungan 3D, timer, dan kontrol kamera dari framework rendering engine. Selain itu juga dibantu dengan menggunakan teknologi SIMD sehingga dapat meningkatkan nilai frame rate per second sebesar antara 24% sampai dengan 40%.

STIKOM

141

5.2. Saran

Rancang bangun dari framework rendering engine ini masih memiliki banyak kekurangan-kekurangan yang perlu ditambahkan agar dapat berjalan menjadi lebih efektif dan efisien. Maka saran-saran untuk pengembangan lebih lanjut ke depan adalah sebagai berikut:

1. Perlunya penambahan implementasi API grafis 3D lainnya selain Direct3D seperti OpenGL atau SDL. Karena sistem ini sudah menerapkan sistem implementasi library dinamis (DLL).

2. Menambahkan subsistem engine tambahan yang membantu pengembangan aplikasi yang lebih luas, seperti AI (artificial inteligence), physics, scripting, sistem jaringan dan lain lain.

3. Framework rendering engine ini kedepannya diharapkan mampu menangani fungsi-fungsi algoritma dan perhitungan matematika tingkat lanjut, seperti LOD (Level Of Detail), curves, occlusion culling, dan sebagainya.

STIKOM

142

DAFTAR PUSTAKA

Bao, H. and Hua, W., 2011, Real-Time Graphics Rendering Engine, Zhejiang University Press, Huangzhou.

Cockshott, P. And Renfrew, K., 2004, SIMD Programming Manual for Linux and

Windows, Springer-Verlag Limited, London.

Dunn, F. and Parberry I., 2002, 3D Math Primer for Graphics and Game

Development, Wordware Publishing, Inc., Texas.

Foley, J.D., van Dam, A., Feiner, S.K., and Hughes, J.F., 1996, Computer

Graphics: Principles and Practice, Second Edition in C,

Addison-Wesley Publishing Company, Inc., Menlo Park.

Fowler, M., 2005, UML Distilled, Edisi Ketiga, Penerbit ANDI, Yogyakarta. Freeman, E. and Freeman, E., 2004, Head First Design Patterns, O’Reilly Media,

Inc., Sebastopol.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J., 1994, Design Patterns

Elements of Reusable Object-Oriented Software, Addison-Wesley

Publishing Company, Inc., New Jersey.

Horton, I., 2006, Beginning Visual C++ 2005, Wiley Publishing, Inc., Indianapolis.

Johnson, R.E., 1992, Documenting Frameworks using Patterns, ACM Press: Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, 63–76.

Jones, W., 2004, Beginning DirectX 9, Thomson Course Technology PTR., Boston.

Kadir, A., 1995, Pemrograman C++, Penerbit ANDI, Yogyakarta.

Lakos, J., 1996, Large-Scale C++ Software Design, Addison-Wesley Publishing Company, Inc., Menlo Park.

Lengyel, E., 2004, Mathematics for 3D Game Programming and Computer

Graphics, Second Edition, Charles River Media, Inc., Hingam.

Luna, Frank D., 2003, Introduction to 3D Game Programming with DirectX 9.0, Wordware Publishing, Inc., Texas.

STIKOM

143

Möller, T.A., Haines, E. and Hoffman, N., 2008, Real-Time Rendering, Third Edition, A K Peters, Ltd., Wellesley.

Riehle, D., 2000, Framework Design: A Role Modeling Approach, Swiss Federal Institute of Technology, Zurich.

Santosa, I., 1994, Grafika Komputer dan Antarmuka Grafis, ANDI OFFSET, Yogyakarta.

Schildt, H., 2003, C++: The Complete Reference, Fourth Edition, McGraw-Hill, Osborne.

Schmuller, J. 1999, Sams Teach Yourself UML in 24 Hours, Sams Publishing, Indianapolis.

Schneider, P.J. and Eberly, D.H., 2002, Geometric Tools for Computer Graphics, Morgan Kaufmann Publishers, San Francisco.

Sholiq, 2006, Pemodelan Sistem Informasi Berorientasi Objek Dengan UML, Graha Ilmu, Yogyakarta.

Stroustrup, B., 1997, The C++ Programming Language, Third Edition, Addison-Wesley Publishing Company, Inc., Reading.

Watt, A., 1993, 3D Computer Graphics, Second Edition, Addison-Wesley Publishing Company, Inc., Menlo Park.

Zerbst, S. and Dü_{vel, O., 2004, 3D Game Engine Programming, Thomson Course} Technology PTR., Boston.

STIKOM