Building a 3D Property Showroom Website: Model Packages, Floor Cutaways, and Interior 360 Panoramas

This property-viewing website was developed together with Mxm. The buyer moves through the building in a fixed order: the whole building, a floor, a unit, and finally a 360 panorama of the interior. The data covers two towers, more than 1,000 units, ten unit types, and more than 70 panoramas, and desktop and phone share the same controls. The property-viewing website developed with Mxm is built with three.js and Vite.

Mxm produced the building models, the interior renders, and the 360 panoramas. POLISH built the web side: model packaging and compression, the interaction flow, the surrounding landmarks, and the day and night scenes. General methods for loading and memory are covered in Web 3D performance engineering, and the overall build scope is described in what a 3D interactive website build covers.

How the render master files reach the web page

The render master file is about 1.4 GB and close to 50 million faces. The exterior model used on the web is a reduced version of about 2.06 million faces, split into four model packages by a Blender batch script. The main building and its surroundings came in as separate delivery files, so the packages follow the source files directly.

Models use glTF 2.0, and the specification from The Khronos 3D Formats Working Group, 2021 defines glTF as an open, interoperable transmission format. Geometry is compressed with Draco, and Zhang et al., 2013–2017 define how Draco is used inside glTF. Decoding runs in Web Workers, with four workers at a time on desktop and, on phones, two for the main building and one for the surroundings. Each batch is released as soon as it finishes decoding.

Textures are the main source of download size and GPU memory, and four tiers are prepared: 512, 1024, 2048, and the original image. Tiering rewrites the textures inside the GLB container and leaves the geometry data untouched, with no re-encoding. glTF also has a texture extension that pairs KTX v2 with Basis Universal (Callow et al., 2020), which the engine transcodes into a block-compressed format the GPU supports, while the textures in this project are embedded in the GLB as WebP. Touch devices with a short side under 600 px load the 512 tier, tablets and smaller screens load the 1024 tier, and desktop picks among 1024, 2048, and the original according to memory and screen pixels.

When desktop selects the 2048 or the original tier, the first load uses the 1024 tier. After the opening sequence ends and the screen goes idle, the viewer swaps in the larger images one at a time. Each image downloads and decodes in the background and is uploaded to the GPU only when nobody is interacting, and the swapped-in image is identical, pixel for pixel, to the one a GLB at that tier would load directly. Under a simulated 40 Mbps connection with 40 milliseconds of latency and the cache turned off, the building is visible after about 4.9 seconds and can be operated after about 8.2 seconds. Four sets of textures that are identical across model packages share a single GPU texture.

The shader variants that interactions switch to are compiled while the loading screen is still up. The surroundings and any newly arrived model package join the scene only after the shaders have compiled in parallel through KHR_parallel_shader_compile and the textures have been uploaded frame by frame. These practices line up with the WebGL recommendations in MDN Web Docs, 2026, which name three areas to work on: reducing draw calls, managing texture memory, and compiling all shaders before linking any. Texture tiering and precompilation belong to the last two.

Floor and unit selection: clipping planes and a translucent shell

When a floor is selected, a set of clipping planes cuts away everything above that floor's slab. There are three planes, an upper edge, a lower edge, and a single-tower cut, and the set is attached once at load time to every material that needs cutting. After that, switching the cut on and off or changing floors only changes the position values of the planes, with no shader recompile. On entering a floor, the lower plane sweeps from the ground up to that slab, and the building turns translucent from the bottom up.

The translucent part is a separate shell that shares the main building's geometry. It uses its own unlit shader, draws only what lies below the cutting plane, brightens its edges according to the viewing angle, does not write depth, and renders both faces, so the front and back facades stack into visible layers. The main building has well over a hundred original materials, and converting each one to translucent would force a shader recompile on every switch, whereas a separate shell leaves the original materials alone.

