Getting a 3D boat configurator ready for phones: measurements so far

The question

The test subject is a browser configurator for a boat interior: the hull color, the floor, the metal finish, the cushions and a few other things across nine option groups and 28 options, with the 3D scene updating to match. On a desktop with a 4090-class graphics processor it looks right and turns smoothly under the mouse. The question is whether it opens on a modest laptop or a cheap phone at all, and if not, which part of it gets in the way.

A rule applies to every phone figure below: "works on phones" stays unclaimed until a real low-end phone has passed. Phone numbers in this note are targets, listed next to the measurements that actually exist.

The setup

The starting point was measured first. The boat model had 2.2M triangles and weighed 77.7 MB uncompressed, with 107 textures adding 52 MB. The lighting is baked into textures ahead of time, which is what makes it look close to an offline render, and some of those light textures were 8K.

The default view needed about 3 GB of GPU texture memory, and roughly 1 GB of that came from three 8K lightmaps alone. On the 4090 nobody would notice. On machines with 4 to 8 GB of graphics memory, or with graphics built into the processor, it was the main reason for freezing, and by estimate that much texture memory is far beyond the graphics memory a typical phone has.

Five test versions of the same scene were built and compared side by side:

• lossless geometry compression on the model
• textures loaded only when an option on screen needs them
• small textures first, with sharp ones swapped in afterward
• a still preview image shown while the 3D scene loads
• a GPU texture compression format in place of the usual image files

Separately, the expensive setup work on the page was moved. The scene downloads once the page has loaded, and the heavy setup only starts after scrolling stops, so the page doesn't stutter while someone is reading. A flicker on the seat cushions was fixed along the way: two surfaces sat in almost the same spot and the browser kept switching which one it drew on top, so the fabric shimmered whenever the camera turned a little.

Measurement

The yardstick was a realistic browser profile: a 100 Mbit connection with the processor slowed down 4x. Each version got two timings, first frame and full quality, and the final image was compared against the original to make sure nothing visibly changed.

That profile has known gaps. It's a desktop pretending to be a slower device, and a phone differs in ways a throttled desktop doesn't capture, such as how its graphics chip handles large textures and how it slows down once it gets warm. Only one scene was measured. The result also hasn't been run on an actual cheap phone yet, which is the only test that counts for the phone claim. The options for that are an old phone out of a drawer or a remote service that gives access to real devices.

Results

The original took 16.7 s to show its first frame on the realistic profile. The chart shows the four versions that render the real scene from the start; the preview-image version and the texture-format version are covered in the text.

• Original16.7 seconds
• Lossless geometry compression13 seconds
• Textures on demand13.4 seconds
• Small textures first10 seconds

Source: Test measurements, September 28, 2026

Lossless geometry compression shrank the model from 77.7 MB to 36.5 MB with an identical image, and the first frame came in at 13.0 s. That's a real saving in download size, but the scene still asked for the same texture memory once it arrived, so the device problem stayed where it was.

Loading textures on demand gave a first frame of 13.4 s, again with the same image, though full quality arrived later than in the original. Sending small textures first got the first frame down to 10.0 s, but full quality took the longest of any version, and the opening seconds looked blurry. The preview image put something on screen in 0.1 s, which makes the page feel alive, but the real scene still took 16.7 s behind it.

The GPU texture format was the surprise: the download grew 3.4x and the first frame arrived even later than the original's 16.7 s, so it was dropped.

The setup rework was the clearest win. The first full draw, meaning the moment the browser first paints the finished scene, went from 3.9 s to about 15 ms with the same image. The scene is just as heavy as before, but the page no longer locks up while the browser prepares it.

Takeaways

The freezing traced back to the 3 GB of texture memory, most of it sitting in a handful of very large lightmaps, and shrinking the download did little about it. Memory is the first thing to check, before file sizes.

In this scene the GPU texture format made the files bigger and slower to show on the same profile, so any format like it should be tried on the real scene before adoption.

A faster first frame and a faster finished scene can pull in opposite directions. The small-textures-first version won on the first frame and lost badly on full quality, so both timings are worth recording before deciding which one a viewer will actually feel.

Device tiers belong in the plan from the first day of a 3D web project, with the high-end desktop treated as the top tier from the start.

Current state

As of September 28, 2026, the code side is done in a test copy. It combines the lossless compression with on-demand textures, draws new frames only while something is moving (so an untouched scene draws nothing and shouldn't drain a battery), caps the pixel density on phones and lowers resolution automatically if the frame rate drops. For the lowest tier, the glass uses a cheap fixed reflection instead of drawing the scene a second time. On load, the page reads what the device can handle from its graphics chip, memory, processor cores and screen, and is set up to open the lightest package first and swap in a heavier one in the background if the device can take it. The detection and swap logic is in place, but for now it only has the full-quality package to serve.

The lighter models are the slower part and aren't built yet. The plan is a medium package around 300K triangles with 2K textures, and a low package around 80K to 100K triangles with 1K textures, with fine detail baked into the surface maps. On the low tier, lighting and color would merge into a single texture per option, which by estimate takes texture memory from 3 GB to about 150 MB. For devices that can't draw 3D at all, the planned fallback is 36 pre-rendered frames per option that can be spun with a finger.

The full-quality version still has a few visible rough spots. The dark velvet cushions come out darker than in the offline render, a tinted glass vase shows up solid black, the glossy black under the hardtop reflects less than it should, and with the third hull color a few railing pieces stay white where the offline render shows them burgundy.

The target on a cheap Android phone is an interactive scene in 3 s, a first download of 10 to 15 MB, memory use under 200 MB and no heat or battery drain while nobody is touching it, while a strong desktop keeps today's full quality. None of that is proven yet. Once a real low-end phone passes, those numbers get published here.

Ask AI about this AI Lab note

Opens the assistant in a new tab with this page as the source.

ChatGPTClaudePerplexityGemini