One evening. A reference photograph, a browser app built from conversation, and 650 objects standing in a live ArchiCAD model. Here is what worked, and the 5 things that did not.
I sent a photograph of the Al Bahar Towers and said: build me an app that generates this, then link it to ArchiCAD.
Not a render. Not a diagram. A working tool, and then the tool talking to my BIM model.
That is the part worth writing about. The design was the easy half. The half that has never been easy is getting a parametric idea out of a sandbox and into the model that actually issues the drawings, and that is the gap that closed this week.
What came out the other end
The app writes a placement file. Claude talks to ArchiCAD over MCP using the Tapir add-on, embeds the library part, places every panel and sets each one's parameters. Two interfaces, one conversation.
I got the module wrong twice. That is not a failure of the process, that is the process, and it is worth showing rather than tidying away.
The first attempt came back as one continuous folded surface. Elegant, wrong. The Al Bahar screen is not a surface, it is a few thousand discrete kinetic units standing about 2 m off a glass curtain wall, each with its own actuator.
So I said so. The second attempt was a hexagon that folded like an umbrella. Closer, still wrong. I sent two more images: a construction photograph, and the IAAC diagram showing the module built from a triangle, its 3 edge midpoints, and a centre node.
That landed. The module is a triangular cell carrying 3 four-point panels. The corners are fixed frame nodes. The centre node travels out on the actuator and the midpoints draw in, which is what opens the slots and lets the glass show.
I did not describe geometry. I described a mechanism, and corrected it until the mechanism was right.
Then I caught something by eye that no number had flagged. The rows were not staggered. Looking at the elevation, the pattern read as continuous horizontal slots instead of the six-pointed rosettes in the photograph.
The cause turned out to be exact: successive rows were not offset by half a cell, so one row's apexes landed between the next row's bases and the structural nodes never met. One line of code. After the fix, every interior node is shared by exactly 6 units, 0 failures across the grid.
Describing a device instead of drawing one. The kinetic unit ended up with a single driving parameter: openness, 0 to 1. A real mashrabiya has one actuator, so the BIM object should have one handle. Every other number in the app hangs off that.
Being told no. The app reports mean shading, how many distinct actuator positions the control system would need, and how far each panel goes out of plane. When I pushed the travel to 650 mm it told me the panels were warping past a quarter of the cell, which is the point where a flat cut stops working and you need a properly patterned double-curved one. That is the tool earning its keep.
The library part building itself. ArchiCAD ships a converter inside its own app bundle that turns a library part XML into a .gsm. So the object is generated from the same source the app previews from. No New Object dialog, no pasting 4 scripts, no typing 11 parameters and getting one subtly wrong.
Iteration being cheap. Change the design, press Sync, re-run. Nothing about the library part changes, because the entire pattern lives in the per-instance parameters. Placing 264 panels takes about a second.
5 things went wrong, and 4 of them were the API rather than the design.
1. A 30 minute hang. One innocuous call, ReloadLibraries, blocked the whole JSON interface and never returned. Embedding registers the part on its own, so the call was not even needed. Cost: half an hour, and a stretch where I could not tell whether anything had been created.
2. A part that embedded and then could not be found. The generated library part had an empty ancestry, so ArchiCAD accepted the file and then had no idea it was a placeable object. It needs to declare that it descends from General GDL Object.
3. A path that works exactly once. Embedding to a bare filename succeeds the first time and is refused ever after, because the file is already sitting there. A folder path is fine. Nothing says so.
4. A boolean that had to be a real boolean. The placement file stored orientation as 0 and 1. The API rejects an integer for a boolean parameter.
The 5th one is the one worth learning from, because it did not throw an error at all.
5. A facade that built perfectly and was wrong. The run reported 130 placed, 130 driven, zero failures. It was only when I read the values back off the model that I found every unit was using the library part's default travel of 450 mm instead of my design's 650 mm. I had pushed the per-unit parameters and forgotten the shared ones. It looked completely plausible.
And one still open. The bounding boxes suggest the panels may be sitting back rather than standing up, which is a coordinate convention I have not yet settled. I am leaving that in this article rather than quietly fixing it, because the honest version of this workflow includes the bit that is still unresolved at the point of writing.
Both apps land on the same structure, and I think it is the transferable idea.
You do not push a mesh into the model. You define one parametric object, then place it many times and give each instance its own numbers. The model stays light, every panel remains schedulable, and changing the design means rewriting parameters rather than rebuilding geometry.
The second app makes the point harder. A triangular precast cell with an outer triangle at the wall face and an inner triangle scaled and set proud of it. Open the inner triangle and you get a deep splayed frame. Collapse it to nearly nothing with some depth and the 3 faces meet at a point, which is a faceted pyramid. Collapse it with no depth and you get a flat panel.
Every one of those is the same casting at a different setting. So the whole elevation, gaping frames at one end and flat panels at the other, is 2 numbers per cell.
Which is exactly the question a precaster asks first, so the app counts the moulds live while you drag. 306 cells, 15 moulds. That number is the difference between a facade that gets built and one that gets value-managed out.
This is the observation I actually want to leave you with.
Everything above is squarely Grasshopper territory. Triangular grids, attractor-driven variation, folding modules. It is also territory most architects never enter, because the entry price is learning a visual programming language well enough to think in it, and then keeping that skill warm.
I did not open Grasshopper. I described a mechanism in English, corrected it when it came back wrong, pointed at photographs when words were not enough, and made judgement calls about whether the result looked like the reference.
The skill that mattered was knowing what the facade should do. Not knowing how to wire a definition together.
And it went further than generating geometry. It went into the model, as native objects, with their parameters set, without me drawing a single panel. The labour of manual drafting, the part that eats the afternoon and produces nothing you could not have described in a sentence, simply was not in the loop.
That is a real widening of who gets to design this way. Not because the tool designs for you, but because it removes the two tolls: learning the language, and then doing the drafting.
You still have to know what good looks like. Every correction in this piece came from me looking at something and saying it was wrong. The machine cannot want the rosettes.
It will build the wrong thing confidently. Twice it produced clean, verified, well-documented geometry that was not the device I asked for. Fluent output is not correct output.
The API is where the time goes. The design took minutes. The 4 interface problems took the bulk of the session, and none of them were interesting.
It is a study, not a facade. No structure, no fixings, no thermal movement, no tolerance strategy, no fire. It is a geometry and quantity tool that hands the model something real to schedule, which is exactly what it is good for and nothing more.
Kinetic Mashrabiya is the responsive screen. Precast Relief is the cast one. Drop any image in and it becomes the pattern.
The ArchiCAD half needs the Tapir add-on and runs locally, so the published versions are the design tools without the model link.