Meningkatkan Kinerja

*Konten ini diterjemahkan menggunakan AI (Beta) dan mungkin mengandung kesalahan. Untuk melihat halaman ini dalam bahasa Inggris, klik di sini.

Halaman ini menjelaskan masalah kinerja umum dan praktik terbaik untuk mengatasi mereka.

Menghitung Skrip

Operasi mahal dalam kode Lua memakan waktu lebih lama untuk diproses dan dapat meng影响 beri ratingframe sehingga dapat mengkompensasi tingkat tread sehingga dapat mengkompensasi tingkat tread sehingga dapat mengkompensasi tingkat tread.

Masalah Umum

  • Operasi intensif pada struktur tabel - Operasi kompleks seperti serialisasi, deserialisasi, dan kloning dalam jumlah besar menghasilkan biaya performa tinggi, terutama pada tabel besar. Ini berlaku terutama jika operasi ini recursive atau melibatkan iterating over very large data structures.

  • Acara frekuensi tinggi - Menghubungkan operasi mahal ke acara-basis frame dari RunService tanpa membatasi frekuensi berarti operasi ini diulang setiap frame, yang sering menyebabkan peningkatan waktu pemrosesan yang tidak perlu. Acara ini termasuk:

Mitigasi

  • Panggil kode di RunService acara dengan hati-hati, mengurangi penggunaan ke kasus di mana panggilan frekuensi tinggi penting (seperti mengaktualisasi kamera). Anda dapat mengeksekusi sebagian besar kode lain dalam acara lain atau kurang sering dalam satu loop.
  • Pecahkan tugas besar atau mahal menggunakan task.wait() untuk menyebarkan pekerjaan ke banyak frame.
  • Identifikasi dan optimalkan operasi yang tidak perlu mahal dan gunakan multithreading untuk tugas-tugas yang tidak perlu mengakses model data.
  • Beberapa script sisi server dapat menguntungkan dari Pembuatan Kode Panggilan Alami, flag sederhana yang mengkompilasi script menjadi kode mesin daripada kode byte.

MicroProfiler Mata

PenglihatanKomputasi Bersama
JalankanService.PreRenderKode berjalan pada acara PreRender
JalankanService.PreSimulationKode berjalan pada acara Stepped
JalankanService.PostSimulationKode berjalan pada acara Heartbeat
JalankanService.HeartbeatKode berjalan pada acara Heartbeat

Untuk informasi lebih lanjut tentang debugging script menggunakan MicroProfiler, lihat debug library, yang termasuk fungsi untuk menandai kode spesifik dan meningkatkan khususnya, seperti debug.profilebegin dan debug.profileend . Banyak metode API Roblox yang dipanggil oleh script juga memiliki label

Penggunaan Memori Skrip

Kecurangan memori dapat terjadi ketika Anda menulis skrip yang menggunakan memori yang pengumpul sampah tidak dapat melepaskan dengan benar saat tidak lagi digunakan. Kecurangan khususnya merupakan pervasive di server, karena mereka dapat terus online selama bertahun-tahun, sementara sesi klien jauh lebih pendek.

Berikut nilai memori dalam Developer Console dapat menunjukkan masalah yang perlu penyelidikan lebih lanjut:

  • LuaHeap - Konsumsi tinggi atau meningkat menunjukkan kebocoran memori.
  • JumlahInstansi - Secara konsisten menumbuhkan jumlah instansi menunjukkan referensi ke beberapa instansi di kode Anda tidak diumparkan.
  • TempatScriptMemory - Memberikan skrip dengan penjelasan runtut dari penggunaan memori.

