Banyak halaman produk WooCommerce masih menampilkan hal yang sama selama 20 tahun terakhir: sekumpulan foto datar. Beberapa bulan terakhir, saya menggarap Noorifa, sebuah plugin yang mengganti tampilan tersebut dengan pemirsa interaktif berbasis Three.js—pelanggan dapat memutar model, memperbesar, dan mengganti warna/bahan pada mesh tertentu secara real time, disinkronkan dengan variasi WooCommerce toko. Bagian rendering 3D hanyalah 20% yang mudah. 80% sisanya adalah serangkaian masalah kecil dan spesifik yang tidak muncul di tutorial Three.js. Berikut adalah empat di antaranya.
Pertama, rig lampu directional tidak dapat menerangi wajah yang tidak terlihat. Saat pelanggan memutar model meja, bagian bawah tabletop sering kali terlihat hampir hitam, tidak peduli seberapa besar intensitas cahaya yang saya naikkan. Rig awal menggunakan satu key light dan hemisphere ambient. Masalahnya bersifat geometris: keyLight berada di atas model, sehingga cahayanya hanya mencapai permukaan yang normalnya menghadap ke arahnya. Permukaan yang menghadap ke bawah—seperti bagian bawah tabletop yang menjorok—tidak dapat menerima kontribusi langsung dari cahaya di atasnya, berapa pun intensitasnya. Solusinya adalah menerapkan pencahayaan tiga titik yang lebih mendekati studio: key, fill, dan rim dari atas untuk bentuk dan pemisahan, ditambah lampu khusus dari bawah, dan warna ground hemisphere yang lebih terang untuk mensimulasikan pantulan cahaya. Lampu-lampu ini tidak menghasilkan bayangan, sehingga biaya GPU tetap rendah.
Kedua, zoom OrbitControls yang tidak terbatas terlihat seperti bug, bukan fitur. Secara default, rentang zoom OrbitControls adalah [0, Infinity]. Pelanggan sering kali menggulir model hingga menghilang di belakang bidang clipping terdekat atau mengecil menjadi titik—kedua kasus ini terasa seperti "rusak", bukan "zoom". Perbaikan adalah dengan membatasi minDistance dan maxDistance, tetapi skalanya harus relatif terhadap produk itu sendiri. Menggunakan angka tetap akan gagal ketika dua produk memiliki ukuran fisik yang sangat berbeda—sebuah cincin dan lemari tidak dapat berbagi rentang zoom yang sama. Dengan menggunakan radius framing otomatis model, setiap produk mendapatkan rentang zoom yang proporsional terhadap ukurannya saat dimuat:
`function applyFraming(framing) { camera.near = framing.radius / 100; camera.far = framing.radius * 100; camera.updateProjectionMatrix(); controls.target.copy(framing.center); controls.minDistance = framing.radius; controls.maxDistance = framing.radius * 4; }`
Ketiga, Draco dan pertanyaan WASM (dikoreksi dari posting sebelumnya). Awalnya saya mengklaim bahwa "WordPress.org melarang bundling biner .wasm." Seorang komentator meminta saya untuk menunjukkan aturan tersebut, dan saya tidak dapat menemukannya. Koreksi yang tepat: Tidak ada aturan khusus yang menyebutkan WebAssembly. Aturan plugin WordPress.org secara umum mengharuskan semua kode yang didistribusikan untuk tidak diobfuscate dan tersedia sebagai sumber yang dapat dibaca manusia. Biner .wasm yang dikompilasi tidak memenuhi syarat sebagai sumber dalam bentuk apa pun, sehingga secara praktis melanggar aturan yang sama—tetapi ini adalah inferensi, bukan kebijakan yang dikutip. Efek praktisnya tetap sama: decoder Draco tersedia dalam build WASM (lebih cepat) dan JS murni (lebih lambat, dapat diinspeksi). Untuk distribusi di WP.org, saya memaksa penggunaan decoder JS untuk mematuhi transparansi sumber, yang menyebabkan decoding lebih lambat pada mesh besar.
Keempat, jangan membuat ulang harga variasi—serahkan pada form WooCommerce. Dorongan awal adalah mengambil harga variasi secara manual saat pelanggan mengklik swatch warna dan memperbarui DOM. Ini salah, karena WooCommerce sudah memiliki form variasi dengan lookup harga/stok yang di-cache AJAX dan dapat di-hook oleh tema dan plugin lain. Membuat ulang logika ini akan membatalkan setiap tema kustomisasi dan hook harga plugin lain untuk swatch Anda. Sebaliknya, klik swatch cukup memicu event change WooCommerce yang asli, yang secara otomatis memperbarui harga dan stok melalui mekanisme yang sama seperti dropdown asli. Efek samping yang baik: jika data variasi toko memiliki inkonsistensi (misalnya, nilai tetap "Any" bukan opsi spesifik), hal ini akan rusak dengan cara yang sama seperti dropdown asli, sehingga memudahkan pembuatan peringatan diagnostik.
Perbaikan-perbaikan ini tidak hanya meningkatkan pengalaman visual tetapi juga memastikan kompatibilitas dengan ekosistem plugin dan tema yang lebih luas. Bagi pengembang e-commerce di Indonesia, mengadopsi konfigurator 3D dapat meningkatkan konversi dan diferensiasi, tetapi penting untuk memahami tantangan teknis seperti pencahayaan, kontrol zoom, kepatuhan kebijakan, dan integrasi variasi agar tidak mengorbankan fungsionalitas yang sudah ada.
Ke depan, teknologi seperti ini membuka jalan bagi pengalaman ritel yang lebih immersif, potensi integrasi dengan AR/VR, dan personalisasi yang lebih dalam. Komunitas pengembang lokal dapat memanfaatkan proyek open-source seperti Noorifa untuk membangun solusi kustom yang sesuai dengan pasar Indonesia, sekaligus menghindari perangkap umum yang dihadapi oleh pengembang plugin global.