Spatial Competence Benchmark
Organizations: Independent Researcher · Maptek
Abstract
Spatial competence is the quality of maintaining a consistent internal representation of an environment and using it to infer discrete structure and plan actions under constraints. Prevailing spatial evaluations for large models are limited to probing isolated primitives through 3D transformations or visual question answering. We introduce the Spatial Competence Benchmark (SCBench), spanning three hierarchical capability buckets whose tasks require executable outputs verified by deterministic checkers or simulator-based evaluators. On SCBench, three frontier models exhibit monotonically decreasing accuracy up the capability ladder. Sweeping output-token caps shows that accuracy gains concentrate at low budgets and saturate quickly, and failures are dominated by locally plausible geometry that breaks global constraints. We release the task generators, verifiers, and visualisation tooling.
Figures & tables
| Bucket | Claude Sonnet 4.5 | Gemini 3 Pro Preview | GPT-5.2 | |
|---|---|---|---|---|
| Axiomatic | 75 | 49.3 +6.7 | 81.3 -6.7 | 74.7 -4.0 |
| Constructive | 171 | 30.2 +4.3 | 51.4 +12.3 | 51.9 +15.0 |
| Planning | 39 | 27.5 -7.8 | 39.0 +23.6 | 50.0 -8.3 |
| Overall | 285 | 34.9 +3.2 | 57.6 +8.8 | 57.6 +6.8 |
Appendix figures & tables63 assets
Supplementary material from the paper’s appendix.
Appendix
| Task | Claude Sonnet 4.5 | Gemini 3 Pro Preview | GPT-5.2 | |
|---|---|---|---|---|
| Axiomatic | ||||
| Topology Enumeration | 10 | 40.0 +20.0 | 100.0 -50.0 | 30.0 0.0 |
| Enumerate Edges | 8 | 12.5 +50.0 | 75.0 0.0 | 100.0 -12.5 |
| Classify Behaviour | 13 | 38.5 0.0 | 46.2 0.0 | 53.8 -7.7 |
| Half-Subdivision Neighbours | 17 | 58.8 -23.5 | 88.2 0.0 | 82.4 -5.9 |
| Two Segments | 27 | 63.0 +11.1 | 88.9 0.0 | 88.9 0.0 |
| OpenAI | Anthropic | ||
| Model alias | gpt-5.2 | claude-sonnet-4-5 | gemini-3-pro-preview |
| Temperature | Provider default | Provider default | Provider default |
| Reasoning | effort=xhigh | thinking enabled (max) | thinking_budget=HIGH |
| Tools | code_interpreter , | code_execution , | code_execution , |
| web_search | web_search | google_search |
| Step | Check |
|---|---|
| 1 | Each brick not on the ground must connect to another brick (up or down) |
| 2 | Bricks must align in X/Y to the 8mm stud grid of any blocks they intersect the studs of |
| 3 | No two bricks may occupy the same volume |
| 4 | Connected bricks must not form a part with a centre of mass outside of the part’s ground footprint |
| 5 | No bricks can be below ground, entirely within the inner hemisphere, or entirely outside of the outer hemisphere |
| Consistency check |
|---|
| Empty lists, not 3D, invalid point Ids, NaN positions |
| Degenerate faces and duplicate vertices |
| Edge manifold check |
| Watertightness |
| Self intersecting face check |
| Non-planar face check |
| Step | Check |
|---|---|
| 1 | Orientation quaternions are checked for normalisation, within 1% ( 75% penalty) |
| 2 | Intersection check ( 50% penalty) |
| 3 | Projection and 2D CSG is performed in OpenSCAD |
| 4 | Score calculated from 2D CSG areas of intersection, overlap, and symmetric difference |
| Common mistake |
|---|
| The tetrahedron centre of rotation is not its centre of mass |
| Normalisation of quaternions; this is clearly asked for in the prompt |
| If they try to solve the problem in 2D without considering 3D, the tetrahedra will intersect |
| Step | Check |
|---|---|
| 1 | Exact number of voxels required |
| 2 | No repeated voxel coordinates |
| 3 | All coordinates within [0, N-1] |
| 4 | Every (x,y) pair must have at least one voxel at some z |
| 5 | Every (x,z) pair must have at least one voxel at some y |
| 6 | Every (y,z) pair must have at least one voxel at some x |
| Rule |
|---|
| Grid must be filled in fully and of size Width Height |
| No single elevation value may occupy > 30% of cells |
| There must only be one solution |
| The path must visit > 20% of cells |
| You can walk to a neighbouring cell if the elevation is +/ 1 |
| If a neighbouring cell has a drop 2, and then there’s a cell at the same elevation, you can jump |
| Step | Check |
|---|---|
| 1 | Trivial things are checked: the grid is square, correctly dimensioned, heights are distributed |
| 2 | Breadth-first search (BFS) is used to find the shortest path, including jumps |
| 3 | Depth-first search (DFS) is used to find articulation points and discover any ‘bridges’ implying multiple paths |
| Step | Check |
|---|---|
| 1 | First the grader checks for forbidden characters. After removing ‘return’, ‘def’ and ‘f’, there must only be x, y, digits, operators, and whitespace |
| 2 | Assuming that safety check passes, the code is compiled and executed |
| 3 | f(x,y) is evaluated at every grid cell |
| 4 | The score is recorded as a fraction of correctly classified cells |
| Step | Action |
|---|---|
| 1 | Check a cache of known, solved, subproblems against the grid, seeing if the particular patterns of obstacles have been seen before. Check from largest to smallest. If so, excellent. Mark that chunk as solved |
| 2 | Split remaining grid into 2x2 chunks, mark as either solvable (all 4 empty) or unsolvable (has obstacles) |
| 3 | Unsolvable chunks grow by absorbing neighbors until solvable |
| 4 | Once solvable, attempt to solve using DFS solver. If solved, cache it, otherwise grow |
| 5 | Chunks merge when they collide during growth. If chunk size gets too big for DFS, subdivide or restart |
| 6 | Once obstacle chunks are solved, grow open space chunks into similar-sized chunks |
| Step | Check |
|---|---|
| 1 | Path length must equal the number of valid (non-blocked) cells |
| 2 | All coordinates within bounds of the grid |
| 3 | Path may not visit blocked cells |
| 4 | Each consecutive pair must be 4-connected / side adjacent |
| 5 | Each cell visited exactly once |
| 6 | The last cell must be adjacent to the first |
| Step | Check |
|---|---|
| 1 | Path must begin at specified start |
| 2 | Each step must have correct number of coordinates |
| 3 | Each step changes exactly one coordinate by 1 |
| 4 | All positions within grid extents |
| 5 | No position may coincide with a wall |
| 6 | Snake body grows; cannot revisit own path |
| Stage | Check |
|---|---|
| 1. Basic validation | Minimum point count |
| Loop closure (last point 1m away from first) | |
| No duplicate vertices | |
| Within bounds | |
| 2. Segment analysis | Compute all line segments |
| Detect and count intersections |
| Pass | People | Building width |
|---|---|---|
| 0 | 4 | 2m |
| 1 | 20 | 4m |
| 2 | 40 | 6m |
| 3 | 80 | 8m |
| 4 | 150 | 10m |
| 5 | 200 | 7m |
| Step | Check |
|---|---|
| 1 | Correct number of people |
| 2 | All positions are numeric and 2D |
| 3 | Each person within maximum distance from building center |
| 4 | Person bounding boxes may not intersect building |
| 5 | No overlapping bounding boxes |
| Step | Check |
|---|---|
| 1 | Individual box sizes are counted, and we check to make sure that the correct count of each size is present |
| 2 | We check for overlaps: no two boxes may intersect or overlap |
| 3 | Compute bounding box of all placed boxes. Efficiency = total_prism_volume / bounding_box_volume |
| 4 | If perfect packing is theoretically possible: score = efficiency. Otherwise: score scaled relative to theoretical maximum |
| # | Requirement |
|---|---|
| 1 | A lake of at least 36 voxels in surface area |
| 2 | 3 unconnected bodies of water, each at least |
| 3 | A lake of at least 2 voxels at |
| 4 | An underground lake of at least 10 voxels in volume but no water voxels are visible from above |
| 5 | 3 lakes on 3 different z levels |
| 6 | A lake at least 6 voxels deep |
| Step | Check |
|---|---|
| 1 | Apply earthworks: modify terrain grid per model instructions |
| 2 | Rock stability simulation: floating rock (disconnected) falls until supported |
| 3 | Water simulation: drop individual water voxels from above (water falls until hitting rock or other water); flood-fill for pooling behavior; water reaching grid edge drains away; iterate until water stabilizes |
| 4 | Evaluation against target: count water surface area; count disconnected water bodies; check water at specific Z levels; check if water is visible from above; measure exact volumes |
| Step | Action |
|---|---|
| 1 | When detonation occurs at (x, y, depth), the heightmap is reduced by depth |
| 2 | (Depth 4) spheres in a vertical stack are added to a PyBullet sim at x,y |
| 3 | The simulation runs until stable |
| 4 | Where each sphere ended up, the heightmap there is raised pro-rata |
| 5 | Rocks that fall off the world are lost |
| Subpass | Check |
|---|---|
| 0: Basic validation | Exactly 10 parts; each part is or generates valid STL; non-zero volume; watertight meshes; consistent face winding; no non-manifold geometry; single connected body per part |
| 1: Printability | Parts fit in build volume ( ); rest on plane; sufficient bed contact area ( mm 2 ); no large unsupported overhangs; will not fall over during printing |
| 2: Bar gap verification | 100 randomly placed cubes, per part, are used to check that: 40mm cubes can pass through gaps (gap 50mm) due to at least one intersection test resulting in a zero volume per part; 101mm cubes cannot pass through (gap 100mm), as all intersections must have a positive volume |
| 3: Assembly size | Assembled cage fits 350 350 700 internal space; not larger than 380 380 740 external |
| 4: Rod clearance | 6mm rod passes through corners without intersection; 16mm rod blocked (adequate material around holes) |
| 5: Part interference | No two parts intersect when assembled. All 90 combinations are checked |
| Digit 8 constraints |
|---|
| Cannot be printed on its long or short side (bridge overhangs) |
| When printed flat, must not occur after any number except 8 (or the start) |
| Regex branch |
|---|
| ^[012345679,]+ |
| ^8[012345679,]+ |
| ^88[012345679,]+ |
| ^888,[012345679,]+ |
| ^8,888[012345679,]+ |
| ^88,888[012345679,]+ |
| Step | Check |
|---|---|
| 1 | Triplet constraint. No sequence of 3 consecutive digits repeated (constrains the search space to prevent infinite solutions) |
| 2 | Printability. Check for overhangs in each digit’s orientation. 8 cannot be printed on its long or short side; 7 can be printed on its head and side but not its base; 3 can only go on its long side |
| 3 | Stackability. Flat-on-flat: determined by which segments are in use. 7 can go on 3, but not vice versa. 6 cannot go on 9 flat, but can when rotated 180° or flipped. Only 7s, 3s, and 1s can go non-flat. Only vertical 1 “spires” can go on top of non-flat 3s or 7s |
| 4 | Height calculation. Flat: mm; rotate90X: mm; rotate90Y: mm (or mm for “1”). A 0.2 mm gap in produces parts that hold together during printing but snap apart afterwards |
| 5 | Primality test (Baillie–PSW). Miller–Rabin base 2; strong Lucas test; results cached |
| 6 | Scoring. Score len(answer) / len(known_best); known best: 42-digit number; 10% penalty if height mm |
| Step | Action |
|---|---|
| 1 | Skip if smaller than the current best |
| 2 | With comma positions now known, check for repeated triplets |
| 3 | Run primality test on the 40-digit candidate |
| 4 | Record as new best; continue searching |
| Split cycle |
|---|
| Z, Y, X, Z, Y, X … |
| X, Y, Z, X, Y, Z … |
| X, X, Y, Z, X, X, Y, Z … |
| Z, Y, X, X, Z, Z, Y, X, Z … |
| Y, Y, X, Y, Z, Y, Y, X, Y, Z |
| Check |
|---|
| All triangles use valid point indices |
| Triangulation is complete (covers convex hull) |
| Delaunay criterion: no point inside circumcircle of any triangle |
| This can’t use the “ground truth” reference without first confirming there are no co-circular points |
| Check |
|---|
| Rectangles tile the grid exactly (no gaps, no overlaps) |
| Each rectangle contains exactly one clue number |
| Each rectangle’s area equals its contained clue |
Spatial Reasoning Benchmarks
Spatial reasoning benchmarks test whether AI systems can perceive, represent, and act on geometric, relational, and viewpoint-dependent information.
See all 162 papers