Apa saja perpustakaan vektor / matriks C ++ vektor / matriks C ++ yang paling banyak digunakan, dan pengorbanan biaya dan manfaatnya? [Tutup]


242

Tampaknya banyak proyek perlahan-lahan datang pada kebutuhan untuk melakukan matematika matriks, dan jatuh ke dalam perangkap pertama membangun beberapa kelas vektor dan perlahan-lahan menambahkan fungsionalitas sampai mereka tertangkap membangun perpustakaan aljabar linier kustom setengah-assed, dan tergantung padanya.

Saya ingin menghindari itu sementara tidak membangun ketergantungan pada beberapa pustaka yang berhubungan secara tangensial (misalnya OpenCV, OpenSceneGraph).

Apa perpustakaan matriks matematika / aljabar linear yang umum digunakan di luar sana, dan mengapa memutuskan untuk menggunakan satu sama lain? Adakah yang disarankan untuk tidak menggunakan karena suatu alasan? Saya secara khusus menggunakan ini dalam konteks geometris / waktu * (2,3,4 Dim) * tetapi mungkin menggunakan data dimensi yang lebih tinggi di masa depan.

Saya mencari perbedaan berkenaan dengan: API, kecepatan, penggunaan memori, luasnya / kelengkapan, kesempitan / kekhususan, ekstensibilitas, dan / atau kematangan / stabilitas.

Memperbarui

Saya akhirnya menggunakan Eigen3 yang sangat saya sukai.


2
Karena Anda menyebutkan OSG dan OpenCV, saya kira Anda hanya perlu jenis vektor grafis 3D / matriks, yaitu: matriks 3x3 dan 4x4. Saya mendasarkan jawaban saya untuk itu, tetapi Anda mungkin ingin menentukan bagaimana tepatnya Anda menggunakan ini - apakah Anda perlu pemecahan matriks? Matriks matematika dimensi yang lebih tinggi? dll
Reed Copsey

Saat ini saya hanya melakukan hal-hal berbasis geometri 2D, tetapi secara hipotesis Anda kadang-kadang membutuhkan operasi 3x3 pada data 2D, dan tidak jelas apakah data 3D dan operasi 4x4 mungkin diperlukan. Kami ingin menggunakan perpustakaan umum di seluruh perusahaan. Saya tidak memiliki akal yang baik untuk apa timbal baliknya. Lebih umum akan lebih baik, tetapi berapa biayanya.
Catskul

1
Jika Anda hanya melakukan transformasi geometris, saya sangat merekomendasikan melihat GGT, seperti yang saya sebutkan dalam jawaban saya. Ini sangat lengkap untuk itu, tetapi benar-benar tidak melakukan apa-apa TETAPI itu, jadi itu pilihan yang sangat bersih dan mudah. BLAS dan LAPACK lebih untuk solusi matriks kompleks doign (yaitu: 50x50 matriks, matriks jarang, dll) untuk ilmiah dan matematika, bukan transformasi geometris.
Reed Copsey

Jawaban:


114

Ada beberapa proyek yang telah diselesaikan pada Generic Graphics Toolkit untuk ini. GMTL di sana bagus - cukup kecil, sangat fungsional, dan telah digunakan cukup luas untuk menjadi sangat andal. OpenSG, VRJuggler, dan proyek lain semuanya telah beralih untuk menggunakan ini alih-alih matematika matriks / matriks lintingan tangan mereka sendiri.

Saya merasa cukup bagus - ia melakukan semuanya melalui templat, jadi sangat fleksibel, dan sangat cepat.


Edit:

Setelah diskusi komentar, dan pengeditan, saya pikir saya akan membuang lebih banyak informasi tentang manfaat dan kerugian untuk implementasi tertentu, dan mengapa Anda dapat memilih satu dari yang lain, mengingat situasi Anda.

GMTL -

Manfaat: API Sederhana, dirancang khusus untuk mesin grafis. Termasuk banyak tipe primitif yang ditujukan untuk rendering (seperti pesawat, AABB, quatenrions dengan banyak interpolasi, dll) yang tidak ada dalam paket lain. Memori overhead sangat rendah, cukup cepat, mudah digunakan.