Masalah Umum

  • Meninggalkan koneksi terhubung - Mesin tidak pernah menumpukkan acara yang terhubung ke instans dan setiap nilai yang di참조 di dalam panggilan terhubung. Oleh karena itu, koneksi aktif dari acara dan kode di dalam koneksi terhubung, fungsi terhubung, dan nilai yang di참조, tidak masuk dalam rentang pengumpulan sampah memori, bahkan setelah acara diaktifkan.

    Meskipun acara terputus saat instans yang mereka miliki dihancurkan, kesalahan umum adalah menganggap bahwa ini berlaku untuk Player objek. Setelah seorang pengguna meningg

  • Tabel-tabel - Menambahkan objek ke tabel tetapi tidak menghapusnya saat mereka tidak lagi dibutuhkan menyebabkan penggunaan memori yang tidak diperlukan, terutama untuk tabel yang melacak data pengguna saat mereka bergabung. Misalnya, contoh kode berikut menambahkan tabel menambahkan informasi pengguna setiap kali seorang pengguna bergabung:

    Contoh

    local playerInfo = {}
    Players.PlayerAdded:Connect(function(player)
    playerInfo[player] = {} -- beberapa info
    end)

    Jika Anda tidak menghapus entri ini saat mereka tidak lagi diperlukan, tabel terus tumbuh dalam ukuran dan mengkonsumsi lebih banyak memori saat lebih banyak pengguna bergabung dengan sesi. Setiap kode yang berulang di atas tabel juga menjadi lebih mahal secara konsentrasi saat tabel tumbuh dalam ukuran.

Mitigasi

Untuk membersihkan semua nilai yang digunakan untuk mencegah kebocoran memori:

  • Terputuskan semua koneksi - Pergi melalui basis kode Anda pastikan setiap koneksi dibersihkan melalui salah satu dari jalan berikut:

    • Terputus secara manual menggunakan fungsi Disconnect()
    • Menghancurkan instans di mana acara berada dengan fungsi Destroy() .
    • Menghancurkan objek skrip yang koneksi menunjuk kembali.
  • Hapus objek pemain dan karakter setelah meninggalkan - Gunakan kode untuk memastikan tidak ada koneksi yang tersisa setelah seorang pengguna meninggalkan, seperti dalam contoh berikut:

    Contoh

    Players.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)

Menghitung Fisika

Simulasi fisika yang berlebihan dapat menjadi penyebab utama waktu pemrosesan per frame yang lebih lama di server dan klien.

Masalah Umum

  • Frekuensi waktu fisika berlebihan - Secara default, frekuensi tahap perilaku ditentukan dalam mode adaptif, di mana tahap fisika berlangsung di 60 Hz, 120 Hz, atau 240 Hz, tergantung pada kompleksitas mekanisme fisika.

    Mode tetap dengan ketepatan fisika yang ditingkatkan juga tersedia, yang memaksa semua assemblei fisika untuk berlangkah 240 Hz (empat kali per frame). Ini menghasilkan komputasi yang lebih banyak per frame.

  • Jumlah eksesif kompleksitas objek simulasi - Semakin banyak 3D assemblies yang simulasi, semakin lama pemotretan fisika mengambil setiap frame. Biasanya, pengalaman akan memiliki objek yang simulasi yang tidak perlu atau akan memiliki mekanisme yang memiliki lebih banyak batas dan join daripada yang mereka butuhkan.

  • Terdeteksi terlalu tepat pendeteksi tabrakan - Mesh bagian memiliki propperti CollisionFidelity untuk mendeteksi tabrakan yang menawarkan berbagai mode dengan tingkat performa yang berbeda. Mode deteksi tabrakan精确 untuk bagian meshes memiliki biaya performa paling mahal dan memakan waktu lebih lama untuk menghitung.

Mitigasi

  • Tautkan bagian yang tidak memerlukan simulasi - Tautkan semua bagian yang tidak perlu diaktifkan oleh fisika, seperti untuk NPC statis.

  • Gunakan adaptive physics stepping. - Adopsi dynamis menyesuaikan tingkat perhitungan fisika untuk mekanik fisika, memungkinkan perbaruan fisika kurang sering dalam beberapa kasus.

  • Kurangi kompleksitas mekanisme * Di mana mungkin, minimalkan jumlah batasan fisika atau rakitan dalam sebuahAssembly.

    • Kurangi jumlah tabrakan diri dalam mekanisme, seperti dengan menerapkan batas atau kendala non-tabrakan untuk menghalang ranting tabrakan satu sama lain.
  • Kurangi keakuratan persentase kecelakaan yang tepat untuk meshes * Untuk objek kecil atau tidak dapat berinteraksi di mana pengguna jarang perhatikan perbedaannya, gunakan kesetelan kotak.

    • Untuk objek ukuran kecil-sedang, gunakan kotak atau kuali fidelitas, tergantung pada bentuknya.

    • Untuk objek besar dan sangat kompleks, bangun tabrakan khusus menggunakan bagian yang tidak terlihat saat mungkin.

    • Untuk objek yang tidak memerlukan tabrakan, nonaktifkan tabrakan, dan gunakan ketelitian ruang atau hull, karena geometri tabrakan masih tersimpan dalam memori.

    • Anda dapat menyederkan geometri tabrakan untuk tujuan debug di Studio dengan menyalakan Kesesuaian tabrakan dari widget Opsi Visualisasi di sudut atas kanan 3D viewport.

      Alternatifnya, Anda dapat menerapkan filter CollisionFidelity = Precise ke Explorer yang menunjukkan jumlah semua bagian mesh dengan keakuratan tinggi dan memungkinkan Anda dengan mudah memilih mereka.

    • Untuk jalan melintasi yang dalam tentang cara memilih opsi keakuratan tabrakan yang menyeimbangkan persyaratan keakuratan dan kinerja Anda, lihat Tetapkan Fisika dan Rendering Parameter.

