CDFG / MIT CSAIL

Open problems

The Computational Design and Fabrication Group develops AI for the physical world. We start with representations of materials, structures, mechanisms, and robots that AI can synthesize and a solver can verify. We build physics simulators that run forward from a design to its performance and backward from a target to a design. We run discovery systems that propose new materials and molecules, test them on real instruments, and learn from what came back. And we build what makes them real: 3D printers that watch themselves print, knitting machines, automated labs.

AI is not a layer on top of this but is built into the representations, the discovery loop, and the machines themselves.

01 / Method

How we work

Every design problem we take on asks the same four questions.

01
How do you represent a design, and the space of designs around it?A representation a machine can write and a solver can check, rather than a picture that merely looks right.
02
How do you learn that space when the data is thin?In most physical design domains the data are expensive, heterogeneous, and sparse against the size of the space being searched. A published dataset for a class of polymers may hold twenty measured formulations. Methods that need a million examples do not apply.
03
How do you search it for designs that actually perform?Predicting performance from a design is usually the more tractable direction. Going the other way, from a target to a design that meets it, is the harder problem and the one worth solving.
04
How do you close the gap between the simulator and the world?Simulation disagrees with the bench often enough that a design verified only in software is a hypothesis, not a result.

Metamaterials answer all four in one line of work. A procedural language describes the geometry. Fifty hand-written programs grow into a database of 150,000 through sampling, mutation, and hybridization, which is how thin data becomes enough. A model then writes a program from a plain-language specification of the properties you want, and the program is simulated to check whether it delivered them. What gets printed and pulled on the bench decides whether the simulator was telling the truth.

The domains change. Metamaterials, molecules, robots, drones, printers. The questions do not. That is the point of working across unrelated fields: a representation or a solver that holds up in only one domain has probably fit that domain's quirks rather than found something general. Each new field is a test of whether the method is real, and it sets who does well here: people who would rather learn a new field than reuse a familiar one.

02 / Now

Three open problems

Three questions drive the group today. Each one is open, funded, and taking new students.

Families of metamaterial geometry generated by a procedural graph program
01

Domain-specific languages for design

Design languages that capture the world, and AI that designs within those languages

Programs, not pixels. We build design languages that a machine can write and a solver can check, so that a generated artifact is correct by construction rather than plausible by appearance.

What you would work onSolver-aided languages for LLM-driven CAD, procedural graph representations, and program synthesis for materials. Suits people who care about both program semantics and the geometry that comes out the other end.
Four cars from the DrivAerML benchmark, each showing predicted surface pressure and the airflow around it
02

Neural physics surrogates

From a design to its performance, and back again

Learned simulators that preserve physical structure and can be checked against a classical solver. The aim is models that replace or accelerate those solvers without discarding the constraints and invariants that make them trustworthy.

What you would work onModular neural simulators, differentiable physics, and scalable contact. Expect numerical methods alongside deep learning, not one instead of the other.
Families of microstructures discovered by searching a material property space
03

AI for scientific discovery

Find the limits of design, then break them

Closing the loop from hypothesis to experiment. Discovery systems that propose candidates, run them on real instruments, and learn from what actually came back.

What you would work onAutonomous experimentation for materials, molecules, proteins, and the instruments themselves. Suits people who want a result they can hold, and who are willing to wait on an instrument to produce it.
03 / Why now

The bet

Generative AI is saturating text and code. The physical world is different: a material, a machine, or a controller has to work in reality, and plausible is not the same as working. We think the next frontier for AI is exactly there, in objects, materials, machines, and instruments.

Working on that frontier takes two things that rarely sit in one group: current AI, and the means to test what it produces against reality. Both go back a long way here. The 2003 doctoral thesis built a data-driven generative model of reflectance, two decades before generative models moved to the center of AI. Fabrication followed in 2009, with two papers on manufacturing a surface to a specified reflectance. That is why we have printers, knitting machines, robots, instruments, the solvers that model them, and the datasets they produce. Vision-controlled jetting is what the pairing looks like: a printing process guided by machine vision, and a robotic hand it printed, in Nature in 2023.

The three problems above are one loop, not three projects. Design languages capture the world; simulators run from a design to its performance and back; discovery systems push on the limits of design and hand back candidates; fabrication builds them. What comes back from the physical world becomes the next round of data. Loops compound.

A teapot rendered from a measured reflectance model Photorealistic 3D hologram computed with a deep neural network A 3D printed mechanical cheetah with computed gear trains 3D printed robotic hand with tendons

Part of the archive the next systems stand on: measured reflectance, neural holography, mechanical characters, a printed hand.

04 / Ahead

Designing beyond data

The near-term version is a design language and a copilot for each domain we work in: a small, readable language that describes the domain in its own vocabulary, a model that writes programs in that language from a plain-language brief, and a compiler and solver that check the result before anything is built. The output is a program rather than an answer, which means it can be read, tested, versioned, and rejected.

The harder problem is designing beyond data. AI trained on what worked learns the patterns of what worked: it copies, refines, and optimizes, which is useful right up until the answer lies outside the pattern. And the rules that constrain a design hardest are the ones nobody wrote down, the assumptions baked in deep enough to pass for truth. We are building systems that treat those assumptions as the rules of a game rather than as facts, and that can work out which ones are worth breaking. In our own soft-robot benchmark, an evolved design jumped higher than anything the group had built by hand, in a shape nobody would have drawn. That problem is open, and it is the one we would most like to solve. Success would be a partner rather than a brilliant apprentice: a system that does not only answer the question it was handed but asks whether the frame around it is right, and that can tell which of our assumptions are load-bearing and which are only habits. The measure is whether that produces the kind of shift climate change, pandemics, and scarcity actually demand, rather than a faster version of what we already know how to build.

05 / Foundations

What this rests on

The three open problems above rest on long-running work in computer graphics, computational design and fabrication, computer vision, and robotics. Each strand below opens the papers behind it. The measurements behind the reflectance work are public as the MERL BRDF database.