Kelemahan: API sangat fokus khusus pada rendering dan grafik. Tidak termasuk matriks tujuan umum (NxM), dekomposisi dan penyelesaian matriks, dll, karena ini berada di luar ranah aplikasi grafik / geometri tradisional.

Eigen -

Manfaat: Bersihkan API , cukup mudah digunakan. Termasuk modul Geometri dengan angka empat dan transformasi geometris. Overhead memori rendah. Pemecahan penuh, sangat berkinerja tinggi dari matriks NxN besar dan rutinitas matematika tujuan umum lainnya.

Kerugian: Mungkin ruang lingkup sedikit lebih besar daripada yang Anda inginkan (?). Lebih sedikit geometris / render rutinitas khusus bila dibandingkan dengan GMTL (yaitu: definisi sudut Euler, dll).

IMSL -

Manfaat: Perpustakaan numerik yang sangat lengkap. Sangat, sangat cepat (konon pemecah tercepat). Sejauh ini, API matematika terbesar dan terlengkap. Didukung secara komersial, dewasa, dan stabil.

Kelemahan: Biaya - tidak murah. Sangat sedikit metode khusus geometris / render, jadi Anda harus menggulirkan Anda sendiri di atas kelas aljabar linier mereka.

NT2 -

Manfaat: Menyediakan sintaks yang lebih akrab jika Anda terbiasa dengan MATLAB. Memberikan dekomposisi dan penyelesaian penuh untuk matriks besar, dll.

Kelemahan: Matematika, tidak fokus rendering. Mungkin tidak sebagus Eigen.

LAPACK -

Manfaat: Sangat stabil, algoritma terbukti. Sudah ada sejak lama. Pemecahan matriks lengkap, dll. Banyak pilihan untuk matematika tidak jelas.

Kelemahan: Tidak terlalu berkinerja tinggi dalam beberapa kasus. Porting dari Fortran, dengan API ganjil untuk penggunaan.

Secara pribadi, bagi saya, hanya ada satu pertanyaan - bagaimana Anda berencana untuk menggunakan ini. Jika Anda fokus hanya pada rendering dan grafik, saya suka Generic Graphics Toolkit , karena kinerjanya baik, dan mendukung banyak operasi rendering yang berguna di luar kotak tanpa harus menerapkan sendiri. Jika Anda memerlukan penyelesaian matriks tujuan umum (yaitu: dekomposisi SVD atau LU dari matriks besar), saya akan menggunakan Eigen , karena ia menangani itu, menyediakan beberapa operasi geometris, dan sangat performan dengan solusi matriks besar. Anda mungkin perlu menulis lebih banyak dari grafik / operasi geometrik Anda sendiri (di atas matriks / vektor), tetapi itu tidak mengerikan.


Apakah Anda mengevaluasi perpustakaan lain sebelum memutuskan GMTL? Perbandingan dangkal membuat saya percaya bahwa Eigen lebih baik didukung, tetapi itu atas dasar meninjau situs web masing-masing. Apakah Anda mengetahui adanya keunggulan spesifik satu di atas yang lain?
Catskul

Eigen juga bekerja dengan baik. Itu belum matang pada saat saya melakukan penyelidikan, tetapi saya percaya itu akan menjadi pilihan yang baik pada saat ini. GMTL telah digunakan secara luas, dan sangat matang dan solid ketika saya memutuskan untuk menggunakannya.
Reed Copsey

Saya kira untuk menjawab pertanyaan saya sampai ke pokok permasalahan: Apakah Anda membuat pilihan Anda secara subyektif seperti "Ini terlihat lebih baik" atau di mana ada fitur spesifik (api, kecepatan, penggunaan memori, luasnya, sempitnya, dapat diperpanjang) yang membuat perbedaan. Saya kira jatuh tempo jatuh di bawah kriteria ini, tetapi jika jatuh tempo adalah satu-satunya metrik, saya pikir Anda akan memilih opsi berbasis BLAS atau LAPACK.
Catskul

