Sarat Babu – Six Questions – CDFAM Tokyo
We first met in 2014, in the frothy days of peak 3D printing hype, when I was trying to give Autodesk’s money away as part of the $100 million Spark investment fund and you were doing the most advanced DFAM I had ever seen at Betatype. Unfortunately we never found a way to funnel that money in your direction. So tell me, what happened to Betatype, and what have you been doing since?
Hah, well that’s definitely more on me than on you! There was no doubt in my mind that 3D printing was going to change the way we design and make things.
I just lacked a convincing case for the big picture: how it was going to land and a timeline investors (including you) could get behind. Back then, no one had demonstrated broad, scalable value, it was all speculative.
I felt like the only way to build a vision was to be at the frontier: real end-use applications. So that’s how we built Betatype: software that pushed laser powder bed fusion (LPBF) hardware as far as it would let us, and instead of selling the software, we focused entirely on developing solutions for partners.
That approach told us where the challenges were, everything from concept design to optical galvo behaviour from machine to machine. Every feature we developed was customer led. As is the nature of these things, a lot of the parts we worked on will never be seen in public. But I distinctly remember walking through a Seattle Nordstrom and seeing the Uniform Wares Nato Watch Strap on display. A part we had designed and built in-house from paper sketch all the way to final production. That was a highlight.
Uniform Wares M-Line cases with Titanium Nato Watchstraps in Nordstrom, Seattle, 2019.
By the end 2019 it was obvious to me that organic growth was now the bottleneck. In OxMet Technologies we found a partner: strong synergy between our technology stacks and alignment on the long-term vision. Alloyed, the resulting company, has been going from strength to strength since 2020. (Alloyed will also be presenting at CDFAM Tokyo 2026)
After two years at Alloyed, I needed to take a break from management and sink my teeth back into technical work. I joined Meta’s Reality Labs working on wearable hardware. While I can’t go into details of that work, it was eye-opening to view the 3D printing industry through the lens of a product owner and re-examine what makes the technology both compelling and frustrating.
Last year I returned to London, keen to get back to working in smaller, earlier-stage organisations. It was also a chance to start exploring computational design again, and that has led me here, presenting at CDFAM Tokyo.
Toolpath as geometry is something we are seeing at the larger scale in WAAM and pellet-fed FDM, but not so often in laser powder bed fusion. What do you think blocks people from exploring this, given the broad potential to architect both geometry and material performance simultaneously?
While you could point to technical hurdles being the reason, I’d put emphasis on the commercial models gating development.
There were two early assumptions about LPBF: (1) that it only competes with processes for producing high-value, low-quantity parts, and (2) that it cannot be (easily) commoditised. If that’s your baseline, then it justifies pricing a black-boxed medium-frame LPBF machine at $1m a pop.
So, cost alone made getting direct access to equipment difficult. If you managed to solve that, you then needed to build deep partnerships with the machine vendors before you could actually drive toolpaths.
In the last few years, things have changed a lot with official APIs and more system choice making access more readily available.
But access aside, the reality is toolpath engineering for one-off, low-volume use cases has little value. And frankly that is still a significant proportion of what LPBF is used for today. There are a few users out there who want to build in large volume, or to build parts at the edge of the hardware’s resolution capability.
Either way, toolpath engineering is the way forward. As LPBF becomes more of a commodity and we see more serial high-volume production, we will inevitably see toolpath engineering as a staple activity.
It’s no different from dialling in any mass production process like the cycle time on an injection moulding tool. Except instead of a handful of parameters you’re dealing with potential terabytes of control data.
Can you tell us about the custom software workflow you have developed rather than using commercially available tools, and what drove the decision to build your own? Was it technical capability, financial, or both?
In short, it was curiosity about what could be technically achieved on a shoestring budget:
I was walking out of CDFAM Barcelona, excited by a few of the presentations on ways people were working with LLMs. I was less compelled by fully generative solutions than those where the technology was used to build new tools and workflows.
I have always been a believer that authoring your own tools is the only way to break out of the creative limitations that any off-the-shelf software imposes. As the saying goes: “if you only have a hammer, everything looks like a nail”.
So out of interest, I figured I’d jump on the current hype-wagon of using LLMs to execute an idea I had that I knew I would struggle to deliver in any single environment that I had access to. The truth is I haven’t personally coded since around 2011.
At Betatype we built an incredible software engineering team that, unfortunately for them, had to put up with a lot of my different ideas. All of those ideas needed a physical proof of concept and that was an arduous manual workflow with everything from Rhino Grasshopper sketches to notepad-stitched toolpaths. If I managed to build convincing parts then I’d work closely with the software team to architect the solutions.
Frankly, getting back into computational design was not something I was ever expecting to do again. Not out of a shortage of ideas, but more in terms of the energy it takes to realise them. LLMs felt like they could be a fun, lighthearted way to get back into the space. However, I ended up co-opting a few technical partners: Metisec (www.metisec.co.uk) to help guide the mechanical engineering and Nexus (www.nexus-am.com) to print and validate parts. In the end though it was not just the resulting parts that were compelling, but what it means for the next generation of computational designers and engineers.
These parts still have to connect to larger assemblies and simulation workflows. How is that handled on the data side? And speaking of data: 3MF, nice. What did using that format open up?
Every piece of software that deals with geometry weds itself to a modelling archetype.
That can be BREPs, Meshes or Implicits. All these representations have their strengths and weaknesses depending on the geometric process you want to execute.
So one of the things I wanted to escape when authoring these new geometry tools was being beholden to a single modelling approach.
I ended up using 3MF meshes for CAD import, simple beams for growing structures and the implicit as the master representation. For simulation, the FEA mesh is generated directly from the implicit.
All possible thanks to the wealth of open libraries and file specifications like VDB and 3MF. As for 3MF itself, it surpasses STL with things like fixed units, compression and multiple objects per file. Critically, the spec is open and simple (a zip archive with an XML model inside), so building a reader and writer from scratch when the library one fell over on multi-object files was straightforward.
On the question of larger assemblies, I’ll be honest and say it was out of scope for this project. But if we’re considering this in the context of a hybrid modelling workflow there is a big question about how to handle design provenance as you switch between representations.
One of the things I implemented in the workflow was a sidecar file at every step to keep a detailed record, but it drops off the moment you export a mesh for someone else’s software.
Tell us a little, but not too much, about the case study you will be presenting in Tokyo.
Around 2010, in the early days of working with 3D printing, I designed a pair of bicycle handlebars made from selectively laser-sintered carbon-filled polyamide.
It was a cool part! Unfortunately not quite as mechanically sound as I had hoped. Turns out the design was, Sub Optimal. Let’s hope second time’s the charm.
Stock bullhorn handlebar (top), Selectively Laser Sintered Carbon filled polyamide handlebar (bottom), 2010
What do you hope people take away from the presentation, and what do you hope to gain from presenting at CDFAM?
For me this is a talk that hopefully inspires new creative ideas rather than a debate about my particular method.
I’m not arguing for replacing the tools or workflows we have today, especially at an enterprise level. But if you have a concept you want to explore that sits outside of the bounds of the common tools at your disposal, the barrier to entry to build your own just dropped substantially.
Looking forward to discussing it with attendees at CDFAM Tokyo, and to hearing where they think it falls short.
If you would like to learn more about Sarat’s approach, along with other experts from industry and academia at the bleeding edge of industrial design, engineering and architecture, join us at CDFAM TOKYO October 8-9 2026 to connect in person.
If you cannot join us this year, subscribe for updates about future events and search the CDFAM index from previous presentations and interview to deep dive into topics as wide as architected materials to architectural systems.
