20 tahun telah berlalu sejak rilis versi 3D pertama KOMPAS - V5.11. Selama waktu ini, kami menyadari bahwa kebutuhan pengguna kami berkembang sesuai dengan kemampuan KOMPAS-3D, seperti halnya fungsi KOMPAS berkembang sesuai dengan kebutuhan pengguna. Hanya satu halangan: membangun bagian teknologi selama bertahun-tahun, kami mengalami masalah produktivitas ketika bekerja dengan proyek-proyek besar yang kompleks. Sekarang garis ini telah diatasi, dan kami siap memberi tahu bagaimana kami berhasil mempercepat KOMPAS-3D di lebih dari 30 operasi dasar.

Kesabaran tidak bisa dipercepat

Bagaimana kita memahami bahwa sudah waktunya untuk "mempercepat"?

Jika 12 tahun yang lalu ada cukup banyak pekerjaan dengan rakitan hingga beberapa ribu komponen, sekarang pengguna KOMPAS ingin melakukan proyek kompleks untuk 300.000 komponen dalam satu rakitan, dan beberapa juta akan sedikit.



Evolusi proyek pengguna KOMPAS-3D: di sebelah kiri Snow milling dan rotor equipment untuk K-700A, K-703MBA traktor , di sebelah kanan Instalasi Steam-Gas PGU-410 MW . Jika sulit dilihat, klik pada gambar.

Di ServiceDesk - dukungan teknis - kami menerima permintaan dengan gaya "Saya tidak bisa membuka pabrik saya di pagi hari" dan "model telah dibuka, tetapi tidak berputar".

Hanya ada satu kesimpulan - COMPAS membutuhkan revisi serius.

Perubahan pertama

Tugas utama adalah meningkatkan kinerja sistem saat bekerja dengan rakitan besar. Dan untuk meningkatkan bukan dengan bersyarat 10-30%, tetapi beberapa kali.

Untuk mengatasi masalah ini, pada 2015 kami membentuk kelompok kerja untuk mempercepat KOMPAS-3D. Semacam regu respon cepat dari programmer, penguji dan analis.

Tim kecepatan kami

BANTUAN: kami telah mengerjakan akselerasi sebelumnya - ini adalah optimalisasi dan fungsi baru yang memungkinkan kami untuk menyelesaikan beberapa masalah saat bekerja dengan rakitan besar. Namun, tugasnya tidak ambisius seperti sekarang, dan pekerjaannya tidak begitu banyak.

Bagaimana Anda memilih kriteria untuk akselerasi?

Kami telah memilih 5 arah untuk akselerasi:

• rendering (rotasi, gerakan, dan pembesaran gambar model),
• menambahkan komponen ke rakitan besar
• pembukaan perakitan
• mengedit di majelis,
• proyeksi.

Saat memilih area ini, kami mengandalkan beberapa sumber:

• pengalaman dan penelitian sendiri,
• analisis permintaan untuk dukungan teknis dan analisis basis kesalahan (dalam alat kami ada label khusus "kinerja", di mana masalah penting untuk kinerja dicatat),
• hasil survei pengguna (pengguna biasanya mengisi kuesioner tersebut di acara ASCON),
• kekuatan yang lebih tinggi .

Di sini kita membahas sesuatu.

Bersama-sama dengan pembentukan kelompok kerja, kami menciptakan ruang informasi kami sendiri - basis pengetahuan - kami menuliskan semua tugas di sana, mengumpulkan dan mensistematisasikan ide-ide dalam bidang akselerasi yang memungkinkan. Akibatnya, persyaratan mulai terbentuk dengan skenario untuk pekerjaan lebih lanjut, berkat itu dimungkinkan untuk mengontrol kinerja.

Aksioma lain yang kami adopsi saat mengerjakan versi ini: produktivitas tidak bisa diambil begitu saja dan diperbaiki, lalu dilupakan. Itu diperlukan untuk mengukur dan mencatat keadaan saat ini, yang darinya kita dapat mengusirnya. Pada saat itu, titik awalnya adalah versi V16 (cerita kami masih tahun 2015), yang perlu dikendalikan oleh skrip dari TK kami. Kinerja beberapa titik kunci dikontrol secara manual, tetapi sekarang proses ini otomatis berkat POI.

Anton Sidyakin, programmer, pemimpin tim:

“Kami mengotomatiskan prosesnya berkat sistem yang diperkenalkan - POI (Points of Interests). Ini adalah tag khusus yang terletak di kode sumber. Menurut mereka, mengeksekusi skrip dalam KOMPAS-3D yang dijelaskan oleh bahasa pengguna, Anda bisa mendapatkan laporan yang dapat dimengerti tidak hanya untuk programmer, tetapi juga untuk analis dengan penguji dan membantu untuk mengetahui apa yang dilakukan KOMPAS-3D pada saat tertentu dan berapa banyak waktu yang dihabiskan untuk itu. Maka informasi ini dapat diproses secara otomatis dan dibandingkan dengan sumber data. "


Hasil pengujian kinerja otomatis. Ngomong-ngomong, siapa yang telah membaca ke tempat ini sekarang tahu bahwa slab KDPV adalah simbol tim akselerator kami. Mereka menganggap kode lambat sebagai kode lambat)

Model apa yang digunakan untuk perbandingan?

Kami memutuskan untuk berkonsentrasi pada model pengguna nyata yang sesuai dengan kriteria "majelis besar."

Basis data model Kompetisi pemodelan 3D Komputer Aces sangat bermanfaat.