Saya memilih ini setelah mencoba beberapa opsi, dan mendasarkannya: kinerja, kegunaan, dan overhead waktu runtime / kompilasi rendah. Eigen terlihat jauh lebih baik sekarang daripada saat itu, jadi saya tidak bisa menilai di antara mereka. Namun, saya sangat senang dengan GMTL untuk penggunaan kami.
Reed Copsey,

Itu bagian dari mengapa saya suka GMTL, dan menggunakannya. Hanya terasa sangat alami untuk digunakan, dan sangat, sangat mudah untuk dikerjakan. Ini juga mendukung semua yang saya butuhkan, dalam hal ini, karena saya hanya khawatir tentang penanganan langsung transformasi geometris dan rotasi angka empat.
Reed Copsey

38

Jadi saya orang yang cukup kritis, dan saya pikir jika saya akan berinvestasi di perpustakaan, saya lebih baik tahu apa yang saya hadapi. Saya pikir lebih baik bersikap terlalu keras pada kritik dan menyanjung pujian ketika meneliti; apa yang salah dengannya memiliki lebih banyak implikasi untuk masa depan daripada apa yang benar. Jadi saya akan pergi ke sini sedikit untuk memberikan jenis jawaban yang akan membantu saya dan saya harap akan membantu orang lain yang mungkin menempuh jalan ini. Perlu diingat bahwa ini didasarkan pada sedikit ulasan / pengujian yang telah saya lakukan dengan lib ini. Oh dan saya mencuri beberapa deskripsi positif dari Reed.

Saya akan menyebutkan di bagian atas bahwa saya menggunakan GMTL meskipun ada keistimewaan karena ketidakpercayaan Eigen2 terlalu besar untuk downside. Tapi saya baru-baru ini belajar bahwa rilis Eigen2 berikutnya akan berisi definisi yang akan mematikan kode penyelarasan, dan membuatnya aman. Jadi saya bisa beralih.

Pembaruan : Saya sudah beralih ke Eigen3. Terlepas dari kekhasannya, ruang lingkup dan keanggunannya terlalu sulit untuk diabaikan, dan optimisasi yang membuatnya tidak aman dapat dimatikan dengan definisi.

Eigen2 / Eigen3

Manfaat: LGPL MPL2, Bersih, API yang dirancang dengan baik, cukup mudah digunakan. Tampaknya terawat dengan baik dengan komunitas yang dinamis. Overhead memori rendah. Performa tinggi. Dibuat untuk aljabar linear umum, tetapi fungsionalitas geometris yang baik juga tersedia. Semua header lib, tidak perlu menautkan.

Idiocyncracies / downsides: (Beberapa / semua ini dapat dihindari dengan beberapa definisi yang tersedia di cabang pengembangan Eigen3 saat ini)

  • Optimalisasi kinerja yang tidak aman mengakibatkan perlu mengikuti aturan dengan cermat. Tidak mengikuti aturan menyebabkan macet.
    • Anda tidak bisa dengan aman melewati nilai
    • penggunaan tipe Eigen karena anggota memerlukan penyesuaian pengalokasi khusus (atau Anda mogok)
    • gunakan dengan tipe wadah stl dan mungkin template lain diperlukan penyesuaian alokasi khusus (atau Anda akan macet)
    • kompiler tertentu perlu perawatan khusus untuk mencegah crash pada panggilan fungsi (GCC windows)

GMTL

Manfaat: LGPL, API Cukup Sederhana, dirancang khusus untuk mesin grafis. Termasuk banyak tipe primitif yang ditujukan untuk rendering (seperti pesawat, AABB, quatenrions dengan banyak interpolasi, dll) yang tidak ada dalam paket lain. Memori overhead sangat rendah, cukup cepat, mudah digunakan. Semua berbasis tajuk, tidak perlu tautan.