MicroProfiler Mata

PenglihatanKomputasi Bersama
fisikaPerhitungan fisika secara keseluruhan
langkah duniaLangkah fisika terpisah diambil setiap frame

Penggunaan Memori Fisika

Gerakan dan deteksi tabrakan fisika mengkonsumsi memori. Mesh part memiliki CollisionFidelity property yang menentukan tindakan yang digunakan untuk mengevaluasi batas-batas kolisi mesin.

Masalah Umum

Mode deteksi tabrakan default dan tepat mengkonsumsi lebih banyak memori daripada dua mode lainnya dengan bentuk tabrakan kesesuaian yang lebih rendah.

Jika Anda melihat tingkat konsumsi memori yang tinggi di bawah PhysicsParts , Anda mungkin perlu menjelajahi mengurangi keakuratan kolisi objek dalam pengalaman Anda.

Cara Menghindari

Untuk mengurangi memori yang digunakan untuk keakuratan kolisi:

  • Untuk bagian yang tidak memerlukan kolisi, nonaktifkan kolisi mereka dengan menetapkan BasePart.CanCollide, BasePart.CanTouch dan BasePart.CanQuery ke 2> false2> .
  • Kurangi ketelitian tabrakan menggunakan pengaturan CollisionFidelity . Box memiliki over memory terendah, dan Default dan 1> Enum.CollisionFidel
    • Biasanya aman untuk menetapkan keselamatan persaingan bagian kecil yang terancam ke Box .
    • Untuk meshes besar yang sangat kompleks, Anda mungkin ingin membangun meshes kebijakan sendiri dari objek yang lebih kecil dengan kualitas kolisi kotak.

Manusia

Humanoid adalah kelas yang memberikan berbagai fungsionalitas kepada pemain dan karakter non-pemain (NPC). Meskipun kuat, sebuah Humanoid datang dengan biaya perhitungan yang signifikan.

Masalah Umum

  • Menyisihkan semua HumanoidStateTypes diaktifkan di NPCs - Ada biaya kinerja untuk meninggalkan beberapa HumanoidStateTypes yang diaktifkan. Nonaktifkan apa pun yang tidak diperlukan untuk NPC Anda. Misalnya, kecuali jika NPC Anda tidak akan menaiki tangga, itu aman untuk men
  • Menginstansiasikan, mengubah, dan mengrespawn model dengan Humanoid secara teratur * Ini dapat intensif untuk mesin untuk memproses, terutama jika model ini menggunakan Pakaian berlapis-lapis . Ini juga dapat menjadi masalah khusus dalam pengalaman di mana avatar sering respawn.
    • Dalam MicroProfiler , panjang updateInvalidatedFastClusters tag (lebih dari 4 ms) sering merupakan sinyal bahwa instialisasi avatar/modifikasi mengaktifkan validasi yang berlebihan.
  • Menggunakan Humanoid dalam kasus di mana mereka tidak diperlukan - NPC statis yang tidak bergerak umumnya tidak memerlukan kelas Humanoid .
  • Bermain animasi pada banyak NPC dari server - Animasi NPC yang berjalan di server perlu disimulasikan di server dan dikirim ke klien. Ini mungkin tidak perlu over头.