A CAD floor plan is laid flat at the actual slab height of the selected floor, made up of the floor, colored unit areas, and line work. The line work inside units comes from the interior design drawings, while corridors, cores, and elevator lobbies come from the wall lines of the permit drawings, and the coordinate conversion is done and checked at build time. The slab, the unit areas, and the line work use one set of material parameters and share one shader program, so entering a floor adds no compilation. Each colored unit area follows the unit outline in the permit drawings. When a unit is selected, the other units turn gray and the labels hide, and the panel keeps only that unit's information. The back button always returns one level up, so a buyer can step back at any stage.

Interior 360: panorama data organized by unit type

Mxm renders the panoramas of unit interiors and shared amenities as 4096 x 2048 equirectangular images, each with a 512 x 256 low-resolution base image. Panoramas are rendered per unit type, and every unit of the same type shares one set of camera positions, so the panorama count depends on the number of unit types and amenities and is independent of the number of units, and the total is more than 70. Units whose layout is a left-right mirror reuse the same panoramas and are flipped horizontally in code.

Entering a panorama loads the low-resolution base image first. The high-resolution version uploads to the GPU in tiles and then covers the base with a 350-millisecond fade-in. Panoramas are decoded as ImageBitmap, and the CPU-side copy is released after upload. The panorama is mapped onto an inside-out sphere with a default vertical field of view of 110 degrees, adjustable between 32 and 125 degrees, and the inertia after a drag decays independently of the frame rate.

The hotspots that lead to the next room are computed from data at build time. Mxm delivers a camera position file for each viewpoint, and the build script aligns the camera coordinates to the interior floor plan one unit type at a time, using a least-squares fit on the positions of door frames and window frames in the panorama. Each unit type gets its own heading correction, because the starting direction of a panorama differs between scenes by multiples of 90 degrees. For every viewpoint the script records the bearing and plan distance to the neighboring viewpoints and whether a wall lies between the two points, with doors treated as open. A viewpoint that can be seen gets its hotspot directly on it, while a viewpoint behind a wall gets its hotspot at the center of the exit door, and the destination is the nearest viewpoint reachable on foot beyond that door.

When the 3D view enters a 360 panorama, the camera first pushes in toward that unit, the last frame is saved as a snapshot that scales up and fades out, and the panorama's field of view settles from narrow to the default at the same time, which takes about 1.3 seconds. Clicking a hotspot first turns the view for 0.35 seconds and then moves to the next viewpoint over 0.65 seconds. When the system is set to reduced motion, only a cross-fade remains.

The floor plan inset at lower left is one vector SVG per unit type, exported from the ten unit-type areas of the interior design drawings. Each SVG is layered by CAD layer into walls, doors and windows, and furniture, and carries its own media queries: at a display size of 130 px or less only walls, doors, and windows remain, at 340 px or less furniture recedes into a faint background pattern, and the full drawing appears only when the inset is expanded. Below the dot for the current viewpoint, a gold fan marks the viewing direction.

Surroundings and day and night scenes: loaded on demand

The surroundings are about 25 MB and are not loaded by default, and the download starts only when the Surroundings button is pressed. After the model arrives it stays out of the scene at first. The shared textures are set, the sky fog is applied, shaders are compiled off screen, and textures are uploaded frame by frame, and only when all of that is done does the model join the scene, so the first frame of the expansion has no hitch.

The expansion animation takes about 6.4 seconds in two beats. First the camera rises above the roof while the nearby blocks grow outward from the center of the site to about 650 meters. Then the camera slides to a frontal view while the radius sweeps out to 14.5 kilometers on a logarithmic interpolation, which covers the farthest point the camera can see. The leading edge is a glowing line-work band built from a grid in world coordinates, with a floor line every 3.2 meters and a vertical line every 8 meters. All surrounding materials share one set of uniforms, so the animation only changes values and never recompiles a shader, and retracting takes 0.9 seconds.