Idiocyncracies / downsides:

  • API itu unik
    • apa yang mungkin myVec.x () di lib lain hanya tersedia melalui myVec [0] (masalah Keterbacaan)
      • sebuah array atau stl :: vector of points dapat menyebabkan Anda melakukan sesuatu seperti pointsList [0] [0] untuk mengakses komponen x dari poin pertama
    • dalam upaya naif pada optimasi, menghapus silang (vec, vec) dan diganti dengan makeCross (vec, vec, vec) ketika kompiler menghilangkan temps yang tidak perlu pula
    • operasi matematika normal tidak mengembalikan tipe normal kecuali Anda mematikan beberapa fitur optimisasi misalnya: vec1 - vec2tidak mengembalikan vektor normal sehingga length( vecA - vecB )gagal meskipun vecC = vecA - vecBberfungsi. Anda harus membungkus seperti:length( Vec( vecA - vecB ) )
    • operasi pada vektor disediakan oleh fungsi eksternal daripada anggota. Ini mungkin mengharuskan Anda untuk menggunakan resolusi lingkup di mana-mana karena nama simbol umum dapat bertabrakan
    • Anda harus melakukan
        length( makeCross( vecA, vecB ) )
      atau di
        gmtl::length( gmtl::makeCross( vecA, vecB ) )
      mana jika tidak, Anda dapat mencoba
        vecA.cross( vecB ).length()
  • tidak terawat dengan baik
    • masih diklaim sebagai "beta"
    • dokumentasi kehilangan informasi dasar seperti header mana yang diperlukan untuk menggunakan fungsionalitas normal
      • Vec.h tidak mengandung operasi untuk Vektor, VecOps.h berisi beberapa, yang lain ada di Generate.h misalnya. cross (vec &, vec &, vec &) di VecOps.h, [make] cross (vec &, vec &) di Generate.h
  • API yang belum matang / tidak stabil; masih berubah.
    • Misalnya "cross" telah berpindah dari "VecOps.h" ke "Generate.h", dan kemudian namanya diubah menjadi "makeCross". Contoh dokumentasi gagal karena masih merujuk ke versi fungsi lama yang sudah tidak ada lagi.

NT2

Tidak tahu karena mereka lebih tertarik pada header gambar fraktal dari halaman web mereka daripada kontennya. Tampak lebih seperti proyek akademik daripada proyek perangkat lunak yang serius.

Rilis terbaru lebih dari 2 tahun yang lalu.

Rupanya tidak ada dokumentasi dalam bahasa Inggris meskipun konon ada sesuatu dalam bahasa Prancis.

Tidak dapat menemukan jejak komunitas di sekitar proyek.

LAPACK & BLAS

Manfaat: Tua dan dewasa.

Kerugian:

  • tua seperti dinosaurus dengan API yang benar-benar jelek

1
Mengenai Eigen aligned menegaskan: untuk mendapatkan kinerja tinggi dari operasi SSE (1,2,3 atau 4) untuk set kecil data, Anda benar-benar membutuhkan data yang selaras. Operasi beban / toko yang tidak selaras jauh lebih lambat. Keputusan antara pemuatan / penyimpanan yang selaras atau tidak selaras juga membutuhkan waktu. Setiap implementasi "tujuan umum" akan memiliki waktu yang sangat sulit untuk melakukan hal yang benar untuk semua orang, kecuali jika mereka memisahkan antarmuka menjadi operasi yang "selaras" dan "tidak selaras" - dan sekali lagi itu bukan tujuan yang sangat umum.
Joris Timmermans

@Catskul Saya ingin menggunakan Eigen3. Bisakah Anda memperluas "optimisasi yang membuatnya tidak aman dapat dimatikan dengan definisi"? Masalah lain yang Anda daftarkan di bawah Eigen2 dirinci dengan cermat dalam dokumen di bawah Topik yang terkait dengan masalah penyelarasan . Saya bisa hidup dengan masalah ini.
Ali

Masalah dengan keselamatan yang saya maksudkan adalah semua penyelarasan terkait dan sama dari Eigen2. Jika Anda setuju dengan Eigen2, Anda akan baik-baik saja dengan Eigen3.
Catskul

2
BLAS dan LAPACK sebenarnya bukan perpustakaan, tetapi spesifikasi / API. Anda bisa menyebutkan implementasi awal mereka oleh netlib atau implementasi lain seperti ATLAS dan OpenBLAS.
Isi

12

Untuk apa nilainya, saya sudah mencoba Eigen dan Armadillo. Di bawah ini adalah evaluasi singkat.

