Interactive 3D reconstruction with Gaussian Splatting: turnkey development

Why 3D Gaussian Splatting does not reach a production version

The first failure is the gap between the demo and the browser. On the demo stand, the scene is captured under even lighting and a circular orbit, but at the client the image falls apart: frames tear, individual splotches protrude in front of objects, and camera rotation stutters.

The reason is not the quality of reconstruction, but that depth ordering, splitting the scene into visibility blocks, and a limit on the number of primitives were not built in — rendering the scene in the browser fails where everything looks flawless on a powerful machine.

The second typical failure is scene mass. A model that actually opens on a workstation weighs more than the delivery channel to the end user: without levels of detail and streaming loading, every visitor pulls the entire volume even though they are viewing one angle.

Interactive 3D reconstruction in this form either does not start or starts after minutes of waiting — and this is not a matter of "optimization later," but of the data storage scheme laid down at the assembly stage.

The third is material edits.

As soon as an object is removed from the source set, the lighting is changed, or an area is re-shot, the stitching of primitives comes apart: foggy clumps appear in place of the removed object, seams at the boundaries of the orbit capture, loss of contact with the floor.

A reconstruction that is computed once for a specific shoot does not survive the first iteration — and therefore does not live in a product.

3D Gaussian Splatting produces a photorealistic image, but a production version also means scene packaging, predictable startup on weak hardware, and repeatable assembly after any edit. We break down how this is covered.

What interactive reconstruction delivers in practice

Gaussian Splatting describes a scene not as a polygonal mesh with textures, but as a cloud of Gaussian primitives with color and density. This yields four effects that the client sees with their own eyes and that we record with measurements before project handover.

Scene loading time is reduced through streaming delivery by levels of detail: first a rough framework arrives, and details arrive as the user explores.

The weight of the scene model drops several times compared with a dense mesh — a model with millions of polygons either does not open on a phone, or opens so slowly that the visitor leaves.

The smoothness of a 3D scene relies not only on a powerful device: primitives are rendered in batches, and detail adapts to the current load.

Response stability is preserved even on weak devices — rotation and zoom do not 'stick,' and the image does not fall apart during fast camera movement.

Displaying an object in the browser ceases to be a separate class of failures: there is no black screen on the first frame, no misaligned textures, and no crashed tab. The scene opens via a link without installing apps and behaves the same on a laptop and a phone.

We tie every effect to a measurement — the weight of delivered data, time to first frame, share of frames without drops. If values diverge from what was agreed, edits go into the scene, not into the client's expectations.

Comparison of approaches to scene reconstruction

There is no universal way to assemble a three-dimensional scene: the choice is determined by the scale of the object, requirements for photorealism, and what should be the result — free viewing, precise geometry, or an editable model.

Below are four options that are realistically chosen between at the start: a trainable Gaussian scene (3D Gaussian Splatting), a point cloud, a polygonal model, and a hybrid.

Scale is the main limiter: Gaussian scenes hold quality as long as the object is shot in one pass with dense overlap, while over large areas data volume and assembly time grow. Therefore territories and long routes are more often assembled hybridly.

We run your source data through a trial assembly and name the option that will withstand both the showcase and further changes.

Implementation stages: from shooting to project handover

The implementation stages of a 3D scene are arranged so that an error on site does not turn into redoing the entire project. Each step ends with an artifact that can be checked before moving to the next.

1. Task and site constraints analysis. We determine what must read up close and what is visible only from afar, and collect constraints: where walking and placing a tripod are allowed, what the lighting and traffic at the site are.

2. Scene plan. We lay out the traversal route, shooting points, frame overlap, and reference objects for alignment. We agree on the plan before traveling — edits on paper are cheaper than a repeat trip.

3. Object shooting. We follow the plan strictly, controlling exposure, focus, and steadiness of movement, and additionally capture control frames to verify geometry.

4. Scene assembly and training. We calibrate cameras, filter out blurry frames, train the model on 3D Gaussian Splatting, and tune parameters so that fine details are preserved without increasing scene size.

5. Testing on target devices. We run the scene on the phones, headsets, and browsers that the client's audience uses: rotation smoothness, first-load time, behavior on a weak network. We close drops before acceptance.

6. Result acceptance and handover. We hand over source data, the assembled scene, build scripts, and a re-shooting protocol if the object changes. We go through the acceptance checklist together, on real devices.

Handover package: scenes, configurations, regulations

After delivery, the client retains not only the assembled scene, but everything needed for its independent operation and development.

The documentation package describes the project structure, links between files, and the rebuild procedure: an engineer who did not participate in development deploys the scene on their own stand without correspondence with us. Acceptance follows the same list — discrepancies are visible before signing the act.

• Project source data — shooting sets sorted by date, camera parameter values, masks of problem areas, and a shooting log: it is visible which frames affect what and what makes sense to re-shoot.
• Assembled scene — the final model, divided into semantic nodes so that editing one fragment does not require rebuilding the whole; next to it are control angles for geometry verification.
• Scene configuration — assembly parameters, viewing boundaries, camera entry points, and lighting settings are moved into separate files rather than hardcoded.
• Scene access rules — roles, export restrictions, key lifetimes; publication in the internal environment and on the external stand are described separately.
• Scene update regulation — the sequence of re-shooting and reassembly, frequency, requirements for source data, and criteria under which a new version is accepted.
• Placement scheme — where source data, finished sets, and backups are stored, how the version is calculated, and how to roll back to the previous set.
• Acceptance instructions — control quality metrics, test angles, and a list of typical defects that are closed before delivery.

