EN TR

Journal

Curated dispatches from the intersection of architecture, AI, and computation.

Industry news, tool deep-dives, and studio notes from Fraktal.

14 articles
From the Studio

Where Architecture Meets AI

Fraktal explores the intersection of computational design, artificial intelligence, and architectural practice. Here we share our research notes, tool reviews, industry news, and perspectives on how emerging technology reshapes the built environment.

0 Articles
0 Events
0 Categories
AI & Tech Jul 2026 4 min
AI Renders in Client Presentations: A Practical Honesty Protocol

AI Renders in Client Presentations: A Practical Honesty Protocol

AI rendering has collapsed the cost of a beautiful image. That is mostly good news for architects, and quietly dangerous for clients. When a photoreal picture takes forty seconds instead of four hours, the temptation is to show more than the design actually promises. After a year of using AI visualization daily, we settled on a small protocol.

Rule one: geometry is authoritative, atmosphere is negotiable. An AI pass may change light, material mood, vegetation, or sky. It may not add a floor, widen a cantilever, or invent a view that the site does not have. If the image contradicts the model, the image loses.

Rule two: label the stage. A concept image is labelled as concept; a design-development render is tied to a model state. Clients do not resent early images being loose; they resent discovering later that a "final look" was a mood board. One line of honest labelling buys years of trust.

Rule three: never let the model design by accident. AI tools will confidently propose details nobody drew: a railing pattern, a soffit, a paving layout. Treat those as suggestions to accept or reject deliberately. If a hallucinated detail survives into the presentation, it has silently become a design decision without an author.

Rule four: keep the boring image next to the beautiful one. We pair every atmospheric render with the plain elevation or massing view it came from. The pairing lets a client fall in love with the mood while still seeing the truth of the geometry.

None of this slows the workflow down. It is one labelling habit and one discipline about who decides what. The speed of AI imaging is the point; the protocol just makes sure the thing being sold at that speed is still the architecture.

Comp. Design Jul 2026 4 min
Your Grasshopper Definition Is a Product: You Are Just Not Shipping It

Your Grasshopper Definition Is a Product: You Are Just Not Shipping It

Somewhere in your office there is a Grasshopper definition that saved a project. It rationalized a facade, or solved a stair, or generated three hundred panel drawings overnight. And today it sits in a folder named after that project, unusable by anyone who did not write it, including, in eight months, the person who wrote it.

We have come to think of this as the biggest wasted asset in computational design. A definition that works is already a product. It has users (your team), a job to be done, and proven value. What it lacks is the unglamorous 20%: named inputs with sane ranges, guards against bad geometry, a note about what it assumes, and a way to fail loudly instead of producing silent garbage.

The upgrade path we use is deliberately boring. First, separate parameters from logic: every magic number becomes a named input with a domain. Second, add validation at the front: if the input surface is not planar within tolerance, say so, do not produce a plausible-looking wrong answer. Third, write the header note: what it does, what it assumes, what it must never be used for. Fourth, and only if the definition earns it: wrap it for people who do not open Grasshopper at all.

That last step is how our own tools happened. FraktalMCP exists because definitions wanted to talk to AI assistants; Falcon AI exists because most of a definition's users should never need to see the canvas. But you do not need to build a product company to benefit. A definitions library with named inputs and honest error messages is already a competitive advantage.

The test is simple: if a new hire can run your best definition without you in the room, you have a tool. If they cannot, you have a memory of a tool.

Architecture Jul 2026 4 min
Scan First, Design Second: Why Existing Conditions Deserve LiDAR

Scan First, Design Second: Why Existing Conditions Deserve LiDAR

Every architect who has worked on a renovation knows the moment: the existing drawings say one thing, the building says another. A wall is 40cm off, a beam nobody documented crosses the ceiling, the "3m" corridor is 2.7m. Most renovation budgets are not blown by ambitious design. They are blown by discovering the building late.

This is why our studio workflow starts with a scan, not a sketch. Phone LiDAR has quietly become good enough for early-stage spatial capture: point your device at a room, walk the space, and you have measurable geometry in minutes instead of a day of laser-distance measurements transcribed into a notebook.

To be precise about what that gives you: fast, reliable room geometry for design decisions: wall positions, openings, ceiling heights, the actual shape of the space. It does not replace an engineering survey where millimeter tolerance is contractually required. Knowing which of those two you need at which stage is the skill.

