Algoritma Nesting Pemotongan Kain di Browser: Menekan Sisa Kain Produksi Seragam Massal

Setiap tahun dunia memproduksi 92 juta ton limbah tekstil. Angka itu bukan estimasi blog, melainkan data dari rilis pers resmi UN Environment Programme menjelang International Day of Zero Waste 2025.

Kebanyakan orang membaca angka itu sebagai isu fast fashion.

Saya membacanya sebagai bug.

Karena di lantai produksi konveksi, sisa kain tidak lahir dari niat buruk. Ia lahir dari keputusan tata letak yang diambil manual, di bawah tekanan deadline, tanpa alat ukur objektif. Dan tata letak adalah masalah komputasi murni. Di situlah algoritma nesting pemotongan kain masuk sebagai persoalan engineering, bukan persoalan kerapian.

Ini bukan opini pribadi. Dalam studi Duta dkk. yang terbit di Journal of Computational Design and Engineering (Oxford Academic), disebutkan bahwa pada industri pakaian, bahan baku tekstil menyumbang 50–60% dari total biaya manufaktur. Studi yang sama menegaskan bahwa penempatan poligon tak beraturan di atas lembaran material adalah masalah NP-complete — tidak ada solusi eksak yang praktis, yang ada hanya heuristik yang lebih baik atau lebih buruk.

Saya mengangkat tema ini karena mayoritas tulisan optimasi di komunitas developer berhenti di LCP, bundle size, dan Core Web Vitals. Padahal ada kelas masalah lain yang nilainya jauh lebih besar per keputusan: satu persen efisiensi marker di pabrik seragam bernilai jutaan rupiah per bulan, dan hampir tidak ada yang menuliskannya untuk audiens teknis Indonesia.

Jadi mari kita bedah.

Bukan sebagai teori operations research.

Tapi sebagai sesuatu yang bisa kamu jalankan di localhost:3000 sore ini.

---

Intinya: sisa kain adalah output dari kualitas algoritma, bukan kualitas manusia. Geometri harus diselesaikan sebelum optimasi. Baseline yang jujur lebih berharga daripada metaheuristik yang tidak pernah diukur. Dan browser — dengan Web Worker dan WebAssembly — sudah cukup kuat untuk menjalankan semuanya tanpa server.

---

1. Sisa Kain Adalah Masalah Algoritma, Bukan Masalah Tukang Potong

Sebelum menulis satu baris kode, kita perlu sepakat soal definisi masalah. Salah mengklasifikasikan masalah di tahap ini akan membuat seluruh implementasi berikutnya menyelesaikan hal yang salah dengan sangat efisien.

Apa Itu Marker dan Kenapa Efisiensinya Diukur

Di konveksi, marker adalah gambar tata letak semua pola potong di atas gelaran kain. Metriknya sederhana:

• Marker efficiency = (total luas pola ÷ luas kain terpakai) × 100%
• Marker manual berpengalaman biasanya mendarat di kisaran 80-an persen
• Selisih 3–5% terdengar kecil, sampai kamu kalikan dengan ribuan meter kain per bulan

Yang menarik: operator berpengalaman sering menghasilkan marker yang setara dengan software komersial. Studi JCDE di atas menyebut hal ini secara eksplisit. Artinya target kita bukan "mengalahkan manusia", tapi mereplikasi kualitas manusia secara konsisten dan otomatis.

Dua Kelas Masalah yang Sering Tertukar

Ini pembeda paling penting, dan paling sering salah:

• 2D Strip Packing — lebar kain tetap (misal 150 cm), panjang tak terbatas. Tujuan: minimalkan panjang kain terpakai.
• 2D Bin Packing — lembaran berukuran tetap. Tujuan: minimalkan jumlah lembar.

Konveksi kain roll hampir selalu masuk kategori pertama. Jadi objective function kamu bukan "jumlah bin", tapi panjang strip. Salah memilih di sini membuat metrikmu tidak nyambung dengan tagihan supplier.

---

2. Selesaikan Geometri Dulu, Optimasi Belakangan

Ini kesalahan yang saya lihat berulang: orang langsung menulis genetic algorithm sebelum punya cara mendeteksi tumpang-tindih yang benar. Hasilnya adalah metaheuristik canggih yang mengoptimasi solusi tidak valid. Geometri adalah fondasi, optimasi adalah lapisan di atasnya.

No-Fit Polygon: Primitif yang Wajib Dikuasai

No-Fit Polygon (NFP) adalah konsep inti dari seluruh literatur nesting. Untuk dua poligon A dan B, NFP adalah himpunan semua posisi B yang membuatnya bersentuhan dengan A tanpa tumpang-tindih.

