Simam AI Lab Our applied AI research division is now open. Visit the lab

Client delivery / Brand experience engineering

A beauty brand in 3D, delivered to a browser tab.

Technology lead for Digital Village (VLGE) across browser-delivered 3D brand experiences for global beauty brands. Unity development, Photon Fusion multiplayer, a real-time avatar pipeline, WebGL delivery, UX flow, performance optimisation and the technical foundations underneath all of it.

The brands belong to Digital Village’s clients rather than to us, so they are not named here. Two of the experiences are still live, and Digital Village publishes them openly — so you can open one in a browser tab and judge the engineering rather than take this page on trust.

Open the multiplayer brand world Open the three-world brand experience Discuss a Brand Build

Digital human avatars with a real polygon budget

Avatar personalisation and a collection loop worth staying for

Unity to WebGL, tuned for download and memory

The constraint that shapes everything

A beauty brand wants photoreal skin. A browser tab gives you a budget.

Every decision on this kind of work traces back to one tension. The brand side wants skin that reads as skin, hair that moves, garments that drape, and an environment that looks like the campaign. The delivery side is a browser: no install, a download budget measured in seconds of patience, a memory ceiling you will hit, and a graphics API a generation behind what the art was authored for.

Technology leadership on a project like this is not choosing the most impressive technique. It is deciding where the budget goes — and, more often, where it does not.

Download

Every megabyte is a drop-off

A brand experience competes with a back button. Asset streaming, texture budgets and load ordering are commercial decisions before they are technical ones.

Memory

The ceiling is lower than anyone expects

Browser 3D fails hard, not gracefully. Staying under the ceiling on mid-range devices constrains avatar counts, texture resolution and scene complexity from the first day of the build.

Fidelity

Spend it where the eye goes

Faces and hair carry a beauty experience. Foliage, architecture and props do not. The wireframe above shows exactly where the triangles went.

What was underneath it

The foundations, chosen rather than defaulted into.

A brand experience is judged on how it feels, but it stands or falls on a handful of infrastructure choices made early, when nobody is looking at it yet.

Digital humans

An avatar pipeline, not a model

Generated digital human avatars with a dedicated hair system, so faces are produced by a pipeline with a controllable budget rather than hand-authored one at a time. That is what makes personalisation and variety affordable instead of a per-character cost.

Multi-user

Presence, so the space is not empty

A networked layer carrying avatar presence and identity through the world. A branded environment with nobody in it reads as a screensaver; other people in it reads as an event.

Browser delivery

The unglamorous half of the work

Responsive WebGL templating, proper text input handling from the browser into the engine, and an optimisation pass over the build. None of it shows up in a pitch deck. All of it decides whether the thing is usable on a phone.

Location and AR

Foundations for taking it outside

Geospatial and AR toolkits were brought in alongside the browser work, so brand environments could extend to real-world placement rather than being locked to a screen.

A reason to stay

A collection loop, not a walkthrough

Visitors gather things as they explore — roses, seeds, petals, cards — with the counts on screen. A branded space with nothing to do in it is a corridor; a small loop gives a reason to reach the second room.

Phone-first

Touch controls, in portrait

On-screen movement and action controls in a portrait layout, rather than a desktop build rotated sideways. That decision constrains the camera, the UI scale and the environment scale, so it has to be made early.

The work in the engine

Built environments, avatars and product moments in one scene.

A brand world has to hold three different jobs at once: a place worth walking through, people worth seeing, and a product moment that does not feel like an advert bolted onto a garden.

Personalisation is the first thing a visitor does, so it is the first thing the pipeline has to make cheap.

In-world view in a portrait layout with on-screen movement controls and a collection counter — On-screen movement controls and a collection counter — a phone-shaped layout, not a desktop build squeezed sideways.

A pink circular pavilion with a glazed colonnade set in landscaped grounds — Architecture built to read instantly as the brand, and cheaply enough to leave budget for the faces.

What this proves: browser-delivered brand 3D is an engineering discipline with a fixed budget, not a rendering problem. The projects that fail are usually the ones that treated the budget as a late optimisation task rather than the design constraint.

The engineering, named

Multiplayer, an avatar pipeline and a backend, not just a Unity scene.

The visible half of this work is an environment with avatars in it. The half that decided whether it shipped was the architecture underneath: keeping twenty people in a room agreeing with one another, getting a photoreal avatar down to a budget a phone can hold, and giving a Unity client somewhere to save a world to.

An entry screen offering three themed worlds to explore, each previewed with its own environment and a styled character — The entry screen. Three themed worlds, each its own streamed scene, chosen before anything heavy downloads — the first decision that keeps the initial payload small.

An interior scene with a neon-lit window and a controls overlay showing movement on W A S D, look on mouse or trackpad and interact on the F key — Controls taught in the scene rather than in a manual. The same build has to answer to a trackpad and a phone, which constrains the interaction vocabulary to almost nothing.