The workflow we settled on is simple. Scan the space on-site. Clean the capture and pull it into Rhino as the reference model. Design against the building as it actually exists, not as its 1980s drawings claim it exists. Every downstream decision (demolition scope, furniture layout, services routing) inherits the accuracy of that first capture.

We ended up building this workflow into a product: SpaceCraft, our iPhone LiDAR scanner, exists because we wanted the scan-first habit to cost minutes, not billable days. But the habit matters more than the tool. Whatever scanner you use: capture reality first. The building always wins arguments with the drawings.

Comp. Design Jan 2026 4 min
The 10 Grasshopper Plugins That Changed Our Workflow in 2026

The 10 Grasshopper Plugins That Changed Our Workflow in 2026

The Grasshopper plugin ecosystem has quietly evolved from a handful of essential tools into a massive landscape of specialized components. After testing dozens of new releases this year, here are the ten that permanently changed how we work.

Wallacei X remains our go-to for multi-objective optimization. The latest update added real-time Pareto front visualization and integration with external Python objectives. We use it on every project that involves performance-driven form-finding.

Telepathy is the newcomer we are most excited about. It creates live data links between Grasshopper instances running on different machines, enabling distributed parametric workflows. We run heavy environmental simulations on a dedicated workstation while the design team iterates on form on their laptops.

Human UI 2.0 turned our Grasshopper definitions into proper desktop applications. We build client-facing dashboards that let stakeholders adjust design parameters without ever seeing the spaghetti.

Karamba3D 2.2 added nonlinear structural analysis. This matters because real buildings do not behave linearly under extreme loads. We can now run buckling analysis and plastic hinge formation studies directly in Grasshopper.

Heteroptera, Metahopper, Elefront, Lunchbox, Pufferfish, and Anemone round out our daily toolkit. Each solves specific pain points in data management, geometry processing, and iterative workflows.

The ecosystem is what makes Grasshopper irreplaceable. Despite competition from Dynamo and emerging visual programming environments, no platform comes close to this depth of community-built tools.

Architecture Feb 2026 5 min
Zaha Hadid CODE: Inside the Firm's Computational Department

Zaha Hadid CODE: Inside the Firm's Computational Department

Zaha Hadid Architects is often discussed for its formal language, but the real story is computational. ZH CODE, the firm's research and development group, runs a dedicated team of computational designers who build the tools that make those famous geometries buildable.

What makes ZH CODE unique is not just scale but integration. Unlike most firms where the computational team sits adjacent to design, ZH CODE members are embedded in project teams from day one. The parametric model is not a post-rationalization tool; it is the primary design medium.

Their tech stack is instructive: Rhino + Grasshopper as the core platform, with extensive custom C# and Python scripting. For structural optimization, they use a combination of Karamba3D and proprietary finite element tools. Environmental analysis runs through a custom pipeline built on top of Ladybug Tools. Fabrication rationalization uses their own clustering algorithms for panelization.

The insight for smaller studios: ZH CODE did not start at this scale. It grew from a handful of designers who wrote scripts to solve specific project problems. The tools accumulated over two decades into a comprehensive platform. The lesson is that computational capability is built project by project, not purchased off the shelf.

What we find most interesting is their recent investment in machine learning. ZH CODE is training neural networks on the firm's own project archive (decades of built and unbuilt work) to identify patterns in their design decision-making. The goal is not to automate design but to create a computational memory that can suggest relevant precedents when designers face similar challenges.

For firms of our scale, the takeaway is clear: every script you write, every algorithm you develop, is an asset that compounds over time. Build your computational library deliberately.

Architecture Dec 2025 4 min
SHoP Architects' Digital Practice: Lessons for Small Studios

SHoP Architects' Digital Practice: Lessons for Small Studios

SHoP Architects has long been the poster child for digitally integrated practice. They own their fabrication pipeline, build custom software tools, and have spun off technology companies from their R&D work. For a small studio, that sounds impossibly ambitious. But the underlying principles are surprisingly transferable.

Lesson one: own your data pipeline. SHoP's competitive advantage is not any single tool but the seamless flow of data from design through fabrication. At our scale, this means scripting the connections between Rhino, structural analysis, and fabrication output rather than manually exporting and re-importing between software. An afternoon spent writing a Grasshopper-to-Tekla bridge saves weeks of manual coordination across multiple projects.

Lesson two: prototype with real materials early. SHoP is famous for building physical prototypes of complex assemblies before finalizing digital models. You do not need a fabrication lab to do this. We use local CNC services and 3D printing to test joinery details at 1:1 scale. The cost is marginal compared to discovering construction issues on site.