Kenapa ini penting secara praktis:

• Uji tumpang-tindih poligon-vs-poligon itu mahal dan rawan floating point error
• NFP mengubahnya jadi uji titik di dalam poligon — jauh lebih murah
• NFP bisa dihitung sekali di awal (precompute) dan di-cache, karena pasangan pola berulang terus

Untuk poligon konveks, NFP dihitung dengan Minkowski sum dan relatif mudah. Untuk poligon non-konveks — dan pola lengan baju itu non-konveks — implementasinya jauh lebih rumit. Ini bukan sesuatu yang sebaiknya kamu tulis dari nol di sprint pertama.

Alternatif yang lebih realistis untuk MVP: raster / grid-based collision. Rasterisasi setiap pola jadi bitmap, lalu uji tumpang-tindih dengan operasi bitwise. Akurasinya lebih rendah, tapi kamu bisa jalan dalam hitungan hari, bukan bulan.

Menyiapkan Poligon Sebelum Masuk Solver

Data pola dari file DXF atau SVG hampir tidak pernah siap pakai:

• Simplifikasi kurva — kurva Bézier harus di-flatten jadi polyline; terlalu banyak titik akan membunuh performa
• Seam allowance — kelim harus sudah termasuk dalam poligon, bukan ditambahkan belakangan
• Normalisasi orientasi — semua pola disimpan pada rotasi 0°, rotasi jadi variabel optimasi
• Toleransi jarak antar pola — pisau potong punya lebar; nol jarak berarti pola rusak

---

3. Menjalankan Solver di Browser Tanpa Membekukan UI

Menjalankan pencarian NP-complete di JavaScript terdengar seperti ide buruk. Praktiknya tidak, asal kamu tidak melakukannya di main thread. Bagian ini menentukan apakah alatmu terasa profesional atau terasa rusak.

Web Worker Adalah Batas Eksekusi, Bukan Optimasi Tambahan

Solver nesting akan berjalan puluhan detik. Di main thread, itu artinya UI beku total — klik tidak merespons, animasi berhenti, browser menawarkan "kill page".

Jakub Andrzejewski, Google Developer Expert di bidang web performance, menulis panduan praktis memindahkan operasi berat ke Web Worker yang polanya langsung berlaku di sini. Prinsip yang relevan untuk kasus kita:

• Kirim geometri sekali di awal lewat postMessage, jangan per iterasi
• Gunakan Transferable Objects (ArrayBuffer) untuk data poligon — hindari structured clone berulang
• Kirim progress update ke UI dengan throttle, misal tiap 200 ms
• Sediakan tombol batal yang benar-benar memanggil worker.terminate()

Untuk beban yang lebih berat, kompilasi bagian collision detection ke WebAssembly. Ini bukan optimasi prematur — deteksi tumpang-tindih adalah hot path yang dipanggil jutaan kali, dan di sinilah 3% kritis yang layak dioptimasi berada.

Mulai dari Baseline yang Jujur

Sebuah algoritma nesting pemotongan kain yang berguna tidak harus dimulai dari metaheuristik. Mulailah dari Bottom-Left-Fill (BLF):

1. Urutkan pola dari luas terbesar ke terkecil
2. Untuk tiap pola, cari posisi paling bawah lalu paling kiri yang valid
3. Uji beberapa sudut rotasi diskrit (0°, 90°, 180°, 270°)
4. Catat efisiensi akhir

BLF sederhana, deterministik, dan cepat. Yang paling penting: ia memberimu angka pembanding. Tanpa baseline, kamu tidak akan pernah tahu apakah genetic algorithm-mu benar-benar membantu atau hanya membakar CPU.

Lapisan Metaheuristik di Atas Baseline

Setelah BLF jalan, urutan pola jadi variabel yang bisa dioptimasi. Di sinilah metaheuristik masuk — bukan menggantikan BLF, tapi mencari urutan input terbaik untuk BLF.

---

4. Perbandingan Pendekatan yang Realistis

Tidak ada pemenang mutlak. Yang ada adalah trade-off antara waktu implementasi, waktu komputasi, dan kualitas hasil. Tabel berikut disusun dari literatur yang dirujuk di studi JCDE dan dari pertimbangan implementasi di browser.

Pendekatan	Kompleksitas Implementasi	Waktu Komputasi	Kualitas Hasil	Cocok untuk
Bottom-Left-Fill (BLF)	Rendah	Detik	Baseline	MVP, validasi konsep
BLF + Genetic Algorithm	Sedang	Menit	Baik	Produksi tahap awal
Simulated Annealing	Sedang	Menit	Baik	Batch kecil, pola beragam
Particle Swarm (PSO)	Sedang–Tinggi	Menit	Baik	Riset internal
Jaya (bebas parameter)	Sedang	Menit	Baik	Tim tanpa spesialis tuning
Solver komersial	—	Detik	Sangat baik	Volume tinggi, budget ada

