Calculation method and concept definitions
The eight concepts behind SPACEFIT, the exact inputs and unit rules, the doorway and room checks, a reproducible worked example, and the limits of the assessment.
Eight terms this tool actually uses
Each definition below describes what the current code does. The English term is kept in both languages so the same concept can be cited unambiguously.
- Furniture DimensionsFurniture Dimensions
The three orthogonal extents of one piece of furniture: length, width and height. SPACEFIT stores all three as canonical millimetres and treats the item as a rectangular block. Legs, arms, handles, detachable parts, upholstery compression and non-rectangular outlines are not modelled.
Where this comes from:
geometry.lengthMm,geometry.widthMm,geometry.heightMm- Doorway ClearanceDoorway Clearance
The net, unobstructed opening of a doorway: clear width and clear height, with an optional frame depth and an optional extra operating clearance. The value must be the smallest usable aperture, not the outer frame size. A missing frame depth is reported as a blocking limitation rather than guessed.
Where this comes from:
clearWidthMm,clearHeightMm,frameDepthMm,MISSING_FRAME_DEPTH- Projected WidthProjected Width
For one tested pose, the horizontal extent of the furniture bounding box on the doorway section. It is derived from the axis-aligned bounding box of the rotated block, so it changes when the pose changes. It is compared against the net clear width plus the requested extra clearance.
Where this comes from:
projectedWidthMm,remainingWidthMm- Projected HeightProjected Height
For one tested pose, the vertical extent of the furniture bounding box on the doorway section. Together with projected width it forms the rectangular section used by the doorway check; the depth of the block is not part of that section test.
Where this comes from:
projectedHeightMm,remainingHeightMm,SECTION_ONLY- Bounding BoxBounding Box
The axis-aligned box that encloses the rotated furniture block. Every comparison in this tool uses that box, never a detailed mesh. A pass therefore means the enclosing box fits, not that every contour of the real object does.
Where this comes from:
BOUNDING_BOX_ONLY,ORIENTATION_IDS- OrientationOrientation
One of six axis-aligned poses of the block. Each pose applies a 3 by 3 rotation matrix combined as Rz then Ry then Rx; the bounding box is the absolute value of that matrix multiplied by the local dimension vector. Continuous or arbitrary angles are not searched.
Where this comes from:
Rz,Ry,Rx,AXIS_ALIGNED_POSES_ONLY- Room ClearanceRoom Clearance
A static volume comparison between the oriented furniture box and a rectangular room of the supplied width, length and height. It says whether the box fits inside the room volume in that pose; it does not check where the door is, how the item is carried in, or where it is finally placed.
Where this comes from:
STATIC_VOLUME_ONLY,ROOM_PATH_NOT_MODELLED- Collision DetectionCollision Detection
The overlap and clearance check computed from the six real faces of the axis-aligned boxes: required versus available extents, remaining clearance and excess. A flush contact with zero clearance is reported as a boundary case, not silently ignored. This is a geometric overlap test, not a moving-path simulation.
Where this comes from:
dimensionComparisons,ZERO_CLEARANCE,PATH_NOT_MODELLED
How the calculation works
Inputs, unit rules, pose handling, the doorway section, spare-space judgement and the scenarios this assessment does not cover. The named limitation codes are the same ones emitted by the engine.
Which inputs are used
Furniture length, width and height; doorway clear width, clear height and optional frame depth; room width, length and height; an optional extra operating clearance; the selected pose; and the display unit.
A genuinely unknown frame depth is stored as null. The engine then raises MISSING_FRAME_DEPTH as a blocking limitation and the overall verdict becomes conditional; no value is invented to fill the gap. Invalid numeric input returns a structured INVALID_INPUT failure instead of a fabricated fit result.
Disclosed in code as: clearWidthMm · frameDepthMm · MISSING_FRAME_DEPTH · INVALID_INPUT
How units are unified
Millimetres are the one normative unit inside the calculation. Inch and foot inputs use the exact factors 1 in = 25.4 mm and 1 ft = 304.8 mm; conversions are not rounded.
The 3D scene converts millimetres to metres only at render time. Dimension parsing rejects thousands separators, suffixes, NaN, zero and negative values rather than silently coercing them.
Disclosed in code as: MM_PER_UNIT · toMillimetres · millimetresToMetres
How furniture poses are handled
Six axis-aligned poses are tested. For each, a 3 by 3 rotation matrix Rz, Ry then Rx is applied; the axis-aligned bounding box is |R| multiplied by the local dimension vector. Projected width and projected height are read from that box.
Only those six poses are tested. No continuous-angle search is performed, so a pose between them that might fit is outside the answered question.
Disclosed in code as: ORIENTATION_IDS · AXIS_ALIGNED_POSES_ONLY · projectedWidthMm
How the doorway section is computed
The doorway check is a section-only comparison: the rectangle formed by projected width and projected height is compared with the net clear aperture, including the requested extra operating clearance. The depth of the furniture in the passing direction is not part of this section test.
The door leaf, its swing, door hardware, thresholds and obstacles are not modelled. Frame-depth rotation and the actual transport path are not modelled either. Each of these limits is emitted as a named limitation code in the engine result.
Disclosed in code as: SECTION_ONLY · PATH_NOT_MODELLED · DOOR_LEAF_AND_OBSTACLES_NOT_MODELLED · FRAME_DEPTH_ROTATION_NOT_MODELLED
How spare space is judged
For each comparison the engine reports requiredMm, availableMm and remainingMm, where remaining is available minus required. These rows come from the real box faces, not from the clamped interaction bounds used by the 3D drag control.
The doorway and room checks stay separate. Any failing local check produces FAIL; any conditional local check, any blocking limitation, or the absence of one single pose satisfying both checks produces CONDITIONAL; otherwise the result is PASS. The UI only renders overallStatus and verdictReasons from that one engine result.
Disclosed in code as: dimensionComparisons · NO_SINGLE_POSE_FITS_BOTH · overallStatus · verdictReasons
What is not supported
Continuous-angle rotation, carrying routes, turning a piece through a hallway, the door leaf and obstacles, rotation through the frame depth, in-room manoeuvring and final placement are all outside this assessment. Both the doorway and room results are explicitly scoped statements, not a moving simulation.
Interactive dragging in the 3D tool is limited to a static-position assessment: moving the item changes the visual feedback but does not rewrite the overall fit verdict. This scope is disclosed on the tool page and in the engine result.
Disclosed in code as: AXIS_ALIGNED_POSES_ONLY · PATH_NOT_MODELLED · ROOM_PATH_NOT_MODELLED · STATIC_POSITION_ONLY
Five questions that are not the same question
A doorway size comparison, a section fit at one pose, a rotated projection, a room volume and a real carrying route are five different questions. SPACEFIT answers the first four — fully or partly — and refuses the fifth.
| Question | Status | What the engine does | What it does not prove |
|---|---|---|---|
01Is the furniture smaller than the doorway?dimensionComparisonsclearWidthclearHeight | Answered | Compares the furniture width and height with the clear opening and reports the raw difference in millimetres. | Only that two numbers are smaller than two other numbers. It says nothing about a tilted or rotated approach. |
02Does one restricted pose fit the doorway section?sectionStatusOrientationIdSECTION_ONLY | Answered | Tests each of the six axis-aligned poses separately and reports, per pose, whether the projected section fits the aperture. | A section fit at one specific pose. The item still has to reach the doorway in that pose. |
03How large is the projection after rotation?rotatedBoxAabbprojectOrientationrotationMatrixXYZ | Answered | Computes the exact axis-aligned bounding box of the rotated box from the |R| · h matrix, for quarter turns and for any yaw. | The size of the box that has to pass the plane. It is neither the furniture surface nor a swept volume. |
04Does the room space contain the furniture?analyzeRoomSTATIC_VOLUME_ONLYROOM_PATH_NOT_MODELLED | Partly answered | Compares the oriented bounding box with a static rectangular room on width, length and height, and reports the remaining space per axis. | A static volume comparison. Moving the item into position inside the room, turning it there, or opening a door is not simulated. |
05Is a complete real carrying path feasible?PATH_NOT_MODELLEDDOOR_LEAF_AND_OBSTACLES_NOT_MODELLEDCONDITIONAL | Not answered | Nothing. No route, stair, corner, corridor or door swing is modelled, so the engine returns CONDITIONAL and names the missing evidence. | This is the question the product does not answer. Claiming a path result here would be the most damaging overstatement it could make. |
The last row is the boundary of the product. A doorway calculation cannot be stretched into a carrying-route calculation, and this page does not try.
How PASS, CONDITIONAL and FAIL are produced
The verdict is not chosen by the interface. Two local checks are merged in a fixed order, and any blocking limitation downgrades the result before the fall-through.
- FAIL
Any local check returns FAIL.
No tested pose satisfies that check, so no pose can satisfy the whole set. The blocking axis and the millimetre excess are reported.
sectionStatusroomFitStatus - CONDITIONAL
Any local check is CONDITIONAL, or no single pose satisfies both the doorway and the room, or a blocking limitation exists.
The geometry is not decided by the data supplied. The verdict names which pose each check needed and what evidence is missing.
NO_SINGLE_POSE_FITS_BOTHREQUIRES_POSE_CHANGE - PASS
Every tested check passes with the requested operating margin, and at least one pose satisfies both the doorway and the room.
The strongest statement the engine can make. It still does not assert that a real carrying route exists.
overallStatusverdictReasons
What this version does not simulate
Every item below sits outside the model. None of them is implied by a PASS, and none of them is quietly approximated.
Modelled
- A rectangular block with three orthogonal extents
- Six axis-aligned poses, each with an exact rotated bounding box
- A rectangular doorway section, clear width and clear height
- A static rectangular room volume on three axes
Not modelled
- Stairs and changes of levelA clear doorway section says nothing about a stair turn or a landing.
- Corridors, corners and turnsThe swept volume of a long item through a 90° turn is not computed.
- Door leaf, swing and frame revealAn open door reduces the usable aperture; the model uses the clear opening only.
- Handles, knobs and protruding fittingsA handle can add tens of millimetres to the real projected width.
- Skirting, radiators and fixed obstaclesAnything that narrows the real passage is outside the model.
- Non-rectangular outlines, legs and armsThe item is a rectangular block; a shaped sofa is measured by its outer box.
- Upholstery compression and flexA mattress that bends is modelled as a rigid box, which is conservative.
- Continuous-angle posesOnly the six axis-aligned poses are tested; arbitrary angles are not searched.
If a real decision depends on an item in the right-hand column, the honest answer is that this tool cannot decide it yet.
One example, computed live
The article supplies input numbers only. Status and comparison rows are produced on every render by the same analyzeFurnitureFit() entry point used by the calculator.
Input data
| Item | Example cabinet |
|---|---|
| Length | 1200 mm |
| Width | 700 mm |
| Height | 1900 mm |
| Clear width | 800 mm |
| Clear height | 2050 mm |
| Frame depth | 120 mm |
| Room width | 3200 mm |
| Room length | 4000 mm |
| Room height | 2600 mm |
| Extra clearance | 0 mm |
| Selected pose | Upright |
Units
All values below are canonical millimetres (mm).
Calculation process
- 01Convert every supplied dimension to canonical millimetres; all values here are already in mm.
- 02For the selected upright pose, build the axis-aligned bounding box using the Rz, Ry then Rx rotation matrix.
- 03Read the projected width and projected height from that box and compare them with the 800 mm by 2050 mm net aperture.
- 04Compare the same box with the 3200 mm by 4000 mm by 2600 mm room as a static volume.
- 05Read the status and the comparison rows from the engine result below; no number in this list is a verdict.
Output (live engine result)
Computed at render time by the current engine; no verdict is copied into prose.
| Comparison | Required (mm) | Available (mm) | Remaining (mm) |
|---|---|---|---|
| Doorway clear width | 700 | 800 | 100 |
| Doorway clear height | 1900 | 2050 | 150 |
| Room width | 700 | 3200 | 2500 |
| Room length | 1200 | 4000 | 2800 |
| Room height | 1900 | 2600 | 700 |
Calculation version 2.0.0
Applicable range
Applies to a rectangular block, one of six axis-aligned poses, a rectangular doorway section and a rectangular room, with all dimensions supplied in millimetres.
Limitations
- The carrying route, door leaf and turning space are not modelled (PATH_NOT_MODELLED).
- Only six axis-aligned poses are tested; continuous angles are not searched (AXIS_ALIGNED_POSES_ONLY).
- The room result is a static volume comparison, not an in-room manoeuvring check (ROOM_PATH_NOT_MODELLED).
07 / Maintenance
Dates, responsibility and version
- Published
- Updated
- Calculation version
- 2.0.0
- Authorship
- No individually credited author; maintained together with the code in this repository.
- Maintenance responsibility
- These pages are maintained together with the calculation engine in this repository. A change to the geometry or verdict logic requires the published method statement and its automated checks to be updated in the same change. There is no separately credited editorial team and no external reviewer.
08 / Trust
What supports this content
- 01
This page does not claim expert authorship, professional qualifications, laboratory testing, certification or corporate endorsement. None exist for this project.
- 02
Definitions, units, limitation codes and the calculation version on this page describe the code in this repository. The worked example is computed at render time by the same analyzeFurnitureFit() entry point used by the calculator.
- 03
Automated unit tests, production HTML assertions and real-browser checks are the verification evidence available here. No measured Core Web Vitals, search-ranking, traffic or third-party audit data is claimed.
- 04
Clear definitions and disclosed boundaries may help an AI search system understand the content. No AI citation, ranking or rich result is promised.