Lesson three: document everything computationally. SHoP does not just design buildings; they design the processes that design buildings. Every project produces reusable algorithms, fabrication templates, and analysis workflows. We have adopted this mindset: project deliverables include not just drawings and models but the Grasshopper definitions and scripts that generated them.

The scale difference between a firm of hundreds and a 5-person studio is real, but the digital mindset scales down gracefully. Start with the data pipeline, build your script library, and prototype physically. These three habits compound.

Fraktal Notes Jul 2026 4 min
SpaceCraft v2: What Rebooting Our LiDAR Scanner Taught Us

SpaceCraft v2: What Rebooting Our LiDAR Scanner Taught Us

SpaceCraft started as a question: what if capturing an existing room took minutes instead of hours? The honest answer took two attempts. The first version tried to be everything at once: meshing engine, material recognizer, universal exporter. It demoed beautifully and was never solid enough to ship. So we rebooted.

SpaceCraft v2 is deliberately narrow. It captures rooms with Apple's LiDAR and RoomPlan stack, processes everything on-device (no cloud, no account) and exports what architects actually ask for first: a USDZ room model and a PDF floor plan, with OBJ and PLY available when the scan captures raw mesh or point-cloud data. That is the whole product, and it will launch free on the App Store.

The accuracy question deserves a straight answer: it depends. Device, lighting, surface quality, and how slowly you walk all move the result. Room captures are reliably good enough for design decisions (wall positions, openings, ceiling heights) and they are not a substitute for an engineering survey where millimeter tolerance is contractual. Knowing which of those two you need at which stage is the real workflow skill, and we would rather say that on the product page than have you discover it on site.

The interesting problem is what happens at larger scales. Keep a scan session open and points keep accumulating: the mesh grows instead of improving. The direction we are researching for the versions after launch is refinement over accumulation: region-level confidence ("this corner is understood, stop adding points"), re-visit passes where new observations correct the surface instead of piling onto it, and coverage-guided prompting that steers you toward what the scan still lacks.

The reboot lesson generalizes well past scanners: a narrow tool that ships beats a broad prototype that demos. SpaceCraft is in App Store preparation now; you can follow the launch at getspacecraft.app.

AI & Tech Jan 2026 4 min
AI-Driven Floor Plan Generation: Where We Are in 2026

AI-Driven Floor Plan Generation: Where We Are in 2026

The AI floor plan generation landscape has changed dramatically since ArchiGAN first demonstrated that neural networks could produce plausible residential layouts. Three years later, the technology is both more capable and more honestly understood.

The current state of the art uses diffusion models, the same architecture behind Stable Diffusion, adapted for architectural plan generation. These models can produce floor plans that satisfy basic spatial constraints: rooms connect through doors, corridors provide circulation, and wet areas cluster near plumbing risers. The visual quality is impressive, but the architectural quality remains questionable.

The fundamental challenge is that a floor plan is not an image. It is a topological graph with geometric embedding, structural constraints, MEP routing requirements, fire egress compliance, and accessibility standards. Current AI models excel at the visual pattern but struggle with the engineering reality. A generated plan might look plausible but place a load-bearing wall where no column exists below, or route a corridor that violates fire egress width requirements.

The most promising approaches combine AI generation with rule-based validation. Systems like the one we built for Archly.ai generate candidate layouts using AI, then filter them through a constraint satisfaction engine that checks structural feasibility, code compliance, and spatial quality metrics. Only layouts that pass all checks reach the architect. This hybrid approach produces fewer options but dramatically higher quality ones.

For practicing architects, the practical advice is: use AI floor plan tools for early-stage exploration, not for production drawings. They are excellent at expanding the design possibility space, showing configurations you might not have considered. But every AI-generated plan needs professional review for buildability, code compliance, and spatial quality. The tool is a starting point, never a final answer.

Architecture Dec 2025 4 min
BIG and the Algorithm: How Data Informs Design at Bjarke Ingels Group

BIG and the Algorithm: How Data Informs Design at Bjarke Ingels Group

Bjarke Ingels Group has built a reputation on formally striking buildings that feel inevitable, as if the design could not have been anything else. What is less discussed is how much of that inevitability is computationally constructed.

BIG's design process starts with what they call "information architecture": assembling every quantifiable constraint into a parametric model before any form is generated. Sun angles, wind patterns, view corridors, zoning setbacks, program requirements, and circulation flows are all encoded as data layers. The design emerges from the intersection of these constraints, not from a sketch on a napkin.