Catatan penting soal Jaya: keunggulannya bukan hasil akhir, melainkan tidak adanya parameter khusus yang perlu di-tuning. GA butuh crossover rate, mutation rate, dan population size. SA butuh jadwal pendinginan. Untuk tim kecil tanpa spesialis optimisasi, satu parameter yang tidak perlu ditebak adalah penghematan waktu yang nyata.

---

5. Batasan Dunia Nyata yang Tidak Ada di Paper

Bagian ini yang membuat implementasi akademis gagal di lantai produksi. Paper mengasumsikan poligon di atas bidang kosong. Kain nyata punya arah, cacat, dan aturan.

Grain Line dan Arah Serat

Kain punya arah serat. Pola yang diputar sembarangan akan menghasilkan baju yang melintir setelah dicuci pertama. Konsekuensi teknisnya keras:

• Rotasi tidak bebas — biasanya hanya 0° dan 180° yang diizinkan
• Kain bermotif satu arah (napped fabric) bahkan hanya mengizinkan 0°
• Ini memangkas ruang solusi secara drastis, dan itu bukan kabar buruk: pencarian jadi lebih cepat

Cacat Kain dan Lebar Efektif

• Roll kain punya cacat titik yang posisinya sudah dipetakan saat inspeksi
• Tepi kain (selvedge) tidak selalu bisa dipakai — lebar efektif lebih kecil dari lebar nominal
• Solver harus memperlakukan area cacat sebagai obstacle tetap, bukan area kosong

Menariknya, studi JCDE menyebut kemampuan membatasi posisi per-pola ini justru fitur pembeda algoritma Jaya — sesuatu yang mereka contohkan pada industri alas kaki, di mana bagian kulit dengan kekuatan berbeda harus dipetakan ke bagian sepatu yang berbeda.

Rasio Size dalam Satu Marker

Order seragam pabrik tidak pernah satu ukuran. Satu marker biasanya memuat campuran S, M, L, XL dengan rasio mengikuti distribusi karyawan. Ini berarti input solver-mu bukan "20 pola", tapi "20 pola × distribusi ukuran", dan jumlah poligon bisa membengkak jadi ratusan.

Daftar batasan di atas saya susun dari diskusi dengan tim produksi di CV Mitra Mandiri Design, konveksi seragam kerja di Karawang, yang rutin menangani order seragam pabrik dalam ratusan potong dengan rasio ukuran yang tidak pernah seragam. Poin soal rasio size ini tidak pernah muncul di satu pun paper yang saya baca — dan justru itu yang paling sering merusak asumsi solver.

---

6. Langkah Implementasi dari Nol

Berikut urutan pengerjaan yang saya rekomendasikan untuk membangun prototipe algoritma nesting pemotongan kain yang benar-benar berjalan, bukan sekadar demo. Urutannya sengaja menunda bagian yang paling menggoda untuk dikerjakan duluan.

Enam Langkah Berurutan

1. Siapkan parser geometri. Impor SVG atau DXF, flatten kurva jadi polyline, normalisasi ke koordinat milimeter.
2. Bangun collision detection. Mulai dari raster-based. Naik ke NFP hanya jika akurasi raster terbukti tidak cukup.
3. Implementasikan BLF sebagai baseline. Ukur efisiensinya. Catat angkanya. Ini titik nol kamu.
4. Pindahkan solver ke Web Worker. Tambahkan progress reporting dan tombol batal sebelum menambah fitur apa pun.
5. Tambahkan lapisan metaheuristik. Optimasi urutan input BLF. Bandingkan dengan baseline pada dataset yang sama.
6. Masukkan constraint produksi. Grain line, cacat kain, jarak pisau, rasio ukuran. Ukur ulang.

