Pemrograman grafis 3D di Java, Bagian 3: OpenGL

Sudah lama sejak angsuran terakhir kami dalam seri ini tentang pemrograman grafis 3D di Java (lebih lanjut tentang itu di akhir kolom ini). Berikut adalah penyegaran singkat tentang apa yang terakhir kita diskusikan dan di mana kita tinggalkan.

Dalam dua kolom sebelumnya (lihat Sumber), kami menjelajahi Java 3D. Kami membahas konten statis dan pemandangan kecil, lalu menggunakan grafik pemandangan yang lebih besar dan membangun interaktivitas ke dalam beberapa dunia 3D dasar.

Sekarang setelah Anda mengetahui sedikit tentang penggunaan Java 3D, sekarang saatnya untuk membandingkan dan membedakan pendekatan Java 3D ke grafik 3D dengan pesaing API grafik terkemuka: OpenGL.

Harap dicatat bahwa artikel ini pada awalnya dimaksudkan untuk menjadi kode intensif, tetapi keputusan terlambat oleh Arcane Technologies mengenai pengikatan Magician (lihat di bawah) mengharuskan penghapusan contoh kode. Saya berharap konten artikel ini dapat diadaptasi untuk pengikatan Java-OpenGL di masa mendatang, yang belum tersedia dari Konsorsium OpenGL.

Bagaimanapun, saya telah berusaha untuk menyediakan semua referensi dan URL terkait OpenGL yang relevan dan berguna di Sumberdaya di akhir kolom ini. Jika Anda ingin menggali lebih jauh tentang Java-OpenGL, saya sangat menyarankan agar Anda meninjau referensi ini.

Perbandingan Java-OpenGL dengan Java 3D

Pada angsuran sebelumnya di Java 3D, saya memberikan daftar kekuatan dan kelemahan menggunakan Java 3D untuk aplikasi grafik. Mari kita ulangi daftar itu, tetapi lakukan dengan melihat kekuatan dan kelemahan solusi berbasis Java-OpenGL daripada solusi berbasis Java 3D.

Kekuatan menggunakan OpenGL (dan, dengan ekstensi dan jika dicatat, pengikatan Java-OpenGL):

  • OpenGL menyediakan model grafik prosedural

    Ini sangat cocok dengan banyak algoritme dan metode yang digunakan pemrogram grafik secara historis. Model prosedural sekaligus intuitif dan lugas bagi banyak penggemar grafis 3D yang ulung.

  • OpenGL menyediakan akses langsung ke pipeline rendering

    Hal ini berlaku untuk semua binding bahasa, termasuk sebagian besar binding Java. OpenGL memberdayakan pemrogram untuk secara langsung menentukan bagaimana grafik harus dirender. Seseorang tidak hanya memberi petunjuk dan meminta seperti pada Java 3D, seseorang menetapkannya.

  • OpenGL dioptimalkan dengan segala cara yang bisa dibayangkan

    OpenGL dioptimalkan dalam perangkat keras dan perangkat lunak serta platform yang ditargetkan mulai dari PC dan konsol game termurah hingga superkomputer grafis paling canggih.

  • Vendor dari setiap jenis perangkat keras yang berhubungan dengan grafik 3D mendukung OpenGL

    OpenGL adalah

    itu

    standar yang digunakan vendor perangkat keras untuk mengukur teknologi grafis mereka, tidak ada batasan. Karena Microsoft telah bergabung dengan SGI dalam inisiatif Fahrenheit, menjadi semakin jelas bagi banyak orang bahwa ini adalah pengakuan tidak langsung Microsoft bahwa OpenGL memenangkan perang API untuk grafik 2D dan 3D.

Di sisi lain, tidak ada yang sempurna. OpenGL, dan tentunya pengikatan Java-OpenGL, memiliki beberapa kekurangan yang signifikan:

  • Kekuatan pendekatan prosedural untuk pemrograman grafis secara bersamaan merupakan kelemahan bagi banyak programmer Java

    Untuk programmer yang relatif baru, banyak dari mereka mungkin telah menerima instruksi pemrograman formal pertama mereka di Java menggunakan metodologi berorientasi objek, metode prosedural OpenGL tidak cocok dengan pendekatan berorientasi objek dan praktik teknik yang baik.

  • Banyak pengoptimalan OpenGL vendor dimaksudkan untuk mengurangi pilihan perangkat keras

    Merupakan kepentingan terbaik setiap vendor untuk membangun ekstensi berpemilik dan membuat pengoptimalan kepemilikan untuk menjual lebih banyak perangkat kerasnya sendiri. Seperti semua pengoptimalan perangkat keras, Anda harus menggunakan pengoptimalan OpenGL khusus akselerator dengan pemahaman bahwa setiap pengoptimalan untuk satu platform mengurangi portabilitas dan kinerja untuk beberapa platform lainnya. Pengoptimalan Java 3D yang lebih umum sebagian besar bertujuan untuk memaksimalkan portabilitas aplikasi Java 3D.

  • Sementara antarmuka C ke OpenGL ada di mana-mana, antarmuka Java belum distandarisasi dan tidak tersedia secara luas

    Produk Magician Arcane Technologies sampai saat ini berada di pasar untuk mengubah masalah portabilitas ini, tetapi dengan kematiannya banyak cerita lintas platform untuk Java-OpenGL, setidaknya saat ini. Lebih lanjut tentang ini di bawah.

  • Eksposur OpenGL tentang detail bagian dalam dari proses rendering dapat secara signifikan memperumit program grafis 3D sederhana

    Kekuasaan dan fleksibilitas harus dibayar dengan kerumitan. Dalam siklus perkembangan pesat dunia teknologi saat ini, kompleksitas dengan sendirinya merupakan sesuatu yang harus dihindari jika memungkinkan. Pepatah lama tentang bug benar: semakin banyak baris kode, semakin banyak bug (secara umum).

Seperti yang bisa Anda lihat dari pro dan kontra untuk pendekatan berbasis OpenGL, Java-OpenGL kuat di banyak area di mana Java 3D lemah. OpenGL memberi programmer akses tingkat rendah ke proses rendering yang dihindari Java 3D secara eksplisit, dan OpenGL saat ini tersedia di lebih banyak platform daripada Java 3D (selain Magician). Tetapi fleksibilitas ini datang dengan harga potensial: programmer memiliki banyak ruang untuk dioptimalkan, yang sebaliknya berarti mereka memiliki banyak ruang untuk mengacaukan semuanya. Java 3D memiliki lebih banyak pengoptimalan bawaan dan model pemrograman yang lebih mudah yang mungkin terbukti sangat berguna bagi programmer yang baru mengenal Java, pekerjaan grafik 3D, atau pemrograman grafik berjaringan dan terdistribusi.