The Mountain Dwellings project in Copenhagen is a canonical example. The cascading residential units are not a formal gesture; they are the geometric result of optimizing for three simultaneous constraints: every unit gets southern sun exposure, every unit has a view of the Oresund strait, and a parking structure fills the northern volume. The "mountain" form is the only shape that satisfies all three.

BIG's computational team, distributed across its offices, builds custom tools for each project. They use Grasshopper for geometric exploration, custom Python scripts for environmental analysis, and proprietary optimization algorithms for complex multi-objective problems. The team structure is similar to ZH CODE: embedded in project teams from concept through construction.

The lesson for smaller practices: BIG proves that computation does not have to mean parametric formalism. Their buildings do not look "computational." They look simple, even obvious. The computation is invisible, buried in the analysis that proves the obvious solution is also the optimal one. That is a powerful model: use computation to validate and refine design intuition, not to replace it.

AI & Tech Jan 2026 4 min
OpenAI o3-mini: What Reasoning Models Mean for Architectural Practice

OpenAI o3-mini: What Reasoning Models Mean for Architectural Practice

OpenAI released o3-mini in January 2026, and the architecture community should be paying attention. Not because it generates floor plans, it does not. Because it reasons through complex multi-constraint problems in ways that directly map to architectural analysis.

We tested o3-mini on three real problems from our studio practice. First, a zoning compliance check: given Istanbul's imar yonetmeligi for a commercial zone, can a 7-story mixed-use building with 60% ground coverage satisfy parking, setback, and FAR requirements simultaneously? o3-mini worked through the calculation correctly, identifying the FAR conflict that our junior architect missed during initial feasibility.

Second, we tested structural intuition: given a 12-meter clear span with residential loading, what beam depth is reasonable for steel, glulam, and reinforced concrete? o3-mini provided ranges that matched our structural engineer's preliminary sizing within 10%.

Third, specification writing: generate a technical specification for curtain wall insulated glass units meeting Istanbul's climate zone requirements. The output was surprisingly detailed, correctly referencing U-value targets and appropriate glass coatings.

The pattern is clear: reasoning models excel at tasks that require combining domain knowledge with logical deduction. They struggle with spatial reasoning, geometric manipulation, and aesthetic judgment. The creative work remains human territory.

AI & Tech Feb 2026 5 min
Claude as a Grasshopper Code Reviewer: What Works, What Fails

Claude as a Grasshopper Code Reviewer: What Works, What Fails

Somewhere in the last year, Claude quietly became part of how Grasshopper work gets reviewed in this studio. Not for generating geometry, for critique. The studio runs on a library of definitions accumulated across projects, and when one breaks or needs a handover, understanding its logic is the slow part. Comments are sparse; variable naming has moods. We started pasting the work into Claude and asking it to find problems.

The workflow is deliberately plain. For a definition, we serialize it into structured text (every component with its inputs, outputs, and connections) and ask for a structural review: unused components, null-reference risks, wasteful data-tree operations, opportunities to simplify. For Python and C# script components, the code goes in directly, together with the before and after versions whenever something changes.

It catches real things. In one project it flagged a Dispatch component downstream of a Cull Pattern as redundant: the culling had already filtered exactly what the Dispatch was supposed to separate. In another, it suggested collapsing a chain of Closest Point components into a single Pull Point operation; we never benchmarked the speed difference, but the canvas became readable, which was the actual win. And before any modified script component is committed, both versions go through a diff review: off-by-one errors, type mismatches, and null risks surface consistently.

The failure modes are just as consistent. Claude does not reason spatially: it cannot tell you a curve offset will self-intersect or that a boolean will fail on one specific input. It reads Grasshopper as a dataflow program (which it is), but it has never felt the canvas. The working posture that survives contact: treat it as a well-read junior developer who has studied all the documentation and never once opened the software.

Two honest caveats to close. First, the review is only as good as the serialization: a definition too tangled to explain is also too tangled to review, and that says more about the definition than about the reviewer. Second, this is a habit, not a product: ten minutes per definition, and any capable model could likely do it. We are exploring building this review loop into Falcon AI, but the underlying discipline (named inputs, honest error paths, definitions that can explain themselves) is the part your studio can adopt this week, no AI required.

Explore More

Follow our research, stories, and updates across platforms.

Read on Medium

In-depth articles on architecture, computation, and AI research.
Watch on YouTube

Tutorials, walkthroughs, and behind-the-scenes studio content.
Connect on LinkedIn

Professional updates, project announcements, and industry insights.
Follow on Instagram

Visual stories from studio life, design process, and project snapshots.