Project: interactive tour of an object before and after

The client is an exhibition pavilion where a visitor walks through the exposition independently, and the tour must show the same hall in two states: before reconstruction and after.

The first prototype on classical photogrammetry did not pass the on-site test: the scene weighed too much, opened after dozens of seconds, and on tablets in the hall the camera noticeably lagged behind the gesture. People abandoned the walkthrough halfway and went to the exhibit stand.

What we changed and what we got

Reconstruction was moved to 3D Gaussian Splatting: the scene is described by a set of Gaussians instead of a dense mesh with textures, so with comparable photorealism the weight drops several times.

Next, we divided the space into zones and load them as the user moves, while distant areas are delivered in a simplified form. Separately, we fixed the response budget: camera rotation must keep up with the gesture without stutters on the stand tablets.

Before and after metrics were captured on the same equipment in the same hall.

The first zone opens in a matter of seconds instead of dozens of seconds of waiting, scene weight decreased approximately fourfold, and scene response to gesture stayed within the comfortable threshold.

The share of users reaching the end of the walkthrough grew from 54% to 88% — drop-offs during loading practically disappeared.

The conclusion for future projects is simple: what matters is not the beauty of an individual frame, but the weight and response budget calculated before shooting the object. Therefore we run the scene on the target device before delivery, not after complaints on site.

How 3D reconstruction differs from a manual model

Short answer: they have different sources of geometry. A manual polygonal model is assembled by a person from measurements and drawings — from primitives that can then be broken down into nodes and edited.

A trainable 3D scene is built from a set of photographs and reproduces the object as it is, not as designed.

In 3D Gaussian Splatting, a scene is described by many volumetric primitives: each has its own position, size, transparency, and color depending on the viewing direction.

Therefore highlights, fibers, translucency, worn metal, and uneven coatings are conveyed as they are, without manual material setup. The preparation time is set not by modeling but by shooting: hours of work on site instead of weeks of construction.

Where material accuracy and speed are critical, a trainable scene wins. Repeat shooting captures changes: walls repainted, equipment replaced — the scene is updated, not rebuilt from scratch.

A polygonal model remains the only workable option when editable topology is needed: UV mapping, animation, calculations, embedding into physics, or a configurator with options.

Also if the object has not yet been built, the site has restricted access, and project documentation is available. A trained scene cannot be disassembled into parts — it shows only what was captured in frame.

In practice, the choice is rarely binary: for interactive demonstration or object acceptance we take the scene; for production tasks, a hybrid, where the polygonal base is responsible for structure and the photorealistic shell for accuracy.

Describe your object and task — we will return with a plan and an assessment of which path is shorter in terms of timelines.

Technical questions asked before the start

Before the start, the same technical questions come up: how the source data will behave, what will happen when the scene is updated, how large an object can realistically be shot.

Scale is limited not by technology but by traversal time — we divide a city block into sections and stitch them by common landmarks, so the seam at the boundaries is not visible.

What to do if the scene has changed?

We reassemble only the changed area, not the entire scene: the rest is taken from the previous data set. Replacing a display or rearranging equipment is a few hours and one short additional shoot, not a project from scratch.

Who owns the rights to the scene?

You do. We hand over the source shooting materials, intermediate data, and the final file set, and we fix in the contract that we do not use them for our own purposes.

If the object is restricted, we cut out anything unnecessary before assembly — it is easier to remove during approval than to explain later.

How does the scene work on weak devices?

We cut not the scene but the stream: we load levels of detail as the camera approaches, deliver materials in parts, and limit the number of light sources. On a laptop and tablet it opens without drops, and full detail turns on when the device can handle it.

Let's discuss your scene and come back with an estimate

To start the review, you do not need a ready scene on 3D Gaussian Splatting — materials that already exist for the object are enough. The more complete the source data, the more accurate the project estimate: it shows the real scope of work rather than an approximation.

• Shooting: photos or video of the object walkthrough from different angles. Dense frame overlap reduces the number of blind zones that later have to be re-shot.
• Geometry: measurements, floor plans, or an existing 3D model — we check the scale and proportions of the future scene.
• Interactivity: what the user should be able to do — rotate the scene, zoom into details, switch zones, open object cards.
• Display channels: a browser on a computer, a tablet on site, or an embedded panel — this determines scene weight and rendering requirements on weak devices.
• References and restrictions: examples you like and what must not be shown — closed zones, unsuccessful angles, third-party logos.
• Access and schedule: when shooting is possible, whether there are restrictions on time, lighting, and movement inside the object.

From this set we assemble a work plan: stages, responsibilities, approval points. We select the team composition for the object — a shooting engineer, a 3D artist, a rendering developer, an integrator.

We provide estimates and implementation timelines by stages, not as a single number: this shows exactly what affects the duration.

Describe the task and send the materials — we will discuss and come back with an estimate and work plan.