Di bawah ini adalah screenshot dari model favorit kami. Tentu saja, ini tidak semua, dan, lebih dari itu, kami yakin bahwa model-model top beberapa tahun terakhir akan segera menjadi akrab dan KOMPAS akan bekerja dengan mereka tidak pada batas, tetapi dalam mode reguler, kecepatan tinggi.

Bis troli	Unit Steam-Gas CCP-410 MW
Gearbox pembangkit listrik kelautan	Instalasi teknologi vakum

Ketika perlu memuat sistem lebih banyak lagi, selain model-model ini, “gado-gado prefabrikasi” yang aneh juga digunakan, misalnya:



Kami juga menggunakan model sintetis: dalam beberapa kasus, masalah tertentu lebih jelas pada mereka dan mereka lebih nyaman digunakan untuk debugging dan pengujian.

Tentang pengembangan dan hasil yang dicapai

Menggambar

Pertama-tama, mereka mencoba mempercepat rendering (ini juga diminta oleh sebagian besar pengguna yang berpartisipasi dalam survei).

Kecepatan rendering sangat penting dalam semua proses di mana model diposisikan atau tampilan berubah. Dan ini bukan hanya rotasi, pergerakan atau zoom model. Kecepatan rendering juga penting dalam proses-proses di mana gambar model diperbarui:

• Menambahkan komponen ke rakitan
• pemilihan objek dasar untuk pasangan (wajah, tepi, dll.),
• menyoroti bagian-bagian tertentu dari model (komponen, wajah),
• mengubah visibilitas objek (sembunyikan / perlihatkan komponen).

Dan ini jauh dari semua kasus di mana subsistem visualisasi digunakan. Oleh karena itu, jelas mengapa rendering akselerasi menjadi prioritas bagi kami.

Pada saat yang sama, penting tidak hanya untuk menggunakan kemampuan kartu video modern yang produktif, tetapi juga tidak melupakan mereka yang menggunakan perangkat keras yang tidak begitu kuat dan modern.

Hasil pekerjaan adalah implementasi dari dua opsi render:

• Basic - Mengaktifkan ekstensi Open GL 2.0. Kurang menuntut kinerja kartu video. Memberikan akselerasi rendering yang baik,
• "Peningkatan" - menggunakan ekstensi modern OpenGL 4.5. Menuntut karakteristik kartu video. Memberikan akselerasi rendering maksimum pada peta modern

Yuri Korchagin, programmer:

“Dalam masalah kinerja menampilkan adegan besar, jelas bahwa banyak sumber daya dihabiskan untuk berkeliling adegan dan menghitung parameter dengan mana primitif harus ditampilkan.

Masalah lain terkait dengan sejumlah besar panggilan draw (panggilan ke OpenGL API, yang mengarah pada output geometri ke buffer frame).

Keadaan awal juga mengasumsikan transfer semua data ke kartu video dari RAM. Dan ini adalah jutaan segitiga dalam kasus majelis besar.

Koreksi kosmetik tidak dapat diberikan di sini, karena diperlukan peningkatan beberapa kali dalam produktivitas. Oleh karena itu, diputuskan untuk menulis ulang sebagian besar modul visualisasi.

Langkah pertama adalah menggunakan memori video untuk cache menggambar data (triangulasi, gambar rangka, wajah). Dengan memindahkan data ini ke GPU, kami berhasil mendapatkan peningkatan FPS 2-3 kali lipat.

Ini diikuti oleh pembuatan model data yang disesuaikan untuk visualisasi. Artinya, kami menyingkirkan permintaan untuk model 3D, yang dapat menjadi sumber daya yang cukup intensif, yang juga memberikan efek positif.

Langkah selanjutnya adalah mempelajari kualitas dan volume triangulasi. Seringkali detail kecil ditampilkan dengan akurasi berlebihan, dan sebaliknya - dalam situasi tertentu, alih-alih permukaan yang halus, pengguna melihat model "cincang" di layar.

Kami memutuskan untuk menggunakan beberapa level detail dan menerapkan perkiraan primitif dengan mempertimbangkan deviasi sudut. Dengan cara ini, dua burung dengan satu batu terbunuh: mereka meningkatkan kualitas dan menghilangkan beban berlebih pada GPU. "

Yuri Korchagin, programmer:

“Yah, menampilkan model menjadi lebih cepat, tetapi tidak sebanyak yang kita inginkan. Pada tahap ini, kami menyadari bahwa kami tidak bisa mendapatkan lebih banyak dari pendekatan ini.

Di sisi lain, penggunaan pendekatan terbaru akan memerlukan kartu video paling mutakhir, yang bertentangan dengan persyaratan kompatibilitas dan beberapa pengguna jelas tidak akan menyukainya. Oleh karena itu, perbaikan yang dijelaskan di atas telah tersedia sebagai opsi render "Dasar".

Dan kemudian kesenangan dimulai ... "

Pada bagian selanjutnya, kami melanjutkan kisah kami tentang rendering, dan juga menunjukkan hasil pengukuran kecepatan rendering selama rotasi perakitan, perhitungan MTC, menambahkan komponen ke perakitan, dan memberi tahu tentang penampilan tipe beban parsial.

Dan untuk hidangan penutup, mereka meninggalkan video untuk Anda membandingkan kecepatan rendering selama rotasi, penskalaan dan pergeseran Reducer dari pembangkit listrik tenaga laut.



Akhir dari bagian pertama. Untuk dilanjutkan .