Skema HowTo (JSON-LD)

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun Algoritma Nesting Pemotongan Kain di Browser",
  "description": "Langkah membangun solver 2D irregular strip packing untuk menekan sisa kain pada produksi seragam massal, dijalankan penuh di sisi klien.",
  "totalTime": "P14D",
  "tool": [
    { "@type": "HowToTool", "name": "JavaScript / TypeScript" },
    { "@type": "HowToTool", "name": "Web Worker API" },
    { "@type": "HowToTool", "name": "Canvas atau SVG untuk visualisasi" }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Siapkan parser geometri",
      "text": "Impor pola dari SVG atau DXF, flatten kurva Bezier menjadi polyline, dan normalisasi seluruh koordinat ke satuan milimeter."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Bangun deteksi tumpang-tindih",
      "text": "Mulai dengan pendekatan raster berbasis bitmap. Naikkan ke No-Fit Polygon hanya bila akurasi raster terbukti tidak memadai."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Implementasikan baseline Bottom-Left-Fill",
      "text": "Urutkan pola dari luas terbesar, tempatkan pada posisi valid paling bawah lalu paling kiri, dan catat efisiensi marker sebagai titik pembanding."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Pindahkan solver ke Web Worker",
      "text": "Jalankan solver di background thread dengan Transferable Objects, progress update ter-throttle, dan tombol pembatalan yang memanggil terminate."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Tambahkan lapisan metaheuristik",
      "text": "Optimasi urutan input Bottom-Left-Fill menggunakan genetic algorithm, simulated annealing, atau Jaya, lalu bandingkan terhadap baseline."
    },
    {
      "@type": "HowToStep",
      "position": 6,
      "name": "Masukkan batasan produksi nyata",
      "text": "Terapkan pembatasan grain line, peta cacat kain, jarak pisau potong, dan rasio distribusi ukuran, kemudian ukur ulang efisiensinya."
    }
  ]
}

---

FAQ

Apakah algoritma nesting pemotongan kain bisa mengalahkan operator marker berpengalaman?

Belum tentu, dan itu bukan tolok ukur yang tepat. Literatur menunjukkan operator berpengalaman sering setara dengan software komersial. Nilai sebenarnya ada pada konsistensi dan skala: solver menghasilkan kualitas yang sama pada jam 2 pagi, untuk order ke-500, tanpa kelelahan.

Kenapa harus di browser, bukan di backend?

Tiga alasan praktis: tidak ada biaya server untuk beban CPU yang berat, data pola pelanggan tidak perlu keluar dari perangkat, dan iterasi desain terasa instan. Kekurangannya jelas — performa bergantung pada perangkat pengguna, dan laptop kantor lama akan terasa lambat.

Berapa lama waktu komputasi yang wajar?

Untuk 20–30 pola, hitungan detik sampai satu-dua menit adalah normal. Studi JCDE mencatat waktu komputasi 83 detik untuk dataset 25 pola. Jangan janjikan hasil real-time — janjikan hasil yang bisa dibatalkan kapan saja.

Apakah perlu WebAssembly sejak awal?

Tidak. Bangun dulu versi JavaScript murni, ukur di mana waktunya habis, baru pindahkan bagian tersempit ke WASM. Hampir selalu bagian itu adalah deteksi tumpang-tindih.

Apakah pendekatan ini berlaku di luar tekstil?

Ya. Masalah yang sama muncul di pemotongan pelat logam, kayu, kulit, kaca, dan laser cutting. Yang berubah hanya batasan domainnya — logam tidak punya grain line, tapi punya arah rol.

---

Efisiensi yang Diukur, Bukan Diklaim

Pada akhirnya, godaan terbesar dalam proyek seperti ini bukan pada bagian yang sulit, melainkan pada bagian yang menyenangkan. Menulis genetic algorithm jauh lebih memuaskan daripada menulis parser DXF. Padahal parser yang salah membuat seluruh optimasi di atasnya tidak ada artinya.

"Premature optimization is the root of all evil."
— Donald Knuth

Knuth adalah profesor emeritus Stanford, penulis The Art of Computer Programming, peraih Turing Award 1974, dan sering disebut sebagai bapak analisis algoritma. Kalimat itu ia tulis dalam makalah Structured Programming with go to Statements (ACM Computing Surveys, 1974) — dan menariknya, Knuth sendiri belakangan mengkreditkannya sebagai "Hoare's Dictum". Konteks penuhnya jauh lebih berimbang daripada versi yang beredar: ia berkata kita sebaiknya mengabaikan efisiensi kecil sekitar 97% dari waktu, tapi jangan melewatkan peluang pada 3% yang kritis.

Relevansinya di sini nyaris harfiah. Sebagian besar kode dalam algoritma nesting pemotongan kain — parser, UI, serialisasi — tidak perlu dioptimasi sama sekali. Tapi deteksi tumpang-tindih adalah 3% itu. Ia dipanggil jutaan kali. Di sanalah WebAssembly, caching NFP, dan spatial indexing benar-benar berarti.

Sisa kain bukan takdir industri. Ia adalah angka yang bisa diukur, dan apa pun yang bisa diukur bisa diperbaiki.

Mulai dari baseline. Ukur. Baru optimasi.