# 3D and BIM tools for agents: where each one sits between a 360 capture and an IFC file
> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.satyajit.si/articles/agent-3d-bim-tools
> date: 2026-11-12
> tags: 3d, bim, cad, mcp, agents, blender, gaussian-splatting, point-cloud, gltf
Between 9 and 11 November 2026 a run of posts went past about 3D and building tools "for AI agents": a BIM engine whose kernel "doesn't know what a duct or a beam is", a browser architecture editor you can model over scans in, a 3D engine with a whole API that fits in a prompt, and a few smaller tools around them. All of them say an agent can drive them. None of them says what an agent can do with a laser scan.
That is the question I care about here. The reader I have in mind turns 360 and fisheye captures into point clouds, and point clouds into building models, and wants to know which of these tools could take a step of that work off a person. So for each tool I asked three things. What is its data model? How does an agent drive it: MCP, code, a command line, or not at all? And where does it sit between the capture and the IFC file?
I cloned each repository with `git clone --depth 1` on 12 November 2026 and read the code, not just the README. I did not run any of it. Every number below says in the sentence whether the project reports it, I counted it from a file, or I worked it out from the other two.
## The pipeline, and where each tool lands
A scan-to-BIM job has five steps, roughly. You capture (a terrestrial scanner, a 360 camera, a phone). You reconstruct (registration, a dense point cloud, maybe a mesh or a Gaussian splat). You model (walls, slabs, openings traced against that reference). You make it BIM (types, parameters, levels, an IFC that someone else's software accepts). Then you ship it for review, to a viewer, a client or a renderer.
The tools in this roundup are not spread evenly over those steps. Most of them crowd the last two. The map below places each one, with what it takes in, what it hands on and how an agent reaches it. Click a tool to read its row.
The short reading of that map: the step in the middle, from a point cloud to editable building elements, is where every one of these tools is thinnest. Pascal accepts a scan as a reference layer and leaves the tracing to the agent's eyes. MutinyBIM does not accept a scan at all. The one working capture-to-model loop in this set is not a product. It is a person on X wiring Claude into Blender.
## MutinyBIM: a kernel, add-ons on a contract, and a server that re-runs your edit
[MutinyBIM](https://github.com/permitzip/mutinybim) went public on 9 November under Apache-2.0. Its maintainer, PermitZIP, [announced it](https://x.com/PermitZIPhvac/status/2119870226120519687) with a list: a kernel of "elements, types, parameters, units, networks, spaces, phases, sheets, commits", trade add-ons for architecture through fire protection, IFC 4.3 export and PDF sheets, an MCP server, and "live multi-user editing, tested at 250k elements". There is also a [hosted app](https://app.mutinybim.com/). I read commit `94513ba`.
### The data model
A model (`ModelState` in `packages/bim-kernel`) is a revision number, a map of elements by id, the connections between them and the model's settings. Every element is a plain, frozen, serializable record with an id, a version, the revision each authored field was last written in, a partition (level, zone, discipline), a group and the phases it is built and demolished in.
Two ideas carry the design. The first is that **types and parameters are data, not code**. An element can name a type. A parameter is a key with a unit kind. The value in force is resolved by one function, `elementValueSource()`, which says it plainly in its doc comment: "the element's own value overrides its type's; clearing the own value puts the type's back". Written out, for element $e$ with type $T(e)$ and parameter key $k$:
$$
v(e, k) = \begin{cases} v_e(k) & \text{if the element sets } k \\ v_{T(e)}(k) & \text{otherwise} \end{cases}
$$
The second is that **trades are add-ons**. An add-on, a "pack" in the code, is a manifest plus contributions to versioned extension points: classes, element kinds, parameter sets, services, network adapters, commands, lint rules, calculations, IFC import rules, symbols, and agent tool descriptors. The contract is at version 1.13.0. The repository's own example, an `acme` stormwater pack, adds a retention-vault class, a `acme.required_volume` parameter in cubic feet that maps to an IFC property set, a sizing lint rule and a volume calculation, and the README says IFC export reads the registries "so anything an add-on defines exports with no exporter change". A model pins the exact versions of the packs it uses, and a host that lacks one "says so by name" and keeps the records it cannot read.
The explorer above is that example, with the three records side by side. Turn the pack off and the element is still there with its class id; nothing reads it. Turn the override on and the resolved value comes from the instance, not the type.
### Does the kernel really not know what a beam is?
Partly. There is a real mechanism behind the claim: a test, `trade-terms.test.ts`, splits every identifier and comment in the kernel's source into words and counts 37 trade terms (duct, circuit, fixture, gas, sprinkler, the code books NEC and IPC, and so on). The count may only go down. Its baseline lists 2,370 occurrences across 172 files; "duct" alone appears 473 times and "electrical" 289. For scale, I counted 589 TypeScript files and about 109,000 lines in the kernel's source outside its test folders. So the kernel is being drained of mechanical, electrical and plumbing knowledge on a ratchet, and the ratchet admits how much is left.
Building elements are a different story. The term list has no wall, slab, beam or column in it, and the kernel's own `types.ts` declares `Wall`, `Slab`, `Opening`, `Room`, `GridLine`, `Column` and `Beam` as kernel record shapes. A beam is a start, an end and a section name; the kernel's element commands say they cover "Building and structure kinds only (walls, slabs, openings, rooms, grids, columns, beams, components)". What the structural pack adds is the class `struct.beam`, its fields, a wide-flange catalogue, live loads and the gravity load path. So the kernel knows a beam's geometry and nothing about what it carries. That is a sensible split. It is not "doesn't know what a beam is".
### How an edit travels
This is the part I would copy. Every change is an **intent command**, a small JSON object parsed by a zod schema (`create_level`, `move_elements`, `route_run`). The client runs it locally as a preview. The server then runs `planCommit()` in `changeset.ts`, and I read that function rather than the architecture page:
1. It refuses a request whose base revision is ahead of the head.
2. It re-runs the command on the current head with its own code. The client's result is never trusted.
3. It drops changesets from the same session (one browser tab, one agent run) from the comparison, so your own unconfirmed edits do not compete with you.
4. If the command deletes an element that another session changed since the base, it refuses: "changed … after you looked at it; check it before deleting".
5. For every authored field the command *records*, if another session wrote that field since the base and the head's value differs from the one being written, it refuses with the other person's name and the field. A command that records no fields gives this step nothing to compare (see the correction below).
6. Intents that earlier changes recorded on any element this one writes must still hold on the result.
Otherwise the change commits, rebased if the head moved. Derived values, such as a duct network's flow total, are recomputed rather than compared, so they never conflict. A `batch_edits` command carries up to 500 steps as one revision and one undo step.
**Correction, 12 November 2026.** The first version of this section said every field an edit writes is protected. It is not. The site's [hands-on run of Mutiny BIM](/articles/mutiny-bim) raced two sessions against the commit server at the same commit, `94513ba`. Two moves of one wall: the second was refused by name. A delete after someone else's edit: refused. Two thickness edits on one wall, 300 mm and 250 mm from the same base: both committed, as revisions 15 and 16, the wall ended at 250 mm and nobody was told. The cause is in `packages/bim-kernel/src/elements/commands.ts`. Five element-core commands (`set_element_class`, `set_element_type`, `set_element_values`, `set_element_placement` and `set_element_thickness`) leave through `finish(reader, working, touched, [], …)`, and that empty list is the authored-field list `planCommit()` compares. So for those commands step 5 above has nothing to check, and the rule degrades to last write wins. `set_element_values` was read in the code, not raced; `set_parameters`, which records `values.`, should be protected by the same reading. The widget below now shows that split.
An agent is an actor of kind `agent`, acting for one person (`agent::`) with exactly that person's capabilities, and it is its own session. That means an agent and a human editing the same model get the same refusals, in the same words, and the hands-on run saw exactly that for a wall move. For a capture team that already has three people tracing the same scan, that matters more than any tool list. It also means the same blind spot for both: until those five commands record what they write, two agents setting types or values on the same walls overwrite each other in silence.
### What the agent gets
The MCP server (`packages/bim-mcp`) has nine core tools, deliberately: a script reference, a checker, a run that previews, an apply that lands, a part-type save, and four reads (model summary, element query, network inspection, validation issues). A live server lists a tenth, `bim_enable_pack`, which loads the trade tools on demand; [the hands-on run](/articles/mutiny-bim) counted 10 with the core set and 168 with every pack. Everything else (walls, routes, circuits, sheets) is a function in a TypeScript scripting kit. The agent reads the reference, writes a script, checks it, runs it for a preview that saves nothing, and lands it after a person approves. Landing re-runs the script and lands only what was previewed; if the model moved in between, it answers `stale_preview`. Scripts run in a fresh capped Node process, never in the process serving the tools.
That design keeps the agent's context small however large the kit grows, and it puts a human on every write. It also means MutinyBIM does not call a model itself: "Your assistant, your bill."
### What "tested at 250k" rests on
The repository holds performance budgets, not results. `docs/perf/mutinybim-budgets.json` has 335 metric rows and 43 invariants, each with a p50 and p95 budget on a reference "Apple-silicon developer laptop (M-series Pro/Max class)". One row is "50 people editing one 250k model at 2 edits/s each", budgeted at 150 ms p50 and 600 ms p95 to "saved". Of the 335 rows, 114 are marked `pending`, and the file lists one known failure at 250k, `3d.edit.redraw`. On shared CI runners the gate checks invariants and sizes and only reports timings. I found no committed measurement, so "tested at 250k" means "there is a gate at 250k that can be run". That is more than most projects have. It is still a budget.
### Where it fits for scan-to-BIM
After the modelling, not during it. MutinyBIM's underlays are PDF, image, DXF and DWG, and it links IFC models (read with web-ifc). I found no point cloud, mesh or splat input. Its export is `IFC4X3_ADD2` STEP. So in a capture pipeline it is the place a model lands once someone has turned the scan into elements: typed, scheduled, checked for clashes, drawn on sheets, and edited by several people and agents with conflicting moves and deletes refused. If you want an agent to route MEP through a scan-derived model with refusals in plain words, this is the most serious open option in the set. If you want two agents filling in element values on the same walls at once, wait for the fix above or serialise them yourself.
## Pascal Editor: a scene graph you can model over a scan
[Pascal Editor](https://github.com/pascalorg/editor) is an MIT-licensed browser editor for architecture, built on React Three Fiber and WebGPU. The [post that surfaced it](https://x.com/dextune/status/2120540292613116282) leads with the line that matters for capture work: "Import scans as reference layers, then model editable walls, slabs, roofs, openings, rooms, and furniture over them." I read commit `51bf407`; the packages are at 1.1.1.
### The data model
A scene is a flat dictionary of nodes keyed by id, each with a type, a `parentId` and a `children` list; the hierarchy is Site, Building, Level, and under a level the walls (with doors and windows as items), slabs, ceilings, roofs, zones, a `scan` (3D reference) and a `guide` (2D reference). State lives in a Zustand store, persists to IndexedDB, and keeps 50 steps of undo. Node kinds come from plugins through the same manifest the built-ins use.
### What a scan actually is
Here I read the schema, because "scan" can mean anything. A `ScanNode` has a URL, an optional capture session, a position, a rotation, a single scale and an opacity from 0 to 100. The editor's upload accepts "a .glb/.gltf scan or an image". So a scan, in the open editor, is a mesh you place by hand and trace over.
There is a second path. `core/capture` defines a versioned capture-session manifest: an ARKit device trajectory as 4x4 transforms, a point cloud as XYZ triples with optional colours, a surface mesh quantized to 16-bit positions with at most 65,535 vertices and 20,000 faces, and a room model as USDZ (the viewer's README calls these RoomPlan models). The viewer package ships a `CaptureRuntime` that draws those streams as reference layers, including PLY point clouds through three.js's `PLYLoader`, for a host that mounts it. The open editor app does not mount it; I found no use of `CaptureRuntime` outside the viewer package. The manifest is built around a phone capture, not a terrestrial scan. And the agent's access to captures is hosted-only: the project's own skill says the capture tools (`list_captures`, `get_capture`, `open_capture_as_project`) "do not exist on the local CLI".
### What the agent gets
The MCP server runs headless in Node or Bun with no browser. Its README's tool table documents 53 tools, and the scene and project tools (`load_scene`, `save_scene`, `list_scenes`, `create_project`, `run_batch`) come on top: reads (`get_scene`, `get_walls`, `get_zones`, `measure`, `view_scene`), semantic edits (`create_story_shell`, `create_room`, `add_door`, `create_roof`, `furnish_room`), a raw `apply_patch` for anything else, checks (`verify_scene`, `check_collisions`) and exports (`export_json`, `export_glb`). Two vision tools, `analyze_floorplan_image` and `analyze_room_photo`, ask the MCP host to run the model through sampling. Locally, projects live in a SQLite file under `~/.pascal/data/pascal.db`; every mutation version-checks the saved scene and answers `live_sync_version_conflict` if the editor saved first. The README asks for one active agent client per local service.
IFC goes both ways, with limits. `@pascal-app/ifc-converter` imports through web-ifc and makes native nodes for sites, buildings, levels, walls, doors, windows, slabs, columns and spaces "when their parameters can be recovered"; railings, members, curtain walls and the rest stay as selectable meshes. Export is IFC4, from the editor (`scene-to-ifc.ts`), not from an MCP tool.
### Where it fits
Pascal is the only tool here with a modelling step over capture data. For a phone-scale interior, the loop is real: put the scan in as a reference, let an agent block out the shell with semantic tools, verify, export. For a building-scale terrestrial scan, it is not there yet: the point-cloud layer lives in a capture runtime the open editor does not mount, and I found no snapping to scan geometry. The agent can render the building from a viewpoint it picks (`view_scene`), but none of the documented tools reads the scan's geometry. Pair it with something that has already extracted walls ([SpatialLM](/articles/spatiallm) writes them as text) and it becomes more interesting.
## vork: an engine the agent writes as code
[vork](https://github.com/voyager-so/vork) is a 3D and VFX engine "built for AI agents", written in Rust and Slang on Vulkan and Metal. There is no editor. The agent writes a scene as JSON (or TypeScript or Python that emits it), renders, looks at the picture and edits the code. The scene format follows glTF for assets, OpenPBR 1.1.1 for materials and Blender's physical camera and AgX colour; programs written in Slang can define materials, cameras, light propagation and simulation. I read version 0.5.1.
### The licence, precisely
It is not open source, and the licence says so plainly. The "vork Preview License" (Nullframe, Inc.) lets you use it free of charge for any purpose including commercial work, let agents operate it, modify it for your own use, and share unmodified copies. It forbids selling or relicensing it, distributing a modified version, and offering it "as a hosted or managed service in which other people submit scenes, code or jobs to be rendered"; rendering for your own organisation and delivering media to a client is allowed. It covers "this version only": later versions may be paid. The Blender bridge is a separate GPL-3.0-or-later component.
### The API that fits in a prompt
The README says the core API "fits in about 2,500 tokens". `vork help` with no topic prints `docs/help/index.md`; I counted 11,595 bytes and 1,428 words in it. At the usual 3.5 to 4 characters per token, that is somewhere around 2,900 to 3,300 tokens, so the claim is in the right range, and the point stands: one page tells an agent the scene shape, the render command, units (metres, seconds, radians), axes and how to look up any field with `vork help field PATH`. Unknown fields are errors, which is the right default when the author is a model.
### The million birds
The headline is "192 frames at 1080p rendered in 97 seconds on a single NVIDIA L4. Blender EEVEE at the same sample count is projected at 13–18 minutes." The README's own table backs it and qualifies it, which I respect. The skim movie's median of three full commands is 96.942 s at four samples with OIDN denoising. Setup took 243.809 s and warmup 166.030 s; with those, the total is 506.781 s, or 8.45 minutes.
The 13 to 18 minutes is the four-sample EEVEE projection for skim, 773.7 to 1,082.5 s across two retained runs, which is 12.9 to 18.0 minutes. It extrapolates eight warm frames, omits simulation, startup and encoding, and hands EEVEE the finished flock as geometry. Dividing those by the 96.9 s movie gives the README's "about 8–11×". Dividing by the 506.8 s that includes setup and warmup gives about 1.5 to 2.1. Neither comparison is equal-quality; the README says that too.
The rest of the speed table is milder. On default stills vork is 1.38 to 1.66 times faster than EEVEE (eight samples with denoising against EEVEE's 64 without), on four complete 240-frame movies 1.14 to 2.32 times, and in path tracing it is 5.81 and 1.99 times slower than Cycles on two scenes. Rendering needs Apple Silicon or an NVIDIA GPU with Vulkan ray queries.
### Where it fits
At the end, as a presenter. vork imports glTF and has no point cloud or splat primitive I could find in its help; it is not a modelling or BIM tool. What it offers a capture team is a renderer an agent can drive without a GUI: a client walkthrough from a model, or the VFX-style shot above, where real footage gets a tracked camera and proxy geometry. Its camera solve is, in the README's words, an estimate. If you already render with Blender, the honest comparison is the 1.4 to 1.7 times on stills, not the bird number, and the licence decides whether you can put it behind a service.
## The smaller tools
**[glTF-Transform](https://github.com/donmccurdy/glTF-Transform)** (MIT, 4.5.1) is the glTF 2.0 SDK most web 3D pipelines already lean on: read, edit and write a model in Node or the browser while it keeps the byte offsets and accessor indices straight. Its CLI registers 39 commands in `cli.ts`, among them `optimize`, `draco`, `meshopt`, `simplify`, `weld`, `resize`, `etc1s`, `uastc`, `webp` and `avif`, and `inspect` prints where a file's weight is. There is no MCP server and it does not need one: `gltf-transform optimize in.glb out.glb --compress draco --texture-compress webp` is a line any agent can run. It is the step between a reconstruction mesh and anything you ship to a browser.
**[ha-diorama](https://github.com/CarlesRojas/ha-diorama)** (MIT) is a Home Assistant card that draws your home as a small 3D model whose pieces are bound to devices: the lamp glows when the light is on, and a click turns it off. It needs Home Assistant 2024.6 or newer. What makes it agent-friendly is that the whole home is plain card YAML: floors, rooms as polygons in metres, each room's area, camera and the entities placed in it. The repo's demo flat is a 916-line `demoflat.yaml`. A plan image can be traced under the drawing, but it is kept in the browser's local storage, never in the config. So an agent with a floor plan, or with walls already extracted from a scan, can write a working digital-twin dashboard without touching the editor.
**viz3d's floor-plan skill** ([codepawl/viz3d](https://github.com/codepawl/viz3d), MIT) turns a 2D plan into a Blender Cycles house, and its author [posted an update](https://x.com/anxuanng/status/2120110291967197466) on 10 November: it "now checks every piece of equipment against the real room size", and in the example "the supplier drew the room 300 mm too wide, so the roaster gets flagged". The skill, `build-house-from-plan`, has two gates I like. `plan_check.py` refuses a build unless at least 0.70 of wall faces land within 7 cm of the drawing's ink, with a best-fit offset of at most 16 cm and a clear win over a 50 cm shifted control. `fitout_check.py` reconciles dimensions written in metres, millimetres and feet-and-inches (two readings may differ by 0.02 m before they conflict), then checks each item's footprint and service zones against its room, every door's swing plus a 0.9 m approach, the other items and the ceiling. The binding check is named, so the fix is obvious. Swap "the drawing's ink" for "the point cloud's wall planes" and that is a scan-to-BIM QA step.
**[blender_ogc3dtiles](https://github.com/iconem/blender_ogc3dtiles)** (MIT, by Iconem) streams OGC 3D Tiles into Blender through cesium-native: tiled meshes (b3dm, glb, Draco, meshopt, KTX2), tiled point clouds and tiled Gaussian splats in `KHR_gaussian_splatting`, compressed with SPZ or not, which become native splats in Blender 5.3. It clips tilesets with Blender objects, so a high-resolution drone scan can sit inside a coarser city-wide one. Blender 5.3's splat support is real: the [release notes](https://developer.blender.org/docs/release_notes/5.3/rendering/) say Workbench, EEVEE and Cycles render 3D Gaussian splats, import from PLY and SPZ, and "There is currently no export support"; [my earlier read of the 5.3 source](/articles/blender-5-3-gaussian-splats) has how each engine does it. For an agent, the add-on's streaming loop also runs headless as `stream_tick()` under `blender -b`, so a script can load the tiles around a camera and render.
**[Mapbox GL JS](https://github.com/mapbox/mapbox-gl-js)** draws vector maps, terrain and 3D models with WebGL (its `3d-style/source/` holds a glTF model source and a tiled 3D model source; I read commit `4853cb8`), and the [post that listed it](https://x.com/dextune/status/2120162064224464905) was right to add that "Use and modification require an active Mapbox account". Since v2.0 the licence is the Mapbox Terms of Service: use only with Mapbox products, through an account in good standing, with no changes to the billing and telemetry code. v1.13 and earlier were BSD-3-Clause, which is where the community fork MapLibre GL JS started. For agents, Mapbox ships its own [MCP server](https://github.com/mapbox/mcp-server) (MIT, needs a token) for geocoding, routing, isochrones and an interactive map render in the chat. For a capture team that means site context: a geolocated scan placed on a basemap for a client. The library itself is driven by code, not by tools.
## One creator's capture-to-Blender loop
The most direct capture work in this set is not a repository. On 11 November the 3DGS practitioner kotohibi [posted a render](https://x.com/kotohibi_3d/status/2120508846758400485) of a hillside shrine modelled in Blender, captioned "Fable5.2 (Opus5.5) + Blender + 密点群 + cubemap画像" (a dense point cloud and cubemap images), said it took a few hours, and linked a [process write-up on Qiita](https://qiita.com/kotohibi/items/eaed29f38970ba90bd22). The post also says a mesh holds up under large viewpoint changes and stays editable in a way a splat does not.
The write-up describes an earlier street scene, not the shrine, but it is the recipe. Capture with a 360 camera (the tags name the DJI Osmo 360), align it with the author's own 3DGS guide up to the COLMAP cubemap step, then build a dense cloud in Metashape with Quality set to Low, Depth filtering to Aggressive, and "Calculate point confidence" on so that Clean Point Cloud can drop low-confidence points afterwards. 360 MCConverter V1.7.0 extracts the dense cloud as `dense.ply` beside the cubemaps. Claude Code, connected to Blender over MCP, gets one prompt: model the whole scene from `dense.ply`, make vegetation and textures procedural, read detail off the cubemap images, estimate scale from the images and the cloud, and save what it learns as a skill. The street took about two hours and one round of corrections ("check both sides of the road sign; add the traffic lights"). A [7 November post](https://x.com/kotohibi_3d/status/2118930786179240412) puts that street's dense cloud at 56M points.
What changed since [the splat-to-Blender loop this site wrote up on 31 October](/articles/gaussian-splat-to-blender-with-claude) is the reference. The sparse tie points were too thin for the model to understand the space, and the splat built from the same data had too many floaters and fell apart when the viewpoint moved, which the author says confused Claude. A cleaned dense cloud plus the original images worked better. That matches what anyone who traces scans by hand knows: you want measured geometry for position and photos for meaning.
## What I would do with this, as a capture shop
Put the three main tools on the pipeline again and the gap is plain. vork renders the end product. MutinyBIM holds a building model with the rigour BIM needs, but only after the scan has become elements. Pascal is the one editor that lets an agent work beside a scan, and its scan is a glTF mesh, or a phone-oriented capture session drawn by a runtime the open editor does not mount. None of them turns a registered point cloud into IFC walls. The closest things on this site are [SpatialLM](/articles/spatiallm), which writes a room's walls and openings as text from a point cloud, [debim](/articles/debim), which writes buildings as YAML and compiles them to IFC with real losses, and [KOLC+](/articles/kolc-3dgs-bim), which puts splats and BIM in one closed viewer. [3D Model Anything](/articles/3d-model-anything) does the phone-scan version of the loop in three.js.
If I were wiring an agent into scan-to-BIM this week, I would not pick one of these tools; I would split the job the way kotohibi's loop does. Measured geometry goes in as the reference (a cleaned, subsampled cloud per level or per room), images go in for meaning, and the agent proposes elements that a deterministic check scores against the cloud, the way viz3d scores a build against a drawing's ink. Whatever passes lands in MutinyBIM as an intent command a person approves, so three people and two agents can work on one building with their conflicting moves refused by name. That part mostly exists and is the best thing in this roundup; the gap is the element-core commands (types, classes, values, thickness), which still overwrite in silence. The part before it is still a person with a prompt.
My ranking, for this reader: MutinyBIM is worth cloning now for its commit model and its add-on contract, even though it cannot see a scan and its commit model has the thickness-and-values hole above. Pascal is worth trying on phone captures and small interiors, with the IFC export checked in a second viewer. vork is worth it only if you render for clients and the preview licence suits you. Mapbox is a licence decision before it is a technical one; if you do not want an account, use MapLibre.
## 12 November: the shrine scored against its cloud, two rooms from prompts, Google's tiles in Blender, a Turkish CAD, drawings back to Revit, and a splat world
Seven more posts came through between 9 and 12 November. The first gives the capture-to-model loop above something it lacked: numbers for how far the agent's model sits from the scan.
### kotohibi's shrine, measured against its own dense cloud
On 12 November kotohibi [posted an accuracy comparison](https://x.com/kotohibi_3d/status/2120857119083909159) for the shrine scene in the clip above, credited again to "Fable5.2 and Opus5.5 x Blender x dense point cloud x cubemap images" and linking the same [Qiita write-up](https://qiita.com/kotohibi/items/eaed29f38970ba90bd22) for the production flow. The post says the dense point cloud keeps the scale ("I think", the author adds), and that areas the camera never saw are estimated, so they are less accurate. Three sheets come with it. Each puts the dense cloud (vegetation removed), the model as a grey solid, and the model's outline in red over the cloud on one metre grid.
Each sheet's header reports the same three measurements, computed on 60,000 points. I transcribed them from the images:
| Sheet | Best scale fit k (95% interval) | Median distance | Within 10 cm |
|---|---|---|---|
| Precinct and worship hall, side view | 1.004 (1.002 to 1.004) | 5.0 cm | 63% |
| Steep stone stairs (otokozaka), side view | 1.000 (1.000 to 1.002) | 5.1 cm | 69% |
| Whole site, top view | 1.000 (1.000 to 1.000) | 5.7 cm | 62% |
Read k first. It is the scale that best maps the model onto the cloud, so 1.000 to 1.004 says the agent built the model at the cloud's scale, within 0.4 percent. The hall spans about 17 m on its sheet, so 0.4 percent there is roughly 7 cm. What k cannot tell you is whether the cloud is at true scale. A 360 capture solved in Metashape has no metric scale unless the photos carry usable GPS or someone adds a scale bar, and the Qiita recipe has the agent estimate scale from the images and the cloud. For survey work you still put a measured distance or control into the cloud; this check would then carry it through to the model.
The distances need a closer look. The headers say the median and the 10 cm share are taken over points within 40 cm of a model surface. Anything farther away is left out, and the farthest points are where the model guessed or missed. On the hall sheet the model runs on past the cloud, a large rounded block from about 7 m to the edge of the sheet where the cloud has almost no points; that is the "invisible area" the post warns about, and it does not reach these numbers. So read them as inlier statistics: among points the model roughly agrees with, half are within about 5 cm, and between 31 and 38 percent are more than 10 cm away. Neither the post, its thread nor the Qiita write-up says how the sheets were produced (by the agent or by a script of the author's) or why the cut is 40 cm.
For an as-built deliverable I would call that a massing model. The as-built specs I would hold a scan-to-BIM job to are written in millimetres to a couple of centimetres, and a 5 cm median over the points that already agree does not get there. For context modelling, a client walkthrough or a first pass that a modeller refines, it is plenty, and the hours-not-days speed is the reason to try it.
The method is the part to copy, and it needs two additions before it is a QA gate. Report the share of points beyond the 40 cm cut, and the share of model surface with no cloud near it, because that second number is the inferred part of the model. And score per element, so a wall that misses is named, the way viz3d's `plan_check.py` names the check that failed. Then record on each element whether it was observed or inferred. In MutinyBIM a parameter is data, so that flag is one field in one add-on, and it would travel into the IFC.
### A Nuketown house from one prompt
On 12 November Caleb Fahlgren [posted](https://x.com/calebfahlgren/status/2120680918914601165) that Fable 5.2 built a detailed two-storey house, 1950s styled, from one prompt in "a few hours". [The prompt is in the thread](https://x.com/calebfahlgren/status/2120680922336862315). It asks for a "triple AAA level mini house like the one in call of duty nuketown", says it should "run in threejs fps", and adds: "send me screenshots as you build it and use subagents ot critique." It also points the model at Hugging Face Jobs for GPU rendering.
What I could check is in his replies. Asked whether the geometry was generated or pulled in, he wrote that "The house and almost everything in it is Python-generated", with about 20 small CC0 props (tools, plants, a chair). Asked how it was done, he said it "was mostly python with headless blender". Asked "Few hours or few days?", he answered "hours". The prompt asks for three.js and the replies describe Blender, and the post does not say whether the video is the three.js build running or a Blender render of the same scene. Neither the post nor his replies link a repository or a scene file. Two people asked how many render-and-fix rounds it took and whether he stepped in; I found no answer to either in the replies. So this is a demo of what one prompt and a few hours can produce, with nothing measurable attached.
For capture work the house itself means little. Nothing in it has a reference; every detail is invented to look right. What carries over is the loop the prompt asks for: render, look, have a second agent critique, fix. kotohibi's cubemaps make that loop checkable. Render the model from each cubemap's pose and the critic compares it with the photograph taken at that spot instead of with its own taste, which is the cheapest way I can think of to catch a missing window or a misplaced post that the 40 cm cut above would hide.
#### We gave the same loop a beach house
His post has no scene file to open, so we ran the method ourselves. Unlike the repositories above, this part we did run. The brief was a paragraph from Satyajit, not a game map, plus a pipeline spec from us (bake the light, stay near 6 MB, no viewer libraries), so this was not one prompt in his sense. The paragraph asked for an original two-storey beach house with whitewashed timber walls, a wraparound deck, big sliding doors to the sea, a balcony, an outdoor shower, a boardwalk through dune grass to the water, warm late-afternoon light, and a model you can walk through on this page. We added one rule his replies suggest he did not keep. Every mesh and material is generated in Python, with no downloaded props, textures or HDRIs. Claude Opus 5.5 in Claude Code wrote the script and ran the loop. Blender 4.5 ran headless on a workstation with an RTX PRO 2000 Blackwell, over SSH.
One pass went like this:
1. `build.py` rebuilds the whole scene from nothing in about 0.3 s.
2. Cycles bakes the light at 128 samples into three texture atlases: 43 s for the exterior, 98 s for the interior and 18 s for the sand.
3. A short script packs everything into a `.glb`.
4. Headless Chromium loads the `.glb` in the same viewer you see below and screenshots twelve fixed cameras.
A full pass took about 200 s. Then someone looked at the twelve pictures. For four of the seven passes that was a new subagent each time, shown the brief and the screenshots and nothing else, never the code. It had to answer yes or no and list at most five problems with numbers (three in the last round). It never said yes.
- **After pass 3** it said the hero shot was a small house on empty sand, the furniture was stacked boxes and the back of the house was "a plain box". The back was a real bug it could not have known about. Every window trim and shutter had its faces wound inward, so the viewer culled them from outside. The fix was two lines.
- **After pass 5** it said the sea was missing from three of the four exterior shots, the beds and bathroom looked unfinished, the walk-mode cameras spawned inside open doors, and the deck-chair stripes shimmered. Half of the furniture complaint was wrong. The headboards, pillows, toilet and mirror were there, but every camera faced away from them. So the cameras moved, and that was the fix.
- **After pass 6** it said the overview had no water in it and the same painting hung in every room. That brought a new aerial over the sea, five different paintings across the six frames instead of two, a real toilet and a shower screen.
- **After pass 7** it said: "No, but it is close." The front, the deck, the balcony and the living room passed. The bathroom, the flat-looking dunes, some smudgy bake seams on the sofas and the plain back wall did not.
I stopped there, so those four are what you will find. Some fixes came from looking at the numbers, not from the critic. The first sand bake was a patchwork, because every one-metre terrain square was its own island in the texture. The first export was 10.6 MB, and 106,000 of its triangles were dune grass.
The file is 5.7 MB and 72,249 triangles, made by a 1,200-line Python script. Three JPEG atlases hold all the light (3,072 px for the outside, 4,096 px for the inside, 2,048 px for the sand), so the viewer draws every surface unlit and shades only the sky and the sea. It does not use three.js or Draco. The loader and renderer are about 900 lines of TypeScript. Walk mode follows floors and stairs and stops at walls. In a headless test it climbed the sixteen stairs in five seconds, came back down, went in through the open half of a sliding door, and stopped at the deck and balcony rails. The timing from the first test render on the GPU box to the file above was 45 minutes.
Next to his video, ours is plainer. His frame has trees, flower beds, mullioned windows, a garage full of shelving and neighbours' houses. Ours is clean low-poly: chamfered boxes for upholstery, four-quad leaves, and nothing shiny, because only diffuse light was baked. The glass is a tint and the sea is a shader. What ours has is the file. You can open it above, walk up its stairs and count its triangles. I don't think the critic loop is optional. In seven passes the reviewers caught a culling bug, cameras that hid half the furniture and doorways you spawned inside, and I had looked straight past all three.
We then gave the same paragraph and the same loop to Fable 5.2 and Sonnet 5.5, each from an empty directory, and had three blind judges rank eleven matched views of all three houses. That comparison, with all three houses walkable, is its own article: [one brief, three Claude models](/articles/beach-house-three-models). In short, Sonnet got a critic's yes fastest and came last with every judge, and Fable edged this house on eye-level light while this one kept the aerials.
### Meng To's apartment: one photo, a camera solve and two blind judges
On 9 November Meng To [posted](https://x.com/MengTo/status/2119746949121495303) that he had turned his apartment into a three.js scene with Opus 5.5 "so I can record videos for my tutorials". It is "fully interactive and you can walk through it in the browser. You can change the lighting and set different render styles. All objects are code using the scoring system." In the replies he said it "took close to 3 days", that it is "a minified version of the actual apartment", and, asked about Gaussian splats, "no, all code". On 12 November he [posted the full tutorial](https://x.com/MengTo/status/2120746846402564163), crediting Opus 5.5 and Fable 5.2. The tutorial is the video attached to that post, 10 minutes 38 seconds long; neither post nor any reply links anything else, and nobody got an answer to "Is this deployed somewhere?".
The tutorial shows its prompts on screen, with session numbers and dates, so the method can be followed frame by frame. I read it that way and did not transcribe the narration. In order:
1. **Warm up on someone else's room.** Prompt 01 (session 1, 5 November) pastes a link to another creator's Unreal room video and says "recreate this perfectly in a single html file in threejs. self-verify until perfect." The self-verify loop on screen is render, compare with the reference, fix.
2. **Swap the reference for one photo.** Prompt 04 is nine words: "do another one for my room instead. self-verify until perfect." The reference is one iPhone ultra-wide portrait photo, 1080 by 1920 px. The card beside it strikes out "Measurements" and "Floor plan".
3. **Turn the photo into a measuring tool.** The agent finds two vanishing points from the back-wall and side-wall lines, assumes the desk top is 0.76 m high, and solves the camera by least squares, "no tape measure": 700 px focal length, turned 30.5°, tilted down 16.3°, lens 1.41 m up and 1.57 m from the back wall. After that, "Nothing placed by eye": each object goes where a ray through its pixel hits a known plane, the floor or the desk top.
4. **Say what is true, in short notes.** The solve put the ceiling at 2.35 m; he corrected it to 2.60 m, and prompt 24 says "the room needs to be bigger". Prompt 27 adds seven more photos ("more details in the room"). Other notes name things: the chairs are an Aeron with a headrest and one without, the box on the shelf is "a game like Catan", the figurines come from Tripo3D.
5. **Score every object, blind.** Prompt 37 (session 2, 7 November): "Keep improving every single object in the room to get a score of 9 out of 10." Each round renders every view, two blind judges score each item, the lower score counts, and the lowest item is fixed next. The judges disagree a lot (round 5: 7.22 from one, 6.50 from the other), so a change merges only after a paired check, where one judge sees both versions in hidden order and the new one has to win in daylight and in low sun. The desk went from 6.54 to 6.81 that way. When the judges' notes went against what he knew of the room (a ladder shelf "two tiers too tall", a white chair of "the wrong type"), his rule was "My photos and my words win over the judges".
6. **Run it in parallel, and plan for the limit.** Four sessions from 5 to 9 November ran six threads (desk, shelf, chairs, room shell, left wall, front wall). One standing instruction says to keep going to 98% of the weekly limit, then stop and write a prompt to continue; session 3 picked up on a new computer from the GitHub repository and one pasted prompt.
7. **Fix the light, then the load.** Slatted-blind shadows came out as dashes (the judges called them "LED strips") until the shadow map was rolled so its rows run along the slats. The page took 83 s to show anything while it baked light; with 594 pre-baked light probes it is ready at 19 s, after a 23.6 MB download in 195 files. The page offers morning, day, evening, night, clay, wireframe scan and walk-around.
8. **Move to Blender for the film.** On 10 November the same room went out as 9 GLB files plus a `scene.json` of lights and cameras into Blender 5.2 Cycles: 13 minutes from the prompt to the first path-traced stills, with 1546 materials, 20 lights and 25 camera views, rendered on two RunPod RTX 6000 Ada pods at \$0.99 an hour, about \$7 for two films.
Some of the tutorial's own numbers do not sit together, and I would not smooth them over. Its end card says "One photo. Two prompts. Every view scored 9 out of 10" over 8,970 meshes, 2.32M triangles and a 9.0 blind-judge score. The chart in chapter 4 shows the round means for 19 items, the lower of the two judges, from round 4 to round 10: 6.61, 6.44, 6.64, 6.67, 6.47, 6.32, 6.74. The card does not say how the 9.0 was scored or whether the same two judges gave it. The prompts run to at least 37, and the brief grew from one photo to eight. And in a reply on 12 November he said he "didn't go as far with the exact measurements", which is true of the tape: every length in the room rests on the assumed 0.76 m desk, and the ceiling still had to be corrected by hand by about 11 percent.
#### Against our beach house
The two runs share the loop: build in code, render, have a model look, fix. They differ where it matters for capture work.
His has a reference and ours did not. The beach house was invented from a paragraph, so our critic could only judge plausibility. His judges compare against a photo, and his camera solve is single-view photogrammetry with one known length. That is the same move a modeller makes when tracing a scan with a known door height, and it inherits the same weakness: one assumed dimension sets the scale of everything, and a desk 4 cm lower than 0.76 m makes the room about 6 percent too big. kotohibi's cloud carries scale in its geometry; one photo does not.
His critic is better designed than ours. We asked one fresh subagent per round for yes or no and at most five numbered problems. He uses two blind judges, keeps the lower score, and merges a change only if it wins a paired, order-hidden comparison under two lightings. That last rule is the one to copy: it stops a fix that looks better in one render from shipping a regression in another, and it would have caught our bake seams. Ours never said yes; his never reached 10, and he says so.
The outputs are different sizes. Ours is 5.7 MB and 72,249 triangles with all light baked in Blender; his page downloads 23.6 MB in 195 files, and the end card counts 2.32M triangles. Both moved the heavy light out of the browser, ours into atlases and his into probes and then a Cycles film. His took close to 3 days by his own reply; ours took 45 minutes from the first test render to the file. Neither runs on a point cloud. His is the nearer of the two to a capture deliverable, because a person can check it against the photograph, and a camera solve plus "nothing placed by eye" is the right instinct for anyone who has to place things where they are.
### Blosm streams Google's 3D Tiles into Blender, tile by tile
On 11 November prochitecture [announced](https://x.com/prochitecture/status/2120487135740617164) that Google 3D Tiles "now import progressively in Blosm", so the city appears "tile by tile while Blender stays responsive".
Blosm, formerly blender-osm, is a commercial add-on with an open base. On Gumroad the [Base version](https://prochitecture.gumroad.com/l/blender-osm) is pay-what-you-want, zero included, and [Pro](https://prochitecture.gumroad.com/l/blosm) is listed at \$19.75 with extras such as baking 3D Tiles textures into one. The Base code is on GitHub at [vvoovv/blosm](https://github.com/vvoovv/blosm), GPL-3.0-or-later, in its `release` branch, whose manifest says version 2.8.0 and Blender 4.5 or newer. The progressive importer landed there between 5 and 11 November, and its README is specific: GLB and B3DM tiles, four concurrent downloads, tiles held in memory with no cache on disk, each tile placed "in their final geographic orientation as each finishes", and the whole import one undo step.
For an agent nothing changes. The same README says "Command-line mode retains blocking behavior", that progressive import is rejected in background Blender, and that `bpy.ops.blosm.import_data()` in progressive mode "returns FINISHED after scheduling the job". A script should keep to blocking mode. This is a quality-of-life change for a person at the viewport.
Next to [blender_ogc3dtiles](#the-smaller-tools), the split is clear. Blosm imports mesh tiles from Google or any other 3D Tiles provider (asked whether Google's mesh is dense, the author replied that it "imports whatever the 3D Tiles provider gives out"), and adds OpenStreetMap buildings and terrain. Iconem's add-on also streams tiled point clouds and Gaussian splats, clips one tileset with another, and has a headless `stream_tick()` loop. A capture team's own drone or scan tilesets belong in Iconem's; Blosm is the quick way to get Google's city around them.
Google's terms decide what that city can be used for. The [Map Tiles API policies](https://developers.google.com/maps/documentation/tile/policies) say: "You may overlay your own 3D objects on Photorealistic 3D Tiles as long as the 3D objects aren't extracted, traced, or otherwise derived by hand or machine from Photorealistic 3D Tiles." The same page says "Don't export, extract, or scrape Google Maps Content for use outside the Services", and requires the Google logo and data attributions to stay visible. Blosm's own product page adds that Google 3D Tiles are unavailable for new projects created after 8 July 2025 with an EU or EEA billing address. So Google's mesh can sit behind your scan-derived model in a client render, credited. It cannot be what an agent traces neighbouring buildings from into your IFC, and a `.blend` saved with the tiles in it is the kind of storage those terms restrict, so read the Service Specific Terms before such a file becomes a deliverable.
### ATA CAD: a closed Turkish CAD program that Claude drives to an IFC 4.3
On 9 November the X user irohemmi [posted, in Turkish](https://x.com/irohemmi/status/2119833486588780882), an 8-minute demo with this text, which I translate as: "Then let me show you my personal CAD program, in which, by chatting with Claude, I had it draw two towers of twelve storeys each, a commercial podium beneath them and 96 flats. It also builds a road platform, runs clash analysis on the infrastructure, and applies the institutions' specifications. It has a BIM feature too, of course." On 11 November [the follow-up](https://x.com/irohemmi/status/2120601380364984637) said only "ATA CAD's new site is live", linking [atacad.com.tr](https://atacad.com.tr), with a one-minute promo video.
The site answers most of what the post leaves open. ATA CAD is a closed, Windows-only program (10 and 11, 64-bit), version 1.0.3, with a Turkish interface, written by one person; the About page names him as Abdulbaki Atakan, an infrastructure engineer, and says the core was written from scratch with no third-party CAD engine. It works in three areas: road and terrain (alignments, clothoids and superelevation from the 2022 KGM road design handbook, cross-sections, cut and fill), infrastructure networks (sewer, stormwater and water, with slopes, cover and manhole spacing checked against İller Bankası, İSKİ and DSİ rules, and crossings between networks flagged in 3D, which is the "clash analysis" in the post), and a 3D building model with landscape and a rule check. It reads DWG and DXF and writes DXF; the model exports as IFC 4.3 and glTF. On terrain input it lists points, TIN surfaces and LAS/LAZ point clouds. The 3D page says plainly what it does not do: no structural calculation, no IFC import, and no replacing the engineer, who approves every check result.
The AI part is not built in. "ATA CAD connects to your own Claude account. You write the request in Turkish, and the program runs the commands on your screen." Every operation is shown and can be undone in one step, you set the approval threshold, and ATA CAD charges nothing extra for it. The site does not say whether the bridge is MCP; it points to the program's help file. The demo's chat panel sits beside the CAD window and names the model as Fable 5.1.
The 8-minute demo is cut from a real screen recording, with the real elapsed time and the speed-up shown in a corner, and Turkish and English captions. It goes from a terrain built from survey points and a parcel to a storey table (ground plus 12 floors), a frame of 364 columns and 104 shear walls at 11 minutes, a podium of 25 walls and 13 rooms (2,748 m²), and 12 floors of four flats per tower, 96 flats, at 47 minutes. Then come risers and floor branches for four services, a sewer line of five manholes and four Ø300 pipes (102.81 m, trench excavation 857.68 m³, backfill 698.47 m³), 144 pieces of furniture on floor 1, and a landscape of 62 areas with a 36-space car park, 63 trees and 17 light poles. A landscape rule check of 12 rules finds five footpaths at 1.20 m against a 1.50 m minimum; Claude widens them to 1.80 m and the second check reports 10 passed and none failed (the video does not say what became of the other two rules). Last come a section cutting 456 elements, a floor plan, and an IFC 4.3 file of 14 storeys, 3,372 products and 637 spaces, at 1 hour 30 minutes and 8 seconds in total. The site's own count is twelve prompts for the towers and landscape. The sunset aerials at the end are captioned as AI-generated images made from the model's views, not renders from it.
None of that can be checked outside the video. There is no repository, no downloadable model and no published price. The trial is 30 days by an approved request form, one per computer, and its DXF, Excel, CSV and LandXML outputs carry a "DEMO" stamp. On 9 November the author replied that he had shared a demo version with a group for feedback, that it is not public, and that "these features have not been released yet"; on 10 November, that the BIM level is "entry", since it is only for buildings for now, and that "this is as far as it gets in 3 weeks". So it is a working product with a trial, and the AI building demo is the author's own run on his own machine.
What I take from it is how close it sits to MutinyBIM in shape. Both put the AI outside the program, both make every agent action a visible command a person can undo, and both export IFC 4.3. ATA CAD is single-user and closed, and it knows Turkish infrastructure rules in a depth no open tool here does; MutinyBIM is open, multi-user and has the commit model. For a capture shop in Turkey doing site and utility work, the LAS/LAZ terrain input and the institution rule packs are the reason to ask for the trial. For building models from scans it adds nothing yet: it imports no IFC, and its point cloud is terrain.
### Drawings to Revit by way of IFC, from a government sample set
On 12 November (UTC) sigmode21 [posted, in Japanese](https://x.com/sigmode21/status/2121004629794373996), four screenshots with this text, which I translate as: "Continuing to have dots/GPT-6 Astra build a native Revit model from detailed design drawings. Maybe because it went through a 3D model on the way, it had a hard time, but using the Revit API and Dynamo to the full it somehow got this far. Revit model → 2D drawings → 3D model → IFC → Revit model: a perverse route, but our dot did well." "Continuing" means there is an earlier post; I have only this one. The post names the model as GPT-6 Astra, and "dots" reads as the name of the author's own agent setup; it does not say more.
The fourth image explains the odd route. Its sheets come from the explanatory material for the government-building BIM model and template that Japan's Ministry of Land, Infrastructure, Transport and Tourism (MLIT) publishes for Revit, updated 19 September 2025. So the drawings were themselves produced from a Revit model, which is where the route starts. The building is four storeys of offices with a small rooftop plant room (the level named 5FL is the roof), 32 m by 24 m on its grid (bays of 7,000 and 6,000 mm one way, three of 8,000 mm the other).
What the other three screenshots show, and only that: the file is open in Revit 2024.3, with levels, plan, section and elevation views, room schedules and sheets in the project browser. The selected wall's type is a Basic Wall named `MLIT_PROXY_WALL_150`. Rooms exist as Revit rooms with names, areas (191.483 m² for office 2-1 on the second floor) and an IFC parameter group with an `IfcGUID`, and their comment field reads "MLIT Room79 | sour…", cut off. A wall type with "PROXY" in its name and rooms carrying IFC GUIDs fit the last two steps of the route: elements that came in through IFC, probably as proxies, were rebuilt as native walls and rooms with Dynamo and the API. The post does not say how many elements were rebuilt, which categories (doors, windows, stairs, structure), or how the result compares with the source.
The one reply asks the natural question, "Why not just go from Revit - IFC - Dynamo - Revit?", and got no answer by the time I read the thread. I think the round trip is deliberate, and it is the most useful thing in the post: because MLIT's own Revit model exists, the agent's model can be scored against it element by element, wall by wall and room by room. Nobody has published that score yet. Until someone does, this is a screenshot of a model that looks right, and a four-storey office is exactly where a missing fire door or a wall on the wrong side of its grid line hides.
This is the same job Satyajit built Satya Revit AI for: a chat pane docked inside Revit plus an MCP tool server, so Claude Code or Codex can read and edit a live model, used to take 2D drawing sets to quantity-ready Revit models. The difference is the route. Driving the live Revit model through its API makes native walls, rooms and families from the first command, with each tool call visible and approved. Going through a separate 3D model and IFC first, as this post did, means rebuilding native elements at the end from whatever survived the export, which is the part the author says was hard.
### A World Labs splat walked in three.js, built with Fable 5.2
Earlier on 12 November XRarchitect [posted a 21-second video](https://x.com/XRarchitect/status/2120947265007440052) captioned "Atlas + Fable 5.2 + three.js". It walks through a courtyard with a scooter, stairs and a café table, then the same place restyled twice, the second time at night.
His replies fill in the method. Asked whether he used World Labs Studio or the APIs: "I used chisel API! Then generated splats from different styles." Asked how: "Using Atlas chisel from World Labs to generate the 3D Gaussian splats from an image I created. Then used fable to do first person real time walk through with some really nice post processing effects / depth of field." He linked the beta at [atlas-beta.worldlabs.ai](https://atlas-beta.worldlabs.ai); one reply says it registered and still has no access. `atlasChisel` is one of the endpoints this site found in World Labs' API when it read [Atlas Camera Studio](/articles/marble-camera-studio).
So the 3D here is generated, not captured, and the agent's part is the viewer: a first-person walk, post-processing and depth of field over the splats. That is the opposite split from our beach houses, where the agent wrote every surface and a stock browser loop drew it. For capture work the takeaway is narrow. A splat, generated or scanned, plus an agent-written three.js walker is now a short job, and a scanned splat would be the same viewer with geometry that exists. The post shows no numbers, no file and no code, so there is nothing to check beyond the video.
Of the seven, kotohibi's sheets change my view the most. They are the first numbers anyone in this set has published for an agent modelling from a capture, and they show the shape of the gap: scale holds, surfaces land within centimetres where the camera looked, and the rest is a guess the summary statistics leave out. That gap is the one to close next.
## 13 November: a quad remesher, a generated dumpster, and the Steve Jobs Theater in Pascal
Three more, from 11 and 12 November. One is a tool that sits after scan-to-mesh; the other two are demos, and I say below what each video can and cannot show.
### openclare: quads out of a triangle mesh, along curves you draw
[openclare](https://github.com/marcgardent/openclare) is automatic quad retopology for Blender: "a mesh of triangles in, a mesh of quads out, its edges following the shape." It is a Blender add-on (Blender 4.2 or later) over an engine written in Rust. The README says each release also ships the engine as a C library with a header (`openclare-capi`) for other programs, and the workspace builds a command-line tool. I cloned it on 13 November at commit `fc884ce` and read it; I did not run it.
Why a capture shop would care: a mesh out of photogrammetry, or one extracted from a splat, is millions of small triangles laid wherever the reconstruction put them. That is fine to look at and bad to work on. Subdivision surfaces want quads. Edge loops, the rings you select to move a window reveal or bevel a cornice, only exist on a quad grid. UV unwrapping and deformation behave far better on one. A field-aligned remesher computes a direction field over the surface, from curvature and hard edges, and lays a grid of quads along it, so the edges of a column run around the column. openclare adds a *Draw Curve* tool: you draw on the model, and the result gets a line of edges along each curve (a loop round an eye, a limb, a moulding), optionally marked sharp, creased or as a UV seam.
How far to trust it, from the repository itself:
- **Licence:** GPL-3.0-or-later for the code. The README calls the add-on the Community edition, and a 6 November documentation commit leaves baking to a PRO edition.
- **Maturity:** young. The first commit is dated 6 October 2026, and there are 356 commits by 13 November. The latest GitHub release is v0.7.0 (28 October), while the workspace `Cargo.toml` already says 0.19.0. The Linux and Windows builds have been run in Blender; the macOS builds pass the C interface's tests but "have not yet been run in a Blender".
- **The curves are experimental.** `docs/FEATURES.md` marks *Draw Curve* and `--curves` experimental: "curves drawn on a cube leave no edges (#195); the curves drawn are not counted in the sizes and the budget (#196); not kept everywhere (#44)". The headline feature is the one the project trusts least.
- **The benchmark is its own.** `bench/results/SCORES.md` marks each remesher from 0 to 100 with weights the project chose (validity 25, alignment 20, fidelity 15 and so on). At 3,000 quads, averaged over 15 organic models, openclare scores 86, Instant Meshes 64, AutoRemesher 53 and QuadriFlow, the remesher built into Blender, 43. On the four mechanical parts openclare scores 99. The one model `CREDITS.md` labels a scan, a bridge from Keenan Crane's repository, scores 96, and QuadriFlow produced no mesh for it.
- **Limits that bite on scans.** `docs/FEATURES.md` lists "deep pockets and cavities are closed over by the mesh" (#36) and, for sculpts of millions of triangles, "most of the time goes to preprocessing" (#45); *Follow Curvature* carries an open issue for "noisy scans and terrains". The README's own timing is about eight seconds for a 200,000-triangle model at 3,000 quads.
So it fits one step of the loop above: a scanned object or ornament you mean to edit, subdivide or rig, after the scan becomes a mesh. It is not a route to BIM. A wall wants to be one planar element with a thickness, not a well-flowing quad grid, and the element tools earlier in this article are the right shape for that.
### Fable 5.2 in Codex, from an image to a textured model
On 11 November Konstantin Zolozhkov ([@KHvostikk](https://x.com/KHvostikk/status/2120621109125202344)), a Vision Pro and 3D developer, posted a 12-second video captioned "Fable 5.2 codex image ref to 3d model with PBR textures".
The labels in the frame say more than the caption. The reference was "generated by Codex: hero shot and four-view sheet", so the input is a generated image, not a photograph, and the four orthographic views are the part a modeller would actually build from. The model is "31,636 triangles, real geometry, three 4K maps (colour, normal, rough-metal-AO)". One reply spotted that the hero shot reads 3127 and the sheet 127; the model has 127, so the sheet won.
This is a demo and nothing more. There is no file, no wireframe, no UV layout, no count of prompts or time, and no way to tell how much of the look comes from the maps rather than the geometry. Replies asked about topology, UVs and time; in the replies I read, the author gave no figures. For capture work it runs the other way from everything else here: it invents a plausible prop, where a scan measures a real one. As set dressing around a scanned scene it could be useful.
### The Steve Jobs Theater, modelled in Pascal
On 12 November Aymeric Rabot ([@aymericrabot](https://x.com/aymericrabot/status/2120992098904412545)), whose profile says he is "building @pascal", posted a 140-second tour: "Welcome to Steve Jobs theater on the @apple park. It is a marvel of a building. This is the biggest project we have done with @pascal". He replied with a link to the hosted editor, [editor.pascal.app](https://editor.pascal.app), and when Pascal's account asked "You could do that!?", he answered "haha, given enough tokens!". That hints an agent did much of the modelling. The post does not say how.
The most useful thing in the video is its legends. Each services layer says how many of its parts are guessed:
| Layer | Elements | Marked illustrative |
|---|---|---|
| Heating & cooling | 358 | 317 |
| Electrical & lighting | 2,029 | 1,719 |
| Plumbing | 124 | 124 |
Under each: "Some of these parts are illustrative: plausible stand-ins, not documented positions" (for plumbing, "All of these parts"). Across those three layers, 2,160 of 2,511 elements, 86%, are stand-ins. I like that a lot. A model that says which parts are documented and which are invented is worth more than one that only looks complete, and scan-to-BIM needs the same habit for whatever the scanner could not see.
Against [the Pascal section above](#pascal-editor-a-scene-graph-you-can-model-over-a-scan): nothing in this video involves a scan. The post does not say what the model was built from. It is a building at a scale (a theater, its lobby, its services) where Pascal's phone capture path, capped at 20,000 faces, could not serve as a reference anyway. The clip also cannot show whether these are native Pascal nodes (walls, slabs, rooms) or imported meshes, or whether the presentation viewer with its radial layer menu is the open editor, and the post links the editor, not the project. It shows how much Pascal can display. What it can model from a capture is a separate question this video does not touch.