An interior scene with a product display on the wall beside a bright video panel playing a campaign film — A product moment and a video panel inside the 3D scene. Streaming video into WebGL without breaking the memory ceiling is its own piece of engineering.

Multiplayer

Photon Fusion, sized to about twenty per room

Host and client architecture, NetworkRunner lifecycle, host migration, network object spawning, player and avatar synchronisation, and a chat system. Sessions were designed around roughly twenty concurrent users, with lobby capacity management and automatic scaling investigated beyond that. Desynchronisation between clients was its own debugging effort, and stress tests ran many avatars at once rather than two.

Commercial architecture

Concurrency is a bill, not just a number

Photon pricing was analysed as part of the design: concurrent users against monthly actives, regional traffic, bandwidth overages and the expected cost at several thousand users. A multiplayer architecture that works technically and is unaffordable at scale has not been designed, only demonstrated.

Avatar pipeline

A specification, agreed with the avatar vendor

The source characters were far too expensive for a mobile WebGL build, so the pipeline was specified rather than accepted: six base avatars, full-body humanoids with Mecanim-compatible skeletons and Mixamo-compatible animation, swappable hair and garments, FBX delivery with a Unity-ready hierarchy, and stated texture and polygon budgets. The targets settled around five to ten thousand triangles per character — roughly one to two thousand for the face, three to four for the body, one for hair and three to four for a garment — with albedo, normal, opacity and packed ambient-occlusion, roughness and metallic maps.

Makeup as a system

Masks and layers, not baked combinations

Baking every cosmetic option into every character multiplies the asset count until the build will not download. Makeup was specified instead as reusable masks and layers applied at runtime across any avatar, which turns an art pipeline into something that scales with the catalogue rather than with the catalogue times the cast.

Progression

One inventory, not six

The Garden Grower loop — buying seeds, planting, timed growth, rose rarity, harvesting, a petal currency, boosts, cosmetic unlocks, achievements, challenges, leaderboards and prestige — was specified to share a generic inventory and reward architecture. A good part of that work was arguing for less implementation rather than more: seeds, petals, roses, boosters and cosmetics are the same shape of thing and did not need five separate systems.

Platform and backend

A REST API a Unity client can actually consume

Alongside V-BLDR, the world-building product, the backend thinking moved from the existing GraphQL setup toward a plain Node.js REST API: authentication and token refresh, users, worlds and world state, assets and uploads, projects and sessions. That meant JWT handling, C# DTOs on the Unity side, file and image upload, error handling, API versioning, environment separation and AWS deployment with S3 storage behind a CDN — and asset bundles delivered the same way, with versioning, manifests, cache invalidation and a small initial payload.

What the role actually was

Technology lead, which is a different job from Unity developer.

The title on the engagement ended up as Technology Lead, and that is closer to the work than any description built around an engine. Most of it was decisions, specifications and the coordination between people who would otherwise have built incompatible halves of the same product.

Across disciplines

Unity, backend, art, vendor, infrastructure

The coordination ran between the Unity team, the backend developers, the 3D and art team, the specialist digital-human vendor, infrastructure, and product and management. The avatar budget above is a good example of why: it is simultaneously an art decision, an engine decision and a download decision, and it is only settled by someone holding all three.

Engineering practice

A branch workflow that protects what ships

Feature branches into dev as the working integration branch, then pull requests into staging and on into production, with the latter two protected from direct changes. Unglamorous, and the difference between a release you can reason about and one you cannot.

Hiring

Interviewing for the team that would build it

Technical interviews and assessment for Unity developers, backend developers and UI and UX candidates, deciding who progressed, and helping establish the engineering practices they would arrive into.

Case study decision record

The commercial case, in one view.

Client: Digital Village (VLGE). The end brands were Digital Village’s clients, not ours, so they are not named here.
Role: Technology lead across three builds: a WebGL marketing game experience, an interactive 3D world-building product, and headset-delivered brand environments.
Business challenge: Deliver a beauty brand’s creative ambition — digital humans, hair, garments, branded architecture — through a browser tab, with no install and no second chance at a long load.
What the work covered: Unity development, WebGL delivery and templating, UX flow, performance optimisation, an avatar and hair pipeline, a multi-user presence layer, and geospatial and AR foundations for extending the work beyond the screen.
Important technical decisions: Treat the download and memory budget as a design constraint from day one rather than a later optimisation. Concentrate fidelity on faces and hair, where a beauty audience actually looks. Produce avatars from a pipeline rather than authoring them individually.
Credible outcome: Browser-deliverable branded 3D environments with digital human avatars and multi-user presence, built for a global beauty client through an agency partner.
What it does not claim: Campaign performance and commercial results belong to the client and the agency and are not reported here. Some material from this programme remains confidential.

Want a brand experience that survives contact with a phone?

The interesting question is rarely whether it can be built. It is what has to be given up to make it load, and who decides. That is worth settling before the art is signed off, not after.

Start a project brief Back to case studies