Halaman ini menjelaskan masalah kinerja umum dan praktik terbaik untuk mengatasinya.
Komputasi skrip
Operasi mahal di kode Luau membutuhkan lebih lama untuk diproses dan dapat mempengaruhi tingkat frame.Kecuali dieksekusi secara paralel, kode Luau dijalankan secara sinkron dan memblokir thread utama sampai menemukan fungsi yang menghasilkan thread.
Masalah umum
Operasi intensif pada struktur tabel - Operasi kompleks seperti serialisasi, deserialisasi, dan kloning mendalam menghasilkan biaya kinerja tinggi, terutama pada struktur tabel besar.Ini terutama berlaku jika operasi ini recursif atau melibatkan iterasi atas struktur data yang sangat besar.
Acara frekuensi tinggi - Mengikat operasi mahal ke acara berbasis frame dari RunService tanpa membatasi frekuensi artinya operasi ini diulang setiap frame, yang sering menyebabkan peningkatan tidak perlu dalam waktu komputasi.Peristiwa ini termasuk:
Peredaman
- Memanggil kode pada RunService peristiwa secara hemat, membatasi penggunaan untuk kasus di mana invokasi frekuensi tinggi diperlukan (misalnya, memperbarui kamera).Anda dapat mengeksekusi sebagian besar kode lain di acara lain atau lebih jarang dalam satu loop.
- Hancurkan tugas besar atau mahal menggunakan task.wait() untuk menyebarkan pekerjaan di beberapa frame.
- Identifikasi dan optimalkan operasi yang tidak perlu mahal dan gunakan multithreading untuk tugas yang mahal secara komputasional yang tidak perlu mengakses model data.
- Beberapa skrip sisi server dapat mengambil manfaat dari pembuatan kode asli, bendera sederhana yang mengompilasi skrip ke kode mesin daripada bytecode.
Scope MicroProfiler
Skop | Hitungan terkait |
RunService.PreRender | Kode dieksekusi pada acara PreRender |
RunService.PreSimulation | Kode dieksekusi pada acara Langkah |
RunService.PostSimulation | Kode dieksekusi pada acara Heartbeat |
Jalankan Layanan.Heartbeat | Kode dieksekusi pada acara Heartbeat |
Untuk informasi lebih lanjut tentang debugging skrip menggunakan MicroProfiler, lihat perpustakaan debug , yang berisi fungsi untuk menandai kode tertentu dan meningkatkan spesifikasi lebih lanjut, seperti debug.profilebegin dan debug.profileend.Banyak metode API Roblox yang dipanggil oleh skrip juga memiliki tag MicroProfiler terkait sendiri yang dapat memberikan sinyal berguna.
Penggunaan memori skrip
Bocoran memori dapat terjadi ketika Anda menulis skrip yang mengkonsumsi memori yang tidak dapat dilepaskan dengan benar oleh pengumpul sampah ketika tidak lagi digunakan.Bocoran secara khusus menyebar di server, karena mereka dapat terus online selama banyak hari, sementara sesi klien jauh lebih pendek.
Nilai memori berikut di Konsol Pengembang dapat menunjukkan masalah yang perlu diteliti lebih lanjut:
- LuaHeap - Konsumsi tinggi atau berkembang menunjukkan kebocoran memori.
- InstanceCount - Secara konsisten meningkatkan jumlah instansi menunjukkan referensi ke beberapa instansi dalam kode Anda tidak dikumpulkan sampah.
- Memori Skrip Tempat - Memberikan skrip oleh pemecahan skrip penggunaan memori.
Masalah umum
Meninggalkan koneksi terhubung - Mesin tidak pernah mengumpulkan sampah acara yang terhubung ke instans dan semua nilai yang disebutkan di dalam panggilan balik terhubung.Oleh karena itu, koneksi aktif acara dan kode di dalam instans terhubung, fungsi terhubung, dan nilai referensi, berada di luar cakupan untuk pengumpul sampah memori, bahkan setelah peristiwa ditembak.
Meskipun acara terputus ketika instansi yang mereka miliki hancur, kesalahan umum adalah menganggap ini berlaku untuk Player objek.Setelah pengguna meninggalkan pengalaman, mesin tidak secara otomatis menghancurkan objek dan model karakter perwakilan mereka, sehingga koneksi ke objek dan instansi di bawah model karakter, seperti , masih mengkonsumsi memori jika Anda tidak memutuskannya di skrip Anda.Ini dapat menyebabkan kebocoran memori yang sangat signifikan dari waktu ke waktu di server ketika ratusan pengguna bergabung dan meninggalkan pengalaman.
Tabel - Menyisipkan objek ke tabel tetapi tidak menghapusnya saat mereka tidak lagi dibutuhkan menyebabkan konsumsi memori yang tidak perlu, terutama untuk tabel yang melacak data pengguna saat mereka bergabung.Sebagai contoh, sampel kode berikut membuat tabel menambahkan informasi pengguna setiap kali pengguna bergabung:
Contohlocal playerInfo = {}Players.PlayerAdded:Connect(function(player)playerInfo[player] = {} -- beberapa informasiend)Jika Anda tidak menghapus entri ini ketika mereka tidak lagi dibutuhkan, tabel terus tumbuh dalam ukuran dan mengkonsumsi lebih banyak memori saat lebih banyak pengguna bergabung dengan sesi.Kode apa pun yang mengulangi atas tabel ini juga menjadi lebih mahal secara komputasional saat tabel tumbuh dalam ukuran.
Peredaman
Untuk membersihkan semua nilai yang digunakan untuk mencegah kebocoran memori:
Putuskan semua koneksi - Pergi melalui basis kode Anda pastikan setiap koneksi dibersihkan melalui salah satu jalur berikut:
- Memutus secara manual menggunakan fungsi Disconnect().
- Menghancurkan instansi yang peristiwa milik dengan fungsi Destroy() .
- Menghancurkan objek skrip yang jejak koneksinya kembali ke.
Hapus objek dan karakter pemain setelah meninggalkan - Terapkan kode untuk memastikan tidak ada koneksi yang bertahan setelah pengguna meninggalkan, seperti dalam contoh berikut:
ContohPlayers.PlayerAdded:Connect(function(player)player.CharacterRemoving:Connect(function(character)task.defer(character.Destroy, character)end)end)Players.PlayerRemoving:Connect(function(player)task.defer(player.Destroy, player)end)
Kalkulasi fisika
Simulasi fisika berlebihan dapat menjadi penyebab utama peningkatan waktu komputasi per frame di server dan klien.
Masalah umum
Frekuensi langkah fisika berlebih - Secara default, perilaku melangkah berada di mode adaptif , di mana langkah fisika pada 60 Hz, 120 Hz, atau 240 Hz, tergantung pada kompleksitas mekanisme fisika.
Mode tetap dengan akurasi fisika yang ditingkatkan juga tersedia, yang memaksa semua assemblasi fisika untuk melangkah pada 240 Hz (empat kali per frame).Ini menghasilkan lebih banyak perhitungan setiap frame.
Terlalu banyak kompleksitas objek simulasi - Semakin banyak 3D assemblies yang disimulasikan, semakin lama perhitungan fisika mengambil setiap frame.Seringkali, pengalaman akan memiliki objek yang disimulasikan yang tidak perlu atau akan memiliki mekanisme yang memiliki lebih banyak batasan dan persatuan daripada yang mereka butuhkan.
Deteksi tabrakan yang terlalu akurat - Bagian mesh memiliki properti CollisionFidelity untuk mendeteksi tabrakan yang menawarkan berbagai mode dengan berbagai tingkat dampak kinerja.Mode deteksi tabrakan tepat untuk bagian mesh memiliki biaya kinerja paling mahal dan membutuhkan waktu lebih lama untuk menghitung mesin.
Peredaman
Bagian pengait yang tidak memerlukan simulasi - Pengait semua bagian yang tidak perlu dipengaruhi oleh fisika, seperti untuk NPC statis.
Gunakan langkah fisika adaptif - Langkah adaptif secara dinamis menyesuaikan tingkat perhitungan fisika untuk mekanisme fisika, memungkinkan pembaruan fisika dilakukan lebih jarang dalam beberapa kasus.
Kurangi kompleksitas mekanisme * Jika memungkinkan, minimalisir jumlah batasan fisika atau persambungan dalam sebuah kumpulan.
- Kurangi jumlah tabrakan diri dalam mekanisme, seperti dengan menerapkan batas atau keterbatasan tabrakan untuk anggota ragdoll untuk mencegah mereka bertabrakan satu sama lain.
Kurangi penggunaan akurasi tabrakan presisi untuk meshes * Untuk objek kecil atau tidak interaktif di mana pengguna jarang memperhatikan perbedaan, gunakan kesetiaan kotak.
Untuk objek ukuran kecil hingga sedang, gunakan kotak atau keloyalan hull, tergantung pada bentuk.
Untuk objek besar dan sangat kompleks, buat kolisi khusus menggunakan bagian tak terlihat saat memungkinkan.
Untuk objek yang tidak memerlukan tabrakan, nonaktifkan tabrakan dan gunakan keandalan kotak atau hull, karena geometri tabrakan masih disimpan di memori.
Anda dapat menampilkan geometri tabrakan untuk tujuan debug di Studio dengan menyalakan keandalan tabrakan dari widget opsi visualisasi di sudut kanan atas tampilan 3D.
Alternatifnya, Anda dapat menerapkan filter CollisionFidelity = Precise ke Explorer yang menunjukkan jumlah semua bagian mesh dengan ketepatan yang tepat dan memungkinkan Anda dengan mudah memilihnya.
Untuk panduan mendalam tentang cara memilih opsi keandalan kolisi yang seimbang dengan persyaratan akurasi dan kinerja Anda, lihat Atur parameter fisika dan rendering.
Scope MicroProfiler
Skop | Hitungan terkait |
fisikaStepped | Kalkulasi fisika keseluruhan |
langkah dunia | Langkah fisika diskrit diambil setiap frame |
Penggunaan memori fisika
Gerakan fisika dan deteksi tabrakan mengkonsumsi memori.Bagian mesh memiliki properti CollisionFidelity yang menentukan pendekatan yang digunakan untuk mengevaluasi batas tabrakan mesh.
Masalah umum
Mode deteksi tabrakan default dan akurat mengkonsumsi memori signifikan lebih banyak daripada dua mode lain dengan bentuk tabrakan kesetiaan yang lebih rendah.
Jika Anda melihat tingkat konsumsi memori yang tinggi di bawah PhysicsParts , Anda mungkin perlu mengeksplorasi mengurangi keandalan kolisi dari objek dalam pengalaman Anda.
Cara mengatasi
Untuk mengurangi memori yang digunakan untuk keandalan kolisi:
- Untuk bagian yang tidak memerlukan tabrakan, nonaktifkan tabrakan mereka dengan mengatur BasePart.CanCollide , BasePart.CanTouch dan BasePart.CanQuery ke false .
- Kurangi kesetiaan tabrakan menggunakan pengaturan CollisionFidelity. Box memiliki overhead memori terendah, dan Default dan Precise umumnya lebih mahal.
- Umumnya aman untuk menetapkan keandalan tabrakan bagian terikat kecil apa pun ke Box.
- Untuk meshes besar yang sangat kompleks, Anda mungkin ingin membangun meshes tabrakan Anda sendiri dari objek yang lebih kecil dengan keakuratan tabrakan kotak.
Manusiawi
Humanoid adalah kelas yang menyediakan berbagai fungsi untuk karakter pemain dan non pemain (NPC).Meskipun kuat, Humanoid datang dengan biaya komputasi yang signifikan.
Masalah umum
- Meninggalkan semua HumanoidStateTypes diaktifkan pada NPC - Ada biaya kinerja untuk meninggalkan tertentu HumanoidStateTypes diaktifkan.Nonaktifkan apa pun yang tidak diperlukan untuk NPC Anda.Sebagai contoh, kecuali NPC Anda akan naik tangga, aman untuk menonaktifkan status Climbing .
- Menginstansiasi, memodifikasi, dan menghidupkan kembali model dengan Humanoids sering * Ini bisa intensif untuk mesin untuk diproses, terutama jika model ini menggunakan pakaian berlapis .Ini juga bisa menjadi sangat bermasalah dalam pengalaman di mana avatar sering respawn.
- Di dalam MicroProfiler , tag panjang updateInvalidatedFastClusters (lebih dari 4 ms) sering menjadi sinyal bahwa instansiasi/modifikasi avatar memicu invalidasi berlebihan.
- Menggunakan Humanoids dalam kasus di mana mereka tidak diperlukan - NPC statis yang tidak bergerak umumnya tidak membutuhkan kelas Humanoid.
- Memainkan animasi pada banyak NPC dari server - Animasi NPC yang dijalankan di server perlu disimulasikan di server dan direplikasi ke klien.Ini bisa menjadi biaya overhead yang tidak perlu.
Peredaman
- Mainkan animasi NPC di klien - Dalam pengalaman dengan jumlah besar NPC, pertimbangkan untuk membuat Animator di klien dan menjalankan animasi secara lokal.Ini mengurangi beban pada server dan kebutuhan untuk replikasi tidak perlu.Ini juga membuat optimisasi tambahan menjadi mungkin (seperti hanya memutar animasi untuk NPC yang berada dekat dengan karakter).
- Gunakan alternatif ramah kinerja untuk Humanoids - Model NPC tidak perlu tentu saja berisi objek humanoid.
- Untuk NPC statis, gunakan sederhana AnimationController, karena mereka tidak perlu bergerak tetapi hanya perlu memainkan animasi.
- Untuk memindahkan NPC, pertimbangkan untuk menerapkan kontrol gerakan Anda sendiri dan menggunakan AnimationController untuk animasi, tergantung pada kompleksitas NPC Anda.
- Nonaktifkan status humanoid yang tidak digunakan - Gunakan Humanoid:SetStateEnabled() untuk hanya mengaktifkan status yang diperlukan untuk setiap humanoid
- Model NPC kolam dengan respawning sering - Alih-alih menghancurkan NPC sepenuhnya, kirim NPC ke kolam NPC yang tidak aktif.Dengan cara ini, ketika NPC baru diperlukan untuk respawn, Anda dapat hanya mengaktifkan kembali salah satu NPC dari kolam.Proses ini disebut kolam, yang meminimalisir jumlah kali karakter perlu diinstansikan.
- Hanya menelurkan NPC saat pengguna berada di dekatnya - Jangan menelurkan NPC saat pengguna tidak berada dalam jangkauan, dan hapus mereka saat pengguna meninggalkan jangkauannya.
- Hindari membuat perubahan pada hierarki avatar setelah diinstansiasikan - Beberapa modifikasi pada hierarki avatar memiliki implikasi kinerja yang signifikan.Beberapa optimisasi tersedia:
- Untuk animasi prosedural khusus, jangan perbarui properti JointInstance.C0 dan JointInstance.C1 . Sebagai gantinya, perbarui properti Motor6D.Transform .
- Jika Anda perlu menempelkan objek BasePart apa pun ke avatar, lakukan di luar hierarki avatar Model .
Scope MicroProfiler
Skop | Hitungan terkait |
stepHumanoid | Kontrol humanoid dan fisika |
animasi langkah | Humanoid dan animasi animator |
perbarui cluster FastTidak Valid | Terkait dengan menginstansi atau memodifikasi avatar |
Rendering
Sebagian besar waktu yang dihabiskan klien untuk setiap frame adalah untuk menyajikan adegan di frame saat ini.Server tidak melakukan rendering apa pun, jadi bagian ini eksklusif untuk klien.
Membuat panggilan Draw
Panggilan serah adalah serangkaian instruksi dari mesin ke GPU untuk menampilkan sesuatu.Panggilan menggambar memiliki overhead yang signifikan.Secara umum, semakin sedikit panggilan seret per frame, semakin sedikit waktu komputasi yang dihabiskan untuk menyajikan frame.
Anda dapat melihat berapa banyak panggilan serah yang saat ini terjadi dengan item Render Statistik > Waktu di Studio.Anda dapat melihat Render Statistik di klien dengan menekan .
Semakin banyak objek yang perlu ditarik di adegan Anda dalam frame tertentu, semakin banyak panggilan ditarik ke GPU.Namun, Mesin Roblox menggunakan proses yang disebut instansiasi untuk melipatgandakan meshes identik dengan karakteristik tekstur yang sama ke dalam satu panggilan serah.Secara khusus, beberapa meshes dengan sama MeshId di tangani dalam satu panggilan menggambar ketika:
- Bahan identik ketika kedua SurfaceAppearance dan MeshPart.TextureID tidak ada.
Masalah umum lainnya
Konsentrasi objek berlebih - Jika banyak objek dikonsentrasikan dengan konsentrasi tinggi, maka rendering area adegan ini membutuhkan lebih banyak panggilan gambar.Jika Anda menemukan tingkat bingkai Anda turun saat melihat bagian tertentu dari peta, ini bisa menjadi sinyal yang baik bahwa kepadatan objek di area ini terlalu tinggi.
Objek seperti stiker, teks, dan partikel tidak batch dengan baik dan memperkenalkan panggilan menggambar tambahan.Berikan perhatian ekstra pada jenis objek ini di adegan.Secara khusus, perubahan properti ke ParticleEmitters dapat memiliki dampak dramatis pada kinerja.
Peluang instansi yang terlewatkan - Seringkali, adegan akan mencakup mesh yang sama diulang beberapa kali, tetapi setiap salinan mesh memiliki ID aset mesh atau tekstur yang berbeda.Ini mencegah instansi dan dapat menyebabkan panggilan tarik yang tidak perlu.
Penyebab umum dari masalah ini adalah ketika seluruh adegan diimpor sekaligus, bukan aset individu yang diimpor ke Roblox dan kemudian diulang setelah diimpor untuk mengumpulkan adegan.
Kompleksitas objek berlebihan - Meskipun tidak sepenting jumlah panggilan serah, jumlah segi di sebuah adegan mempengaruhi berapa lama waktu yang dibutuhkan untuk menampilkan frame.Adegan dengan jumlah mesh yang sangat besar dan sangat kompleks adalah masalah umum, seperti adegan dengan set properti MeshPart.RenderFidelity ke Enum.RenderFidelity.Precise di terlalu banyak mesh.
Pencadangan bayangan berlebihan - Penanganan bayangan adalah proses mahal, dan peta yang berisi jumlah dan kepadatan cahaya yang tinggi yang melemparkan bayangan (atau jumlah dan kepadatan bagian kecil yang dipengaruhi oleh bayangan) kemungkinan memiliki masalah kinerja.
Penarikan transparansi tinggi - Menempatkan objek dengan transparansi parsial di dekat satu sama lain memaksa mesin untuk menampilkan piksel tumpangan berkali-kali, yang dapat mempengaruhi kinerja.Untuk informasi lebih lanjut tentang mengidentifikasi dan memperbaiki masalah ini, lihat Hapus transparansi bertingkat.
Peredaman
- Menginstansi meshes identik dan mengurangi jumlah meshes unik - Jika Anda memastikan semua meshes identik memiliki ID aset dasar yang sama, mesin dapat mengenali dan menampilkannya dalam satu panggilan menggambar.Pastikan untuk hanya mengunggah setiap mesh di peta sekali dan kemudian menyalinnya di Studio untuk digunakan kembali daripada mengimpor peta besar secara keseluruhan, yang dapat menyebabkan meshes identik memiliki ID konten yang berbeda dan diakui sebagai aset unik oleh mesin.Paket adalah mekanisme berguna untuk penggunaan ulang objek.
- Penyaringan - Penyaringan menggambarkan proses menghapus panggilan serah untuk objek yang tidak masuk ke dalam frame terakhir yang drender.Secara default, mesin melewati panggilan menggambar untuk objek di luar bidang pandang kamera (pengumpulan frustum), tetapi tidak melewati panggilan menggambar untuk objek yang terhalang dari pandangan oleh objek lain (pengumpulan penutupan).Jika adegan Anda memiliki banyak panggilan serah, pertimbangkan untuk menerapkan penyaringan tambahan sendiri saat runtime secara dinamis untuk setiap frame, seperti menerapkan strategi umum berikut:
- Untuk lingkungan dalam ruangan, implementasikan sistem kamar atau portal yang menyembunyikan objek yang saat ini tidak ditempati oleh pengguna mana pun.
- Mengurangi ketepatan rendering - Tetapkan ketepatan rendering ke Otomatis atau Kinerja .Ini memungkinkan meshes untuk jatuh kembali ke alternatif yang kurang kompleks, yang dapat mengurangi jumlah poligon yang perlu ditarik.
- Menonaktifkan pencastan bayangan pada bagian dan objek cahaya yang tepat - Kompleksitas bayangan dalam adegan dapat dikurangi dengan menonaktifkan properti pencastan bayangan secara selektif pada objek cahaya dan bagian.Ini dapat dilakukan saat编辑时 atau dinamis saat runtime.Beberapa contoh adalah:
Gunakan properti BasePart.CastShadow untuk menonaktifkan pencastan bayangan pada bagian kecil di mana bayangan tidak mungkin terlihat.Ini bisa sangat efektif ketika hanya diterapkan pada bagian yang jauh dari kamera pengguna.
Nonaktifkan bayangan pada objek bergerak saat memungkinkan.
Nonaktifkan Light.Shadows pada instans ringan di mana objek tidak perlu melemparkan bayangan.
Membatasi jangkauan dan sudut instansi cahaya.
Gunakan lebih sedikit instansi cahaya.
Scope MicroProfiler
Skop | Hitungan terkait |
Siapkan dan Lakukan | Rendering keseluruhan |
Lakukan/Adegan/ computeLightingPerform | Pembaruan grid ringan dan bayangan |
LightGridCPU | Pembaruan grid cahaya Voxel |
Sistem Peta Bayangan | Pemetaan bayangan |
Lakukan/Adegan/UpdateView | Persiapan untuk rendering dan pembaruan partikel |
Lakukan/Adegan/RenderView | Rendering dan post-processing |
Jaringan dan replikasi
Jaringan dan replikasi menggambarkan proses di mana data dikirim antara server dan klien terhubung.Informasi dikirim antara klien dan server setiap frame, tetapi jumlah informasi yang lebih besar membutuhkan lebih banyak waktu komputasi.
Masalah umum
Lalu lintas remote berlebihan - Mengirim sejumlah besar data melalui RemoteEvent atau RemoteFunction atau memanggilnya sangat sering dapat menyebabkan banyak waktu CPU yang dihabiskan untuk memproses paket masuk setiap frame.Kesalahan umum termasuk:
- Mengulangi data setiap frame yang tidak perlu direplikasi.
- Mengulangi data pada input pengguna tanpa mekanisme untuk membatasnya.
- Mengirim lebih banyak data daripada yang diperlukan.Sebagai contoh, mengirim seluruh inventaris pemain saat mereka membeli barang daripada hanya rincian barang yang dibeli.
Penciptaan atau penghapusan pohon instansi kompleks - Ketika perubahan dilakukan pada model data di server, itu direplikasi ke klien yang terhubung.Ini berarti membuat dan menghancurkan hierarki instans besar seperti peta pada saat eksekusi bisa sangat intensif jaringan.
Penyerang umum di sini adalah data animasi kompleks yang disimpan oleh plugin Editor Animasi di rig.Jika ini tidak dihapus sebelum permainan dipublikasikan dan model animasi diklon secara teratur, sejumlah besar data akan direplikasi tidak perlu.
Layanan Tween di Sisi Server - Jika TweenService digunakan untuk menyelingkan server sisi objek, properti yang diselingkan dipindahkan ke setiap klien setiap frame.Tidak hanya ini menyebabkan remaja gelisah karena latensi klien berfluktuasi, tetapi menyebabkan banyak lalu lintas jaringan yang tidak perlu.
Peredaman
Anda dapat menggunakan taktik berikut untuk mengurangi replikasi yang tidak perlu:
- Hindari mengirim banyak data sekaligus melalui acara remote .Sebagai gantinya, hanya kirim data yang diperlukan pada frekuensi yang lebih rendah.Sebagai contoh, untuk status karakter, salin ketika berubah daripada setiap frame.
- Memotong pohon instansi kompleks seperti peta dan memuatnya dalam potongan untuk mendistribusikan pekerjaan mereplikasi ini di banyak frame.
- Bersihkan metadata animasi , terutama direktori animasi rig, setelah diimpor.
- Batasi replikasi instansi tidak perlu , terutama dalam kasus di mana server tidak perlu memiliki pengetahuan tentang instansi yang dibuat.Ini termasuk:
- Efek visual seperti ledakan atau ledakan mantra sihir.Server hanya perlu tahu lokasi untuk menentukan hasil, sementara klien dapat membuat visual secara lokal.
- Model pandangan item orang pertama.
- Objek remaja di klien daripada server.
Scope MicroProfiler
Skop | Hitungan terkait |
Paket Proses | Memproses paket jaringan masuk, seperti panggilan acara dan perubahan properti |
Menyediakan Bandwidth dan Menjalankan Pengirim | Peristiwa keluar yang relevan di server |
Penggunaan memori aset
Mekanisme dampak tertinggi yang tersedia untuk pencipta untuk meningkatkan penggunaan memori klien adalah mengaktifkan streaming instansi .
Streaming instansi
streaming instansial memuat secara selektif bagian model data yang tidak diperlukan, yang dapat menyebabkan waktu beban menurun secara signifikan dan meningkatkan kemampuan klien untuk mencegah kecelakaan saat berada di bawah tekanan memori.
Jika Anda mengalami masalah memori dan streaming instansi dinonaktifkan, pertimbangkan untuk memperbarui pengalaman Anda untuk mendukungnya, terutama jika dunia 3D Anda besar.Streaming instansi didasarkan pada jarak di ruang 3D, jadi dunia yang lebih besar secara alami mendapat manfaat lebih dari itu.
Jika streaming instansi diaktifkan, Anda dapat meningkatkan agresivitasnya. Misalnya, pertimbangkan:
- Mengurangi penggunaan persisten StreamingIntegrity .
- Mengurangi radius streaming .
Untuk informasi lebih lanjut tentang opsi streaming dan manfaatnya, lihat Properti streaming.
Masalah umum lainnya
- Duplikasi aset - Kesalahan umum adalah mengunggah aset yang sama beberapa kali dengan hasil berbeda ID aset.Ini dapat menyebabkan konten yang sama dimuat ke memori beberapa kali.
- Volume aset yang berlebihan - Bahkan ketika aset tidak identik, ada kasus ketika peluang untuk menggunakan kembali aset yang sama dan menghemat memori terlewatkan.
- File audio - File audio dapat menjadi kontributor mengejutkan untuk penggunaan memori, terutama jika Anda memuat semuanya ke klien sekaligus bukan hanya memuat apa yang Anda butuhkan untuk sebagian pengalaman.Untuk strategi, lihat Waktu pemuatan.
- Tekstur resolusi tinggi - Konsumsi memori grafis untuk sebuah teks tidak terkait dengan ukuran teks di disk, tetapi lebih dari jumlah piksel di teks.
- Sebagai contoh, tekstur piksel 1024x1024 mengkonsumsi empat kali memori grafis dari teksur 512x512.
- Gambar yang diunggah ke Roblox diterjemahkan ke format tetap, jadi tidak ada manfaat memori untuk mengunggah gambar dalam model warna yang terkait dengan kurang dari satu byte per piksel.Demikian pula, kompresi gambar sebelum mengunggah atau menghapus saluran alfa dari gambar yang tidak membutuhkannya dapat mengurangi ukuran gambar di disk, tetapi tidak meningkatkan atau hanya sedikit meningkatkan penggunaan memori.Meskipun mesin secara otomatis menurunkan resolusi tekstur pada beberapa perangkat, tingkat penurunan tergantung pada karakteristik perangkat, dan resolusi tekstur berlebihan masih dapat menyebabkan masalah.
- Anda dapat mengidentifikasi konsumsi memori grafis untuk tekstur tertentu dengan memperluas kategori GrafikTexture di Konsol Pengembang .
Peredaman
- Hanya mengunggah aset sekali - Gunakan kembali ID aset yang sama di antara objek dan pastikan aset yang sama, terutama mesh dan gambar, tidak diunggah secara terpisah beberapa kali.
- Temukan dan perbaiki aset duplikat - Cari bagian dan tekstur mesh identik yang diunggah beberapa kali dengan ID yang berbeda.
- Meskipun tidak ada API untuk mendeteksi kemiripan aset secara otomatis, Anda dapat mengumpulkan semua ID aset gambar di tempat Anda (baik secara manual atau dengan skrip), downloadnya, dan bandingkan dengan alat perbandingan eksternal.
- Untuk bagian mesh, strategi terbaik adalah mengambil ID mesh unik dan mengatur mereka berdasarkan ukuran untuk secara manual mengidentifikasi duplikat.
- Alih-alih menggunakan teksur terpisah untuk warna yang berbeda, unggah teksur tunggal dan gunakan properti SurfaceAppearance.Color untuk menerapkan berbagai warna kepadanya.
- Impor aset di peta secara terpisah - Daripada mengimpor seluruh peta sekaligus, impor dan rekonstruksi aset di peta secara individual dan rekonstruksi mereka.Importer 3D tidak melakukan de-duplikasi meshes, jadi jika Anda harus mengimpor peta besar dengan banyak ubin lantai terpisah, masing-masing ubin akan diimpor sebagai aset terpisah (walaupun itu duplikat).Ini dapat menyebabkan masalah kinerja dan memori di sepanjang garis, karena setiap mesh diperlakukan secara individual dan mengambil memori dan memanggil panggilan.
- Batasi piksel gambar tidak lebih dari jumlah yang diperlukan.Kecuali gambar mengisi banyak ruang fisik di layar, biasanya membutuhkan maksimal 512x512 piksel.Kebanyakan gambar minor harus lebih kecil dari 256x256 piksel.
- Gunakan lembar pemotong untuk memastikan penggunaan ulang tekstur maksimum di peta 3D.Untuk langkah dan contoh tentang cara membuat lembar pemotong, lihat Buat lembar pemotong.
Waktu pemuatan
Banyak pengalaman menerapkan layar pemuatan khusus dan menggunakan metode ContentProvider:PreloadAsync() untuk meminta aset sehingga gambar, suara, dan meshes diunduh di latar belakang.
Keuntungan dari pendekatan ini adalah Anda dapat memastikan bagian penting dari pengalaman Anda sepenuhnya dimuat tanpa pop-in.Namun, kesalahan umum adalah overmenggunakan metode ini untuk pra-memuat lebih banyak aset daripada yang sebenarnya dibutuhkan.
Contoh praktik buruk adalah memuat seluruh Workspace . Meskipun ini dapat mencegah pop-in tekstur, ini secara signifikan meningkatkan waktu pemuatan.
Sebagai gantinya, hanya gunakan ContentProvider:PreloadAsync() di situasi yang diperlukan, yang termasuk:
- Gambar di layar pemuatan.
- Gambar penting di menu pengalaman Anda, seperti latar belakang tombol dan ikon.
- Aset penting di area mulai atau spawning.
Jika Anda harus memuat banyak aset, kami sarankan Anda memberikan tombol Lewati Pemuatan .