Making Local 3D Furniture Portable in a Vue 2 Indoor-Map SDK

zyl19950114 — Thu, 06 Aug 2026 02:11:08 +0000

An indoor map stops being portable when every chair, desk, or fixture still depends on a private model URL.

KiMap exports now keep furniture metadata in kidata.furnitures and model content in kidata.models. Each furniture item points to its embedded model through modelRef, so the Vue 2 SDK can parse OBJ, FBX, GLB, or glTF content from memory and restore position, rotation, scale, size, and material settings without a separate furniture server.

The compatibility requirement mattered just as much as the new path. Existing integrations can continue providing a .kimap URL, while upload-driven applications can pass kimapContent, kidataContent, and kithemeContent directly.

The SDK is MIT licensed:
https://github.com/zyl19950114/kimap-vue2-sdk

You can test the editor example without signing in:
https://www.kimap.cc/editor/example?utm_source=devto&utm_medium=article&utm_campaign=early_access&utm_content=sdk_followup

The most useful feedback is specific: which model format, loading lifecycle, or scene-performance limit would block your integration?

Building an Editable 3D Indoor Map in the Browser

zyl19950114 — Wed, 05 Aug 2026 03:56:10 +0000

Indoor maps are often treated as a rendering problem: take a floor plan, extrude a few walls, and display the result. That is useful for a viewer, but it breaks down when a team needs to edit a real space, place assets, or hand the result to another application.

We are building KiMap around a different boundary: turn a floor plan into an editable indoor scene in the browser, then keep the resulting structure useful for an SDK consumer.

Why a floor plan is not enough

A production indoor workflow needs more than a textured image on a plane. At minimum, the editor has to preserve the relationships between walls, floors, rooms, openings, and the objects placed in the space. Those relationships determine whether the result can later support navigation, facility workflows, a digital twin, or a custom web experience.

That is why the current KiMap workflow starts with structure. You can define the indoor geometry, inspect it in 2D and 3D, and keep editing instead of committing to a static export too early.

The browser editor boundary

The editor is built with React and Three.js. The goal is not to replace every DCC tool. It is to make the early spatial workflow accessible to teams that need to test an indoor experience before investing in a full custom pipeline.

The parts we are concentrating on are:

editable floor-plan structure and bounded spaces
2D and 3D scene inspection in the same workflow
reusable 3D furniture and local asset handling
saving an indoor project without dropping the referenced model data
a path toward SDK-oriented rendering and integration

The last point matters. A scene that looks correct in an editor is not automatically useful to an application. We want the data boundary to be explicit enough that an SDK consumer can load the geometry and assets without rebuilding the scene from scratch.

What we are testing next

KiMap is in free early access. The most useful feedback is not generic interest; it is a concrete blocker from someone building an indoor-navigation, GIS, WebGL, facility, or digital-twin workflow.

Try the live example without creating an account:

Open the KiMap example

After trying it, I would especially value answers to three questions:

Which indoor data model or export format would your stack require?
Where would this editing workflow conflict with your real building or facility data?
What API or model-loading behavior would you need before integrating it?

Early access is free and no credit card is required. There is a feedback action inside the example, or you can reach the team at kimap.founder@gmail.com.

DEV Community: zyl19950114

Making Local 3D Furniture Portable in a Vue 2 Indoor-Map SDK

Building an Editable 3D Indoor Map in the Browser

Why a floor plan is not enough

The browser editor boundary

What we are testing next