Landmark labels are DOM elements, and layout projects every label first, calculates the collision avoidance in one pass, and writes only the positions that changed, so the browser is never forced to reflow within a frame. Whether a label is hidden behind a building is decided with a height grid of 8-meter cells, checked every 150 milliseconds. A single ray through the main building costs about 80 milliseconds, and the grid avoids that cost.

The day and night switch changes light, fog, background, and exposure together. All of these are driven by shared uniforms, so switching only changes values and never recompiles a shader, and the night data downloads the first time the view switches to night. Whether a pane of glass on the main building is lit depends on its unit and floor: a whole unit lights up together, and inside a unit the lighting is further divided by room. The unit outlines are rasterized in the browser into a 256 x 256 lookup table. The window lights of the surrounding blocks need no texture download, because the shader generates the window grid from world coordinates and wall direction, and the share of lit windows comes from low-frequency noise at a scale of about 45 meters, so lit windows thin out with distance from the camera.

Phone flow and resource settings

Devices that are mainly touch, including an iPad with a keyboard attached, get a different set of settings applied as soon as the page opens. The sizes of shadows and environment reflections go into the shader's program key, so changing either midway would force a recompile of the whole scene. The flow stays the same: select a floor, select a unit, enter 360, expand the surroundings, and switch day and night, and only the entry points differ: shared-amenity panoramas open from a list at the bottom, the next room is reached with a bottom button, the floor plan inset expands to full width, and the landmark list for the surroundings sits in a bottom drawer.

The geometry in the phone files gets separate handling. Draco primitives with more than 65,536 vertices are split into small chunks at build time and re-encoded with the original quantization parameters, so the decoded floating-point values match the original file bit for bit. At load time, indices, positions, and normals all use 16-bit integers. The maximum angular error of a normal is 0.002 degrees, and the GPU memory for geometry drops by about one third.

Desktop and phone share the same render cadence. When the picture is still, nothing is drawn at all. During a drag, each frame draws only a block at 0.625 times the canvas size in the lower-left corner and stretches it, and after the hand stops, eight sub-pixel jittered samples are accumulated into a full-resolution image. When 20 consecutive frames exceed 1.25 times the display refresh interval, the pixel density drops by 0.25 each time, down to a minimum of 1.0, and if a phone still drops frames at the minimum, the frame rate is capped at 30 fps. Measured results decide which features stay on the phone and which are desktop only, and the method is covered in memory budgets for 3D on phones.

Where Mxm's work and POLISH's work meet

Mxm and POLISH connect through agreed conventions. Package names and component names are settled by both sides up front, the web side identifies the towers, the podium, the surrounding buildings, and the roads by name, and the names also decide which components take part in the cutaway. If either side changes a name, the other side changes it in step. How externally produced models are received and accepted is covered in receiving and accepting outsourced 3D models, and the method for measuring before and after reduction and compression is covered in a before-and-after comparison table for 3D model optimization.

Which projects can use the same path

Residential and commercial office developments, along with other projects where the buyer moves step by step from the whole into a space, can reuse the same path. Two checks decide it: whether the space has levels such as whole, zone, unit, and interior, and whether the buyer needs to see the interior before deciding. Another example of seeing the finished result before deciding is previewing a custom sign before payment.

Cases where this path is not a fit

• Projects that do not yet have a building model and interior renders. The interaction path is built on these two assets, so web development starts once the assets are ready.
• Small projects with a single unit type. For one building with few units, one set of panoramas plus a floor plan is enough, and the whole-building floor selection level is not needed.
• Projects that must show live availability and prices on the page. This path presents the space, and the sales control data has to be planned and connected separately.

What to prepare before starting

Four things need to be ready first.

• Who produces the building model and the interior renders, and the size and format of the master files
• The number of units, unit types, and panoramas
• Whether buyers mainly use phones or desktop, and which features the phone version must keep
• The list of surrounding landmarks, and the requirements for the day and night scenes

What drives the cost is covered in what determines the cost of a 3D website. Once these are ready, the next step is to discuss the plan for a property-viewing website.