Mitigasi

  • Mainkan animasi NPC di klien - Dalam pengalaman dengan banyak NPC, pertimbangkan untuk membuat Animator di klien dan mengeksekusi animasi secara lokal. Ini mengurangi beban di server dan kebutuhan untuk pemutaran yang tidak diperlukan. Ini juga memungkinkan optimisasi tambahan (seperti hanya memutar animasi untuk NPC yang
  • Gunakan alternatif yang ramah performa untuk Humanoid. - Model NPC tidak harus selalu berisi objek humanoid.
    • Untuk NPC statis, gunakan AnimationController, karena mereka tidak perlu bergerak tetapi hanya perlu memainkan animasi.
    • Untuk NPC yang bergerak, pertimbangkan menerapkan kontrol gerakan Anda sendiri dan menggunakan AnimationController untuk animasi, tergantung pada kompleksitas NPC Anda.
  • Nonaktifkan negara-negara manusia yang tidak digunakan - Gunakan Humanoid:SetStateEnabled() untuk hanya mengaktifkan negara-negara yang diperlukan untuk setiap manusia.
  • Model NPC kolam renang dengan respawning yang sering - Alih-alih menghancurkan NPC sepenuhnya, kirim NPC ke kolam renang NPC yang tidak aktif. Dengan cara ini, ketika NPC baru dibutuhkan untuk respawn, Anda hanya dapat mengaktifkan salah satu dari NPC dari kolam. Proses ini disebut kolam, yang mengurangi jumlah waktu yang dibut
  • Hanya spawn NPC saat pengguna berada di dekatnya - Jangan spawn NPC saat pengguna tidak berada dalam jangkauan, dan cull mereka saat pengguna meninggalkan jangkauan mereka.
  • Hindari membuat perubahan pada hierarki avatar setelah diinstansikan. - Beberapa modifikasi pada hierarki avatar memiliki implikasi kinerja yang signifikan. Beberapa optimasi tersedia:
    • Untuk animasi prosedural khusus, jangan update property JointInstance.C0 dan JointInstance.C1 . Alih-alih itu, update property Motor6D.Transform.
    • Jika Anda perlu menambahkan objek apa pun BasePart ke avatar, lakukanlah di luar hierarki avatar Model .

MicroProfiler Mata

PenglihatanKomputasi Bersama
stepHumanoidKontrol dan fisika manusia
Animasi Langkahanimasimanusia dan animator
updateInvalidatedFastClustersDikaitkan dengan mengeksekusi atau mengubah avatar

Render

Sebagian besar waktu yang dikonsumsi klien setiap frame adalah saat menyajikan adegan di frame saat ini. Server tidak melakukan render apa pun, jadi bagian ini hanya eksklusif untuk klien.

Panggilan Penggambar

Panggilan cetak adalah set instruksi dari mesin keGPU untuk menyelesaikan sesuatu. Panggilan cetak memiliki over头 yang signifikan. Biasanya, semakin sedikit panggilan cetak per frame, semakin sedikit waktu pemrosesan yang dibutuhkan untuk menyelesaikan frame.

Anda dapat melihat berapa banyak panggilan render saat ini terjadi dengan item Menggambar Statistik > Timing di Studio. Anda dapat melihat Menggambar Statistik di klien dengan menekan 1>Shift1> 3>F23>.

Semakin banyak objek yang perlu ditarik dalam adegan Anda dalam satu frame tertentu, semakin banyak panggilan menggambar dilakukan ke CPU. Namun, mesin Roblox menggunakan proses yang disebut instancing untuk menggabungkan meshes identik dengan karakteristik tekstur yang sama dalam satu panggilan menggambar. Secara khusus, beberapa meshes deng

Masalah Umum Lainnya

  • Kepadatan objek yang berlebihan - Jika banyak objek dikonsentrasikan dengan kepadatan tinggi, maka mengeklik area ini dari adegan mengharuskan lebih banyak panggilan menggambar. Jika Anda menemukan tingkat penggambaran Anda menurun saat melihat bagian tertentu dari peta, ini bisa menjadi tanda yang baik bahwa kepadatan objek di area ini terlalu tinggi.

    Objek seperti stiker, tekstur, dan partikel tidak mengalir dengan baik dan memperkenalkan panggilan penggambaran tambahan. Berhati-hatilah ekstra untuk jenis objek ini di adegan. Khususnya, perubahan properti ke ParticleEmitters dapat memiliki dampak signifikan pada pelaksanaan.

  • Kesempatan Pembuatan yang Dilewatkan - Seringkali, adegan akan mencakup meshes yang sama yang di duplikasi beberapa kali, tetapi setiap salinan meshes memiliki ID meshes atau tekstur yang berbeda. Ini mencegah pembuatan dan dapat menyebabkan panggilan gambar yang tidak perlu.

    Penyebab umum masalah ini adalah ketika seluruh adegan diimpor sekaligus, bukan aset individu yang diimpor ke Roblox dan kemudian duplikasi post-import untuk mengumpulkan adegan.

  • Kompleksitas objek yang berlebihan - Meskipun bukan penting seperti jumlah panggilan penggambaran, jumlah triungul di adegan menentukan berapa lama waktu render. Skala dengan propietas MeshPart.RenderFidelity di set ke Enum.RenderFidelity.Precise pada terlalu bany

  • Pemotretan bayangan yang berlebihan - Menangani bayangan adalah proses yang mahal, dan peta yang mengandung banyak objek bayangan (atau peta yang mengandung banyak objek kecil yang terpengaruh oleh bayangan) kemungkinan akan memiliki masalah kinerja.

  • Tingkat transparansi tinggi overdraw - Menempatkan objek dengan transparansi parcial di dekat satu sama lain memaksa mesin untuk mengekspor pixel yang bertumpangan beberapa kali, yang dapat menyebabkan pelaksanaan. Untuk lebih banyak informasi tentang mengidentifikasi dan memperbaiki masalah ini, lihat Hapus Layer Transparansi .

Mitigasi

  • Menginstansikan meshes serupa dan mengurangi jumlah meshes yang unik - Jika Anda memastikan semua meshes serupa untuk memiliki ID aset yang sama, mesin dapat mengenali dan menyajikan mereka dalam satu panggilan penggambaran. Pastikan untuk hanya mengunggah setiap meshes di p
  • Menghapus - Menghapus menggambarkan proses menghilangkan panggilan gambar untuk objek yang tidak masuk ke frame render terakhir. Secara default, mesin mengabaikan panggilan gambar untuk objek di luar bidang pandang kamera (frustum menggambil), tetapi tidak mengabaikan panggilan g
    • Sembunyikan MeshPart dan BasePart yang jauh dari kamera atau pengaturan.
    • Untuk lingkungan室内, 实现 a room or portal system yang menyembunyikan objek yang tidak saat ini ditempati oleh pengguna mana pun.
  • Mengurangi kesempurnaan render - Tetapkan kesempurnaan render ke Otomatis atau Performa. * Ini mengizinkan meshes untuk jatuh ke alternatif yang lebih sederhana, yang dapat mengurangi jumlah poligon yang perlu ditambahkan.
  • Menonaktifkan Shadow Casting di bagian yang tepat dan objek cahaya - Kompleksitas bayangan dalam adegan dapat dikurangi dengan menonaktifkan Shadow Casting properties di objek cahaya dan bagian. Ini dapat dilakukan saat waktu pengeditan atau secara dinamis saat eksekusi. Beberapa contoh:
    • Gunakan property BasePart.CastShadow untuk menonaktifkan Shadow Casting di bagian kecil di mana bayangan tidak mungkin terlihat. Ini dapat sangat efektif ketika hanya diterapkan pada bagian yang jauh dari kamera pengguna.

    • Nonaktifkan bayangan pada objek bergerak jika mungkin.

    • Nonaktifkan Light.Shadows di instans cahaya di mana objek tidak perlu menghasilkan bayangan.

    • Membatasi jangkauan dan sudut cahaya instans.

    • Gunakan lebih sedikit instans cahaya.

MicroProfiler Mata

PenglihatanKomputasi Bersama
Siapkan dan LakukanRender Umum
Lakukan/Panggung/menghitungCahayaPembaruan jaringan cahaya dan bayangan
LightGridCPUPembaruan jaringan cahaya Voxel
Sistem Peta BayanganPemetaan bayangan
Lakukan/Panggung/UpdateViewPersiapan untuk render dan pembaruan partikel
Lakukan/Panggung/RenderViewMenyelesaikan dan menyajikan

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 memerlukan lebih banyak waktu komputasi.

Masalah Umum

  • Lalu lintas lokal yang berlebihan - Mengirimkan jumlah data besar melalui RemoteEvent atau RemoteFunction objek atau mengeksek mereka dengan sangat sering dapat menyebabkan waktu pemrosesan yang besar. Kesalahan umum termasuk:

    • Mengkloning data setiap frame yang tidak perlu diklon.
    • Mengkloning data pada masukan pengguna tanpa mekanisme untuk menguranginya.
    • Menyampaikan lebih banyak data daripada yang diperlukan. Misalnya, mengirim seluruh inventaris pemain saat mereka membeli item daripada hanya rincian dari barang yang dibeli.
  • Pembuatan atau penghapusan pohon instansi kompleks - Ketika sebuah perubahan dibuat pada data model di server, itu di replikasi ke klien yang terhubung. Ini berarti menciptakan dan menghancurkan hierarki instansi besar seperti peta saat eksekusi dapat sangat intensif jaringan.

    Masalah umum di sini adalah data animasi kompleks yang disimpan oleh plugin Editor Animasi di rig. Jika ini tidak dihapus sebelum game diterbitkan dan model animasi dikloning secara teratur, sejumlah besar data akan di replikasi tanpa perlu.

  • Server-side TweenService - Jika TweenService digunakan untuk menggandakan objek server sisi,속性 yang diteleportasi ke setiap klien setiap frame. Tidak hanya menyebabkan tween menjadi jittery saat kelayakan latensi klien bervariasi, tetapi menyebabkan banyak lalu lintas jaringan yang tidak perlu.

Mitigasi

Anda dapat menggunakan taktik berikut untuk mengurangi replikasi yang tidak perlu:

  • Hindari mengirimkan jumlah besar data sekaligus melalui acara jarak jauh melalui Remote Event. *Alih-alih, hanya kirim data yang diperlukan dalam frekuensi yang lebih rendah. Misalnya, untuk keadaan karakter, replikasi ketika itu berubah daripada setiap frame.
  • Chunk up kompleks tree instance seperti peta dan memuatnya dalam potongan-potongan untuk mendistribusikan pekerjaan menggandakan ini di beberapa frame.
  • Bersihkan metadata animasi , khususnya direktori animasi rig, setelah diimpor.
  • Batasi replikasi instans yang tidak diperlukan , terutama dalam kasus di mana server tidak perlu mengetahui instans yang dibuat. Ini termasuk:
    • Efek visual seperti ledakan atau pembalasan sihir. Server hanya perlu tahu lokasi untuk menentukan hasilnya, sementara klien dapat menciptakan visual lokal.
    • Model tampilan item pertama.
    • Tween objek di klien daripada server.

MicroProfiler Mata

PenglihatanKomputasi Bersama
Paket ProsesMemproses paket jaringan yang masuk, seperti panggilan acara dan perubahan properti
A分配 Bandwith dan Jalankan PengirimAcara yang akan datang relevan di server

Penggunaan Memori Aset

Mekanisme dampak tertinggi yang tersedia untuk para kreator untuk meningkatkan penggunaan memori klien adalah mengaktifkan Streaming Instansi .

Mengalirkan Instansi

Instans Streaming secara selektif memuat bagian dari model data yang tidak diperlukan, yang dapat mengakibatkan waktu pemuatan yang signifikanmente dikurangi dan meningkatkan kemampuan klien untuk mencegah kemunduran saat ditekan oleh tekanan memori.

Jika Anda mengalami masalah memori dan memiliki instans Streaming Instan dinonaktifkan, pertimbangkan untuk meningkatkan pengalaman Anda untuk mendukungnya, terutama jika dunia 3D Anda besar. Streaming Instans adalah berbasis jarak di ruang 3D, jadi dunia yang lebih besar secara alami mendapatkan lebih banyak manfaat darinya.

Jika streaming instans adalah aktif, Anda dapat meningkatkan agresivitasnya. Misalnya, pertimbangkan:

  • Mengurangi penggunaan StreamingIntegrity yang bertahan.
  • Mengurangi Streaming Radius .

Untuk informasi lebih lanjut tentang opsi streaming dan manfaatnya, lihat Streaming Properties.

Masalah Umum Lainnya

  • Duplikasi aset - Kesalahan umum adalah mengunggah aset yang sama berkali-kali menyebabkan ID aset yang berbeda. Ini dapat menyebabkan konten yang sama dimuat ke dalam memori berkali-kali.
  • Volume aset yang berlebihan - Bahkan ketika aset tidak identik, ada kasus ketika kesempatan untuk menggunakan aset yang sama dan menyimpan memori hilang.
  • File audio - File audio dapat menjadi kontributor mengejutkan penggunaan memori, khususnya jika Anda memuat semuanya ke klien sekaligus bukan hanya memuat apa yang Anda butuhkan untuk beberapa bagian dari pengalaman. Untuk strategi, lihat Waktu pemuatan.
  • Tekstur tinggi resolusi - Konsumsi memori grafis untuk tekstur tidak terkait dengan ukuran tekstur di disk, tetapi lebih bien nomor piksel dalam tekstur.
    • Misalnya, tekstur pixel 1024x1024 mengkonsumsi empat kali memori grafis dari tekstur 512x512.
    • Gambar yang diunggah ke Roblox disimpan dalam format tetap, jadi tidak ada keuntungan memori untuk mengunggah gambar dalam model warna yang terkait dengan lebih sedikit bit per pixel. Secara serupa, kompresi gambar sebelum mengunggah atau menghapus saluran alfa dari gambar yang tidak memerlukannya dapat
    • Anda dapat mengidentifikasi konsumsi memori grafis untuk tekstur tertentu dengan menambahkan kategori Grafis ke konsol pengembang.

Mitigasi

  • Hanya mengunggah aset sekali - Gunakan ID aset yang sama di semua objek dan pastikan bahwa aset yang sama, terutama meshes dan gambar, tidak diunggah secara terpisah beberapa kali.
  • Temukan dan perbaiki duplikasi aset - Cari bagianesh serupa yang diunggah berkali-kali dengan ID yang berbeda.
    • Meskipun tidak ada API untuk mendeteksi kesamaan aset secara otomatis, Anda dapat mengumpulkan semua ID aset gambar di tempat Anda (baik secara manual atau dengan naskah), mengunduh mereka, dan membandingkan mereka menggunakan 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 tekstur yang berbeda untuk berbagai warna, unggah tekstur tunggal dan gunakan propinsi SurfaceAppearance.Color untuk menerapkan berbagai nuansa kepada itu.
  • Mengimpor aset di peta secara terpisah - Alih-alih mengimpor seluruh peta sekaligus, impor dan konstruksi aset di peta secara individual dan konstruksi mereka. 3D importer tidak melakukan duplikasi meshes, jadi jika Anda mengimpor peta besar dengan banyak ubin lantai yang ber
  • Terbatas piksel gambar untuk tidak lebih dari jumlah yang diperlukan. Kecuali gambar mengambil banyak ruang fisik di layar, itu biasanya memerlukan setidaknya 512x512 pixel. Kebanyakan gambar kecil harus lebih kecil dari 256x256 pixel.
  • Gunakan Trim Sheets untuk menjamin penggunaan maksimum tekstur ulang dalam peta 3D. Untuk langkah dan contoh tentang cara membuat Trim Sheets, lihat Membuat Trim Sheets .

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 bahwa itu memungkinkan Anda untuk menjamin bahwa bagian penting dari pengalaman Anda sepenuhnya dimuat tanpa pop-in. Namun, kesalahan umum adalah menggunakan metode ini secara berlebihan untuk pra-memuat lebih banyak aset daripada yang benar-benar diperlukan.

Sebuah contoh praktik buruk adalah memuat seluruhWorkspace . Meskipun ini dapat mencegah pop-in teks, itu secara signifikan meningkatkan waktu pemuatan.

Sebagai gantinya, hanya gunakan ContentProvider:PreloadAsync() dalam situasi yang diperlukan, yang termasuk:

  • Gambar di layar pemuatan.
  • Gambar penting dalam menu pengalaman Anda, seperti latar belakang tombol dan ikon.
  • Aset penting di area pemulatan atau bertelur.

Jika Anda harus memuat banyak aset, kami merekomendasikan Anda menyediakan tombol Skip Loading .