Building a 3D visualiser that survives a showroom basement

When we started building the tile visualiser, we assumed the hard problem was making tile look convincing in a rendered room. It was not. The hard problems were all environmental.

The device is worse than you planned for

Showroom tablets are bought once and kept for years. Ours needed to run on hardware several generations old, with a GPU that gives up quickly and a browser that is not current.

That ruled out a great deal of what makes 3D on the web pleasant. We ended up with a much more conservative rendering approach and a quality ladder that degrades on capability detection rather than assuming a baseline.

The connection will fail mid-session

Showrooms are frequently in basements. A salesperson configuring a room in front of a customer cannot have the tool stall on a texture download.

We moved to aggressive pre-caching of the tiles a particular showroom actually carries, rather than loading the full catalogue on demand. A dealer stocking two hundred SKUs does not need the other eight thousand available instantly.

Texture memory is the real constraint

Tile textures need to be high resolution or the product looks cheap, which defeats the purpose. But a room with floor, walls and a border is several large textures at once, on a device with limited memory.

Most of the optimisation work went into texture atlasing and unloading anything not currently visible — unglamorous engineering that determined whether the thing worked at all.

What we would tell someone starting this

Get a prototype onto the actual device in the actual room within the first fortnight. Every assumption we made from a desk was wrong, and the ones that mattered were wrong in ways no amount of specification would have surfaced.