Keuntungan Eigen: 1. Benar-benar mandiri - tidak ada ketergantungan pada BLAS atau LAPACK eksternal. 2. Dokumentasi yang layak. 3. Konon cepat, meskipun saya belum mengujinya.

Kerugian: Algoritma QR mengembalikan hanya satu matriks tunggal, dengan matriks R tertanam di segitiga atas. Tidak tahu dari mana sisa matriks berasal, dan tidak ada matriks Q yang dapat diakses.

Keuntungan Armadillo: 1. Berbagai dekomposisi dan fungsi lainnya (termasuk QR). 2. Cukup cepat (menggunakan templat ekspresi), tetapi sekali lagi, saya belum benar-benar mendorongnya ke dimensi tinggi.

Kekurangan: 1. Tergantung pada BLAS eksternal dan / atau LAPACK untuk dekomposisi matriks. 2. Dokumentasi kurang IMHO (termasuk spesifik wrt LAPACK, selain mengubah pernyataan #define).

Akan menyenangkan jika perpustakaan open source tersedia yang mandiri dan mudah digunakan. Saya telah mengalami masalah yang sama selama 10 tahun, dan itu membuat frustrasi. Pada satu titik, saya menggunakan GSL untuk C dan menulis pembungkus C ++ di sekitarnya, tetapi dengan C ++ modern - terutama menggunakan keunggulan templat ekspresi - kita tidak harus macam-macam dengan C di abad ke-21. Hanya tuppencehapenny saya.


2
Armadillo memiliki sintaks mirip Matlab yang disengaja, sehingga mudah digunakan. Saya tidak yakin apa yang Anda maksud tentang "dokumentasi kurang ... spesifik wrt LAPACK". Dokumentasi dengan jelas mendokumentasikan semua fungsi yang tersedia pengguna, bersama dengan contoh bagaimana menggunakannya. Seluruh poin tentang pustaka pembungkus C ++ adalah untuk mengabstraksi kompleksitas dan verbositas LAPACK. Anda selalu dapat menelusuri sumber jika ingin melihat bagaimana Armadillo memanggil LAPACK.
mtall

Tentang dekomposisi QR di Eigen, maksud Anda Eigen2 atau Eigen3?
qed

11

Jika Anda mencari matriks / aljabar linier / optimasi kinerja tinggi pada prosesor Intel, saya akan melihat perpustakaan MKL Intel.

MKL dioptimalkan dengan cermat untuk kinerja run-time yang cepat - sebagian besar didasarkan pada standar fortran BLAS / LAPACK yang sangat matang. Dan kinerjanya berskala dengan jumlah core yang tersedia. Skalabilitas hands-free dengan core yang tersedia adalah masa depan komputasi dan saya tidak akan menggunakan perpustakaan matematika untuk proyek baru yang tidak mendukung prosesor multi-core.

Sangat singkat, itu termasuk:

  1. Operasi vektor-vektor, vektor-matriks, dan matriks-dasar
  2. Matriks faktorisasi (penguraian LU, hermitian, jarang)
  3. Masalah fitting squares dan nilai eigen terendah
  4. Pemecah sistem linier yang jarang
  5. Non-linear least square solver (wilayah kepercayaan)
  6. Ditambah rutinitas pemrosesan sinyal seperti FFT dan konvolusi
  7. Generator angka acak yang sangat cepat (mersenne twist)
  8. Banyak lagi .... lihat: tautan teks

Kelemahannya adalah bahwa API MKL bisa sangat kompleks tergantung pada rutinitas yang Anda butuhkan. Anda juga dapat melihat pustaka IPP (Integrated Performance Primitives) mereka yang disesuaikan dengan operasi pemrosesan gambar berkinerja tinggi, tetapi bagaimanapun juga cukup luas.

Paul

Perangkat Lunak CenterSpace, perpustakaan .NET Math, Centerspace.net


8

Saya pernah mendengar hal-hal baik tentang Eigen dan NT2 , tetapi belum secara pribadi digunakan. Ada juga Boost.UBLAS , yang saya percaya agak lama di gigi. Para pengembang NT2 sedang membangun versi berikutnya dengan maksud untuk meningkatkannya, sehingga mungkin ada gunanya.

Lin saya. alg. kebutuhan tidak diperluas melampaui kasus matriks 4x4, jadi saya tidak bisa mengomentari fungsionalitas canggih; Saya hanya menunjukkan beberapa opsi.


Dalam pengalaman saya (matriks yang lebih besar), Boost.UBLAS lebih banyak digunakan. Namun, ketika saya melihat ke dalamnya, saya tidak menyukainya (terutama karena dokumentasi) jadi saya berkonsentrasi pada Eigen. Eigen memiliki modul geometri , tapi saya belum menggunakannya sendiri.
Jitse Niesen

Eigen tampaknya digunakan oleh ROS (garasi willow), Celestia, Koffice, dan libmv. Saya melihat beberapa obrolan tentang UBLAS, tetapi mengalami kesulitan menemukan proyek yang beriklan menggunakannya. Ditto untuk NT2. Bisakah Anda menguraikan hal-hal baik apa yang telah Anda dengar?
Catskul

Itu dalam sebuah diskusi di mailing list Boost tentang menambahkan perpustakaan LinAlg modern ke Boost - Eigen dan NT2 keduanya disebut sebagai kandidat yang mungkin, tetapi hanya pengembang NT2 yang menyatakan minat untuk mengejarnya. Kedua perpustakaan itu tampak layak; seperti yang Anda katakan, Eigen sedikit lebih populer, dan juga lebih C ++ - ish; NT2 dirancang untuk meniru MATLAB sebanyak mungkin.
Jeff Hardy

8

Saya baru mengenal topik ini, jadi saya tidak bisa mengatakan banyak, tetapi BLAS cukup standar dalam komputasi ilmiah. BLAS sebenarnya merupakan standar API, yang memiliki banyak implementasi. Sejujurnya saya tidak yakin implementasi mana yang paling populer atau mengapa.

Jika Anda ingin juga dapat melakukan operasi aljabar linear umum (sistem penyelesaian, regresi kuadrat terkecil, dekomposisi, dll.) Lihatlah ke dalam LAPACK .


7

Bagaimana dengan GLM ?

Ini didasarkan pada spesifikasi OpenGL Shading Language (GLSL) dan dirilis di bawah lisensi MIT. Jelas ditujukan untuk programmer grafis


baik, ini menyediakan vektor dan matriks pemrograman grafis. itu memperkenalkan jumlah overhead yang bagus untuk tetap mematuhi GLSL (jika Anda dapat melakukannya di GLSL, sebagian besar melakukannya di GLSL lebih baik terutama dengan GL 4.x), dan kehilangan banyak primitif pemrograman grafis (frustum, AABB, BB, ellipsoid ). Antarmuka yang bergelombang itu mengalami obesitas. Alternatif yang jauh lebih baik adalah jika ia memiliki fungsi ".xyzz ()" yang dihasilkan dengan beberapa pembuatan kode. Ini sempurna ketika Anda harus membuat prototipe aplikasi terbuka dan mulai menunjukkan sisi negatifnya pada proyek yang lebih besar. jangan pernah kode perpustakaan matematika.
CoffeDeveloper

5

Saya akan menambahkan suara untuk Eigen: Saya mem-porting banyak kode (geometri 3D, aljabar linier dan persamaan diferensial) dari pustaka yang berbeda ke yang satu ini - meningkatkan kinerja dan keterbacaan kode di hampir semua kasus.

Satu keuntungan yang tidak disebutkan: sangat mudah untuk menggunakan SSE dengan Eigen, yang secara signifikan meningkatkan kinerja operasi 2D-3D (di mana semuanya dapat diisi hingga 128 bit).


1
Seluruh "jika Anda melakukan ini maka pastikan untuk ..." sesuatu menurut saya sedikit bendera merah. Sejauh ini saya sudah dua kali mengalami masalah ini dan saya baru mulai menggunakannya. Saya benar-benar berharap untuk tidak membebani pengembang di masa depan karena mengetahui semua jenis keanehan dari masing-masing perpustakaan termasuk: khususnya masalah penyelarasan di mana ia mogok jika Anda tidak menggunakan makro tertentu setiap kali Anda memiliki anggota, dan fakta bahwa mereka telah menyebar fungsionalitas untuk masing-masing kelas di beberapa header. Sendiri mungkin tidak mencegah saya memilihnya, tetapi itu dikirim sedikit bendera merah.
Catskul

1
Penyelarasan dan makro itu hanya penting jika Anda menggunakan SSE, yang sama sekali tidak diperlukan. Dan jika Anda menggunakan SIMD, masalah-masalah itu akan memunculkan perpustakaan apa pun yang Anda gunakan. Setidaknya Eigen tidak hanya crash, tetapi menyediakan pesan kesalahan yang bermakna yang langsung mengarah ke masalah.
ima

Dan ada cara mudah untuk menghindari penyelarasan makro - gunakan pointer atau referensi sebagai anggota.
ima

1
Saya rasa itu tidak benar. Saya tidak menggunakan opsi SSE khusus dan mendapatkan beberapa crash setelah menggunakannya dengan wadah stl. Ya saya tahu itu memberi Anda pesan yang membantu, dan Ya saya tahu ada instruksi khusus, tapi itu maksud saya. Saya tidak ingin membebani pengembang lain dengan instruksi khusus untuk setiap perpustakaan yang disertakan. Hal jangan lewat nilai misalnya terlalu banyak.
Catskul

Saya baru tahu bahwa cabang pengembangan terbaru memiliki beberapa definisi yang dapat Anda gunakan untuk mematikan perataan dan menghindari masalah terkait.
Catskul

4

Oke, saya pikir saya tahu apa yang Anda cari. Tampaknya GGT adalah solusi yang cukup bagus, seperti yang disarankan Reed Copsey.

Secara pribadi, kami menggulung perpustakaan kecil kami sendiri, karena kami sering berurusan dengan poin-poin rasional - banyak NURBS dan Beziers yang rasional.

Ternyata sebagian besar pustaka grafik 3D melakukan perhitungan dengan titik-titik projektif yang tidak memiliki dasar dalam matematika projektif, karena itulah yang memberi Anda jawaban yang Anda inginkan. Kami akhirnya menggunakan poin Grassmann, yang memiliki fondasi teoritis yang kuat dan mengurangi jumlah jenis poin. Poin Grassmann pada dasarnya adalah perhitungan yang sama yang digunakan orang sekarang, dengan manfaat teori yang kuat. Yang paling penting, ini membuat segalanya lebih jelas dalam pikiran kita, jadi kita memiliki lebih sedikit bug. Ron Goldman menulis makalah tentang poin-poin Grassmann dalam grafik komputer yang disebut "On the Algebraic and Geometric Foundations of Computer Graphics" .

Tidak terkait langsung dengan pertanyaan Anda, tetapi bacaan yang menarik.


Sengaja terbuka karena saya tidak tahu apa kompromi itu. Mungkin adil untuk mengatakan bahwa geometri adalah perhatian utama kita, dimensi geometri tidak jelas. Saat ini 2/3 (2 + waktu) dan secara hipotesis bisa sangat tinggi (3dims + waktu + multi-dim-costmaps).
Catskul

Saya setuju dengan pertanyaan itu. Sebagai contoh, banyak aplikasi semacam ini membutuhkan kinerja waktu nyata (perilaku waktu konsisten), sementara banyak yang lain dengan baik menyerahkan konsistensi dan / atau kecepatan untuk akurasi.
TED

Jadi, apakah Anda mengatakan bahwa dari perpustakaan yang Anda selidiki, tidak ada yang mengurus NURBS dan Beziers? Adakah alasan khusus untuk tidak mengambil salah satu perpustakaan yang ada dan membangun dukungan NURBS dan Bezier di sampingnya?
Catskul

Apa yang saya coba katakan adalah bahwa NURBS dan Beziers rasional menggunakan titik kontrol rasional lebih dari kebanyakan aplikasi 3d, jadi kami membuat lebih banyak kesalahan. Biasanya sebagian besar aplikasi 3d hanya memiliki vanilla 3d points dan vektor sampai setelah melalui transformasi perspektif. Banyak algoritma kami harus mampu benar menangani tertimbang / poin rasional / proyektif dan Cartesian, akan bolak-balik, dll
tfinniga


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.