Snapshot

2. Reintegrated validated interactions into the 3D Studio prototype;
3. Defined reusable rules for shared picking, feature registration, and testing. | | Current Status | 3D Studio has been consolidated; the next step is to turn it into a shared prototyping foundation for the team. |

<aside>

Live Demo ↗

</aside>

TL;DR

Scanat’s core interactions happen directly inside 3D models. Drag targets, camera motion, spatial orientation, occlusion, and conflicts between multiple tools are difficult to evaluate in Figma alone.

Starting in Feb 2026, I used AI-assisted coding to build working 3D prototypes: first creating focused demos to validate interaction feel and geometric logic, then consolidating the validated features into 3D Studio in August to test state and interaction conflicts in a shared product environment.

My contribution: I independently implemented the prototypes and, during integration, clarified code responsibilities, unified picking, standardized feature registration, and defined basic testing rules.

1. Problem

Static designs could not validate 3D interaction

Scanat users measure, annotate, and edit directly inside 3D models. Figma can communicate interface structure, but it cannot reliably show whether drag targets are easy to hit, whether controls stay stable as the camera moves, whether spatial orientation feels correct, or how animation and occlusion behave in a running environment.

I therefore brought working prototypes into the design process and used the browser to test these behaviors directly.

Isolated demos could not validate feature coexistence

Focused demos were effective for isolated problems, but in the real product, notes, measurements, Gizmos, camera controls, and model scaling all operate in the same scene. As the demos grew, I needed to validate shared pointer events, cross-tool state, coordinate changes, and visual hierarchy.

That became the main reason to build a consolidated prototype.

2. Approach

3D Studio was not planned as a platform from the beginning. It emerged gradually from real project needs.

Phase 1: LidarLab 3D

In Feb 2026, I built LidarLab 3D to test whether point-cloud loading, distance measurement, and volume visualization were feasible in the browser. Some later visualization work for Scanat Volume directly reused findings from these experiments.

This version was intentionally a one-off validation tool rather than an extensible platform. At this stage, the priority was to quickly verify 3D feasibility and interaction behavior; building a full architecture before the requirements stabilized would only have added maintenance cost.

Phase 2: Focused Demos

From May to Jul 2026, new 3D interaction needs emerged. Rather than extending the old prototype, I created a separate demo for each problem. Each demo contained only the minimum functionality required for that validation, keeping existing states and interactions from interfering with the test.

Each demo addressed one problem, making it faster to tune the interaction and isolate edge cases.

Phase 3: Consolidating into 3D Studio

By Aug 2026, enough isolated interaction problems had accumulated that I reorganized the earlier prototypes and moved validated behaviors into 3D Studio, a workspace closer to the real Scanat product environment.

Focused demos remained useful for fast single-problem testing, while 3D Studio was used to evaluate interaction, state, and performance when features coexisted.

3. Design Decisions

Decision 1: Keep both focused demos and the integrated prototype

The two prototype types served different purposes:

Complex interactions could still be validated quickly in a focused demo first, then moved into 3D Studio to test coexistence in a product-like environment.

Decision 2: Refactor the prototype structure before integrating features

When integration began, the core LidarViewer.tsx file had grown to 3,543 lines, with components, algorithms, and panel UI mixed together. Adding more focused demos on top of that would have made future issues difficult to isolate.

I first separated responsibilities into:

• core/: geometry and algorithms;
• viewer/: foundational 3D capabilities such as scene and camera;
• features/: isolated directories for individual features.

After the refactor, the main file dropped to about 1,559 lines and primarily handled scene composition and shell-level state.

Decision 3: Define shared interaction rules for feature coexistence

As notes, measurements, Gizmos, and other features began sharing the same 3D scene, the question was no longer whether each demo worked in isolation, but whether the tools interfered with one another. A single click, for example, could trigger multiple tools or cause features to compete for the same interaction.

I first defined shared input rules: the active task and tool state determine which feature responds to an interaction, preventing multiple features from processing the same input. Once the rule was clear, I implemented it in the working prototype with AI assistance.

Feature entry points: place them based on when they are needed. Some tools are used continuously, while others only make sense after an object is selected. I placed entry points in the toolbar, side panel, or selection actions based on task state instead of flattening every feature into the same hierarchy. With AI assistance, I then turned this into a reusable feature-registration pattern.

Validation approach: verify logic first, then interaction feel. 3D interactions such as Gizmos involve both spatial computation and hands-on behavior. Mixing the two makes it difficult to tell whether an issue comes from the interaction model or the implementation. I first validated movement, rotation, and other core logic with AI assistance, then tested hit areas, drag feel, and behavior from different viewpoints in the browser.

Integration also surfaced visibility-state and browser-runtime issues that static designs could not reveal. For complex 3D interactions, working prototypes therefore became more than a presentation artifact—they were a way to expose edge cases during the design process itself.

4. Prototype Examples

3D Studio Integrated Workspace

Runs multiple 3D features together in a product-like interface to inspect cross-tool state and interaction conflicts.

https://res.cloudinary.com/v7b2p5ho/video/upload/v1787649476/crxau7l9ekh7wlxir1r6.mov

Focused Demo Entry Points

Each feature still keeps its own standalone page. When a single interaction needs refinement, I can test it quickly in the focused demo and then sync the validated version back into 3D Studio.

https://res.cloudinary.com/v7b2p5ho/video/upload/v1787649478/bgya5ih3ruhn73wy071d.mov

5. Outcome

Prototype output: From Feb to Aug 2026, I built LidarLab 3D, five focused demos, and the consolidated 3D Studio.

Product application: Several visual and interaction explorations were carried into production specifications and parameter handoff—especially volume measurement, the cube Gizmo, and scale changes—reducing design–engineering back-and-forth. These features have since shipped, with interaction and animation behavior remaining close to the prototypes.

Internal feedback: Animation and interaction parameters from the cube Gizmo, reset-view, and scale-change prototypes were applied directly in production. Engineers reported that this reduced implementation time and trial-and-error.

6. Reflection 反思

1. Choose prototype fidelity based on the problem. Focused demos are better for quickly validating a single interaction, while an integrated prototype is better for checking conflicts in a product-like environment. They complement rather than replace each other.
2. Repeatedly reused prototypes need basic engineering boundaries. One-off demos can stay lightweight, but once multiple features begin to coexist, responsibilities, input handling, and testing need clearer structure.
3. AI shortens implementation and debugging time; it does not replace product judgment. Which interactions to keep and how they should fit the current product still need to be decided in context.