HINGEROOM

Rehearse the space a cabinet door needs to open.

Comment

Inspiration

A cabinet can fit a room and still be awkward to use: its door needs space along the entire opening motion. Checking only the final position can miss the obstruction it would pass through on the way there.

HINGEROOM turns that overlooked space into something you can explore at full scale. The goal is to help someone compare a furniture arrangement before buying or moving it, with the moving door and its surroundings in the same spatial view.

What it does

The prototype presents a virtual cabinet, hinged door and movable box. Use the angle slider to open the door from 0 to 110 degrees, drag the box across the virtual floor with one hand, and reset the example to compare again. The cabinet and controls stay in world space after initial placement.

The central distinction is between “Current panel: no overlap” and “Path blocked.” In the default example, the door can be clear of the box at 90 degrees even though its route from closed passes through the box. HINGEROOM checks the whole route from closed to the selected angle every time, regardless of which direction the slider last moved.

Words and symbols accompany the cyan and amber path guide. At zero degrees, the interface says “Open to check.” Dimensions are visible and explicitly authored: this is a virtual example, not an automatic room measurement.

How it was built

Devpost Learn's planning guide shaped the approved brief. The prototype was built in Lens Studio with TypeScript and the CLAD/Lens Studio MCP workflow. Code-generated meshes define the cabinet, door and path guide; Spectacles Interaction Kit handles the draggable obstacle, and Spectacles UI Kit supplies the slider and reset button.

Geometry, application state and presentation are separate. The geometry models door thickness and obstacle height as well as their footprints. An adaptive interval calculation checks distance throughout the opening motion. It only reports a clear path after every interval meets a conservative distance bound; an unresolved interval remains blocked. This avoids relying on a few sampled angles or on the final pose alone. The current example uses a 0.5 cm clearance margin.

What was checked

Verification so far is in Lens Studio Preview. Separate geometry regression checks cover contact, height separation, narrow collisions and conservative fallback. LEAF scenarios check fixed-angle examples and exercise real SIK slider, obstacle-drag and reset interactions. World-anchor checks move the simulated camera and verify that the authored objects stay fixed. A separate local IK scenario tests a simulated reset-button interaction.

Screen-coordinate gesture injection was also used to diagnose desktop input. Those diagnostics, simulated IK and Preview interaction tests do not establish that the experience works on physical glasses.

Challenges and limits

The main challenge was keeping the visible motion, interaction collider and clearance calculation in the same coordinate system while preserving the difference between the current pose and the whole opening path.

This prototype uses one manually defined cabinet and one obstacle on an authored virtual floor. It does not scan a room, detect furniture or measure real dimensions. The clearance margin is an example assumption, not a furniture safety tolerance. Physical Specs testing is still needed for tracking, hand interaction, placement, legibility and comfort. The result should support layout exploration, not certify that real furniture is safe to move or use.

What's next

The next useful steps are editable dimensions, other hinge configurations and saved arrangements, followed by trials on physical glasses. These would let people compare practical alternatives while keeping the whole opening path visible.

Built With

Share this project:

Updates

Submission history