Interactive brand experience
Interactive 3D business experience
A corporate site where the product sits in a navigable 3D space, built to hold a stable frame rate on a phone rather than to impress a desktop reviewer.
Interface built in code for this case study — not a client screen capture.
01Business problem
A business whose product is physical, sold to buyers who will never hold it before deciding — and a website that could only show it as photographs on a white background.
Who feels it
Corporate sites in trading and distribution converge on the same template because the template is safe: a hero image, three value propositions, a grid of product photographs, a contact form. It communicates competence and almost nothing else. A buyer leaves knowing the company exists and nothing about what distinguishes what it sells.
A physical product photographed flat loses the two things that actually sell it, which are scale and construction. A photograph is one angle chosen by whoever took it. The buyer’s real question — what does this look like from the side, how does it sit next to something familiar — is unanswerable from a gallery.
The obvious counter-argument to 3D on a business site is that it is decoration, and usually it is. An interactive scene that takes eight seconds to load on a phone and then runs at twelve frames per second is worse than a photograph in every measurable way. So the brief was not "add 3D"; it was to make a spatial presentation that survives contact with a mid-range device, or else not to ship one.
02Product overview
A single interactive scene the visitor moves through, with a hard performance budget, and a static path that carries the same information for anyone the scene would fail.
Engineering notes
The scene is one continuous space, not a set of separate 3D viewers. A visitor moves along a path through it, and the business content is positioned in that space: a section of copy sits at a place, not on a page. That is where the work goes — keeping orientation legible so the visitor always knows where they are, and making movement feel intentional and never like a camera being dragged.
Scrolling drives the camera, which is a decision with a well-known failure mode: scroll-jacking that fights the user. The mitigation is that scroll position maps to camera position monotonically and predictably, the visitor can always go back the way they came, and no input is captured or delayed. Movement is damped, never snapped, so a fast flick decelerates into place instead of overshooting.
The performance budget was fixed before any geometry existed: a stable frame rate on a mid-range Android, and a first meaningful frame before the full scene finishes loading. That drove nearly every subsequent decision — polygon counts, texture resolution, how many materials could be distinct, whether a given effect was affordable. Geometry was authored to the budget rather than optimised down to it afterwards. A scene that holds the target and a scene that gets close are built differently from the first asset onward.
Loading is progressive and ordered by what the visitor sees first. A low-resolution version of the primary subject arrives early and is replaced when the full-resolution asset is ready, so the first frame shows the product and not a spinner. Assets for later positions along the path load while the visitor is reading the earlier ones.
The static path is not a degraded version, it is a complete one. If WebGL is unavailable, the device is thermally constrained, or reduced motion is requested, the page renders the same content as ordinary sections with pre-rendered stills of the same views. Nothing that matters is only expressible in the scene, which was a constraint on the content design and not a technical afterthought.
03Key features
8 capabilities, described by what they let someone do rather than by the technology underneath.
Business content is positioned within a single scene, never split across separate 3D widgets, so moving through the site is moving through one place.
Scroll maps monotonically to position along the path. Movement decelerates into place, reverse is always available, and no input is swallowed or delayed.
Copy and calls to action are attached to locations in the scene and remain readable against whatever is behind them — the part that usually fails.
The subject can be turned and examined in place, answering the questions about scale and construction that a photograph cannot.
A low-resolution primary subject appears first and is upgraded in place. The first frame shows the product, not a loading state.
A dropped-frame counter ran in the development build. A change that cost frames was reverted, not accepted, and that is why the target held.
No WebGL, a constrained device, or a reduced-motion preference produces the same content as ordinary sections with pre-rendered stills. Nothing is only available inside the scene.
Gesture targets sized for a thumb, no reliance on hover, and no gesture that conflicts with the browser’s own. Mouse behaviour was added second.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
WebGL support, device memory and reduced-motion preference are read before anything heavy is requested. A device that fails the check never downloads scene assets at all.
Geometry decimated and compressed at build time, textures resized to the maximum the budget allows and no further. Nothing is optimised at runtime.
A single scene graph with content anchors as named nodes, so a copy section and its camera position are defined together and not coordinated by hand.
Scroll offset maps to a position along a spline. Damping is applied to the mapped value, not to the scroll itself, so native scrolling is never intercepted.
One loop, driven by animation frames, with work skipped when the tab is hidden and geometry outside the frustum culled. Nothing animates while the visitor is not looking at it.
Pre-rendered stills of the same camera positions in a document layout, generated from the scene so the two versions cannot drift apart visually.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Optimising a finished scene downward is guesswork and it usually ends with the scene looking worse than if it had been built to the target. Authoring to a budget makes every asset decision concrete.
Trade-off
Some visual ideas were rejected on cost before being tried. That is a real creative constraint, and it is why the frame rate held on the devices that matter.
Why
Scroll is the gesture every visitor already has. A bespoke navigation control has to be discovered, and most visitors will not bother.
Trade-off
Scroll-driven cameras are widely done badly, so the implementation has to be conservative: monotonic, reversible, and never capturing input. Less scope for dramatic transitions.
Why
A meaningful share of visitors will not get the scene, whether from hardware, a preference or a failed asset. Treating them as an error case would have meant designing content that only works in 3D.
Trade-off
Every content decision had to work in both presentations, which ruled out ideas that only made sense spatially.
Why
Overlaid text floating above a 3D background is the arrangement that makes these sites feel like a screensaver with captions. Anchoring content to locations makes the space navigational; without it, the geometry is decoration.
Trade-off
Legibility becomes a real engineering problem, since the backdrop behind a paragraph changes as the camera moves. Solved with backing treatments tuned per anchor, not one global overlay.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Profiled on the actual device, not on a throttled desktop. That put the cost in overdraw and material count — not in polygon count, where I had assumed it was. Consolidated materials and reduced transparent layers.
Outcome
The frame rate stabilised on the target hardware. Desktop throttling had been measuring the wrong bottleneck entirely.
Approach
Added a per-anchor backing treatment tuned against the actual backdrop at that position, instead of a single global scrim that darkened the whole scene.
Outcome
Copy stayed readable throughout the path without flattening the scene behind it.
Approach
Replaced linear mapping with damped interpolation towards the target position, plus soft attraction near each anchor so the camera settles at a section and not beside it.
Outcome
A fast flick decelerates into the nearest anchor. The visitor cannot end up looking at nothing, and scrolling itself is never blocked.
Approach
Reordered loading by view priority and introduced a low-resolution version of the primary subject that is swapped for the full asset in place.
Outcome
The product is visible almost immediately and sharpens as the visitor reads. No spinner, and no empty frame.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Built as a coded interface for this write-up rather than a screen capture, so it stays sharp at any zoom and no client content is republished.
Scene path
The camera path with its content anchors marked, and the current position along it.
Frame budget
Frame timing on the target device against the budget, with the expensive passes broken out.
Asset loading
Load order by view priority, with the low-resolution placeholder and its upgrade.
Fallback path
The same content as document sections with pre-rendered stills, for devices that fail the capability check.
A diagram I drew from the implementation, showing the components that exist and how they call each other. It is evidence of how the system is put together. It is not a capture of a running system, and it does not by itself establish that the system shipped or was used by anyone.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
11Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.