DEV Community

Alicia lu
Alicia lu

Posted on Edited on Originally published at digitalgarden.si Fully Autonomous

Idol to Three.js: notes from a local garden-object experiment

This is a short companion to my original Idol desktop study on Digital Garden, published on 13 November 2026. The complete measurements, code, figures and reproduction files are available there.

I wanted to know whether an object generated from one owned garden image could survive a local browser loader. The practical check was not just whether Idol generated a PLY, but whether the file displayed with the expected orientation and color in Three.js and Spark.

A few observations

The study ran on an RTX 5070 Ti with Windows as the host and CUDA through WSL2. Fourteen generation jobs completed using two owned Blender renders: a potted plant and a watering can. Each condition was one observation at seed 42, so this is a small desktop experiment rather than a broad model benchmark.

At the default 50-step, 262,144-Gaussian setting, the first pipeline call with new compile caches took 47.68 seconds. The same input in the same process then took 29.52 seconds. Initial model loading and disk saving were recorded separately. The resulting uncompressed PLY was 17,826,208 bytes.

Actual browser captures of the owned plant generated by Idol, viewed from four headings

The browser integration mattered

The isolated viewer used Three.js 0.186.1 and Spark 2.3.1. The exported basis initially placed the plant upside down; an X rotation of pi corrected its placement. The native Three.js path also needed explicit SH0 sRGB decoding into the linear working space. These were viewer adaptations, and the generated PLY files were kept unchanged.

Nineteen final browser loads completed across WebGPU, the WebGL2 fallback and Spark, including the million-point file. Timing ended at the first submitted draw. It does not measure the first visible pixel or establish a renderer-speed ranking; Spark's worker may still be preparing visible data after submission.

Windows adapter counters included shared memory and unrelated desktop activity, so completion is not proof of zero memory spill. Physical iPhone Safari, public-network 3D delivery and production-garden placement remain untested.

Read the full original

The full Digital Garden article contains all five tables, four original figures, the encoder-source checks, native API examples, exact memory distinctions and an 18.7 MB reproduction bundle with raw records and two representative PLY exports. The article also explains the setup failures and limits behind these observations.

Alicia — 3D technical artist, TA and independent developer. Codex assisted the tests, numerical checks and writing. Owned text and figures retain CC BY 4.0; the linked bundle carries its own code and upstream notices.

Top comments (0)