Nodi: A Unified Computational Design Platform For Additive Manufacturing Workflows
Interview with Masatatsu NAKAMURA
Masatatsu Nakamura, founder and developer of Nodi, answered six questions ahead of his presentation at CDFAM Tokyo on the node-based CAD/CAE platform he is building for metal additive manufacturing.
In the interview he covers his path from real-time graphics at teamLab to writing a CAD kernel and CAE solver from the ground up, how Nodi treats lattice geometry, material behavior and manufacturing limits as a single iterable process, and where implicit modeling still has to hand off to B-Rep and existing engineering tools.
Can you tell us a little about your background in real-time graphics and 3D software, and what led you to start building Nodi?
From 2014 to 2021, I worked at teamLab, where I was involved in developing real-time graphics and interactive 3D systems, primarily in Unity.
In real-time artworks, nothing is pre-rendered; the space and imagery are continuously computed on the spot in response to the viewers’ behavior and the surrounding conditions. Through that experience, I became more interested in designing the rules from which shapes and behaviors emerge than in producing finished 3D geometry.
Later, I learned that in manufacturing and architecture, procedural modeling was already being used in real design processes to handle complex geometry and design constraints. From there, my interest shifted from simply using existing CAD tools to building CAD software itself.
The idea behind Nodi is to treat geometry not as static, finished data, but as a system that can be recomputed in response to its input conditions. If the entire workflow, from geometry generation through analysis, optimization, and export, can be composed as a node graph, it can flexibly follow changes in design requirements.
Additive Manufacturing in particular is a remarkably good fit for programmable design, because it can actually produce the complex geometries that were impossible with conventional processes. Seeing that potential, Nodi today focuses specifically on design and engineering for metal AM.
Can you introduce us to Nodi, what the platform does, and what the presentation will cover at CDFAM?
Nodi is a node-based CAD/CAE platform focused on design and engineering for metal AM.
In addition to geometry design that combines B-Rep and Implicit Modeling, it handles lattice and TPMS generation, internal flow channels, structural analysis, and topology optimization, all within a single node graph. The goal is not to create complex shapes for their own sake, but to build a workflow in which geometry generation, performance evaluation, and manufacturability checks can be recomputed as the design changes.
For example, when load conditions or the design domain change, the entire chain of analysis, lattice generation, geometry integration, and export can be re-executed from the same graph. A major advantage of the node-based approach is that the design data captures not only the final shape, but also the conditions and steps from which that shape was produced.
We are also currently developing a system in which AI generates and edits node graphs based on natural-language instructions.
At CDFAM, in addition to introducing Nodi’s capabilities, I will talk about how to bring geometry generated with Implicit Modeling into real product design, including analysis, manufacturability verification, and integration with existing CAD, CAE, and CAM tools.
Implicits are highly efficient for generating lattices, internal flow channels, and geometry whose properties vary continuously. In practice, however, once the shape is created, its performance must be verified, its manufacturability confirmed, and the result handed over to existing engineering tools. In the presentation, I will share not only the potential of Implicits, but also the challenges that arise when connecting them to real manufacturing processes, and the approaches we are exploring in Nodi.
Building a CAD kernel and CAE solver from the ground up is a considerable undertaking. What drove the decision to develop your own rather than build on existing kernels, and what did that make possible?
Reinventing every technology from scratch is not Nodi’s goal in itself. We chose in-house development because we needed to control the data representations and computational processes that sit between geometry generation and analysis.
What Nodi aims for is not to run modeling and analysis as separate stages, but to bind geometry and physics together into a single, iterable computational process.
It is possible to build such a system by chaining existing kernels and solvers. However, because each has its own internal representation, geometry conversion and remeshing are required between stages. When design and analysis are iterated many times on complex Implicit geometry, these conversions become a source of computational cost and information loss, and a bottleneck for design exploration.
By controlling the core computational technology ourselves, analysis results can be used not merely for visualization, but as input for generating the next geometry. For example, lattice beam diameters can be varied according to stress magnitude, or principal stress directions can be used as a reference for orientation.
Moreover, the loop of modifying geometry based on analysis results and re-analyzing that geometry can be built as a node graph, without shuttling data back and forth between external tools. Being able to treat a design not as a static model but as a system that updates in response to boundary conditions and performance requirements is the major benefit we gained from in-house development.
On the other hand, generating a fully boundary-conforming mesh for complex Implicit geometry every time is a significant burden. For that reason, alongside analysis on structured grids, Nodi also treats analysis methods that pair well with Implicits, such as Immersed FEM, which does not require a boundary-conforming mesh, as an important area of research and development.
Lattice structures sit at the intersection of geometry, architected material behavior and fabrication limits. How does Nodi handle the relationship between the three?
In Nodi, a lattice is treated not as a repetition of uniform cells, but as a structure whose geometry and properties can vary spatially.
Cell size, beam diameter, density, orientation, and cell type can all be varied according to position or analysis results. For example, a design can thicken beams in high-stress regions and orient the structure along the principal stress directions.
In a lattice, changing the geometry directly changes the material properties of the structure as a whole. Even with the same base material, stiffness, anisotropy, and weight vary with cell type, relative density, and orientation. That is why it is important not to treat lattice generation and structural analysis as independent stages, but to feed the analysis results back into the next round of geometry generation.
Furthermore, a mechanically superior shape is not necessarily manufacturable. In metal AM, overhang angles, minimum wall thickness, minimum beam diameter, enclosed voids, powder removal paths, and build orientation must also be taken into account. Optimizing for structural performance alone may lead to beams that are too thin, or orientations that cannot be built without supports.
Manufacturing constraints therefore need to be treated not as a checklist at the end of the design, but as inputs for deciding cell geometry and orientation. For example, when alignment with the principal stress directions and a highly self-supporting orientation do not coincide, the trade-off between the two has to be explored.
In Nodi, we attempt to treat all of this as an iterable process by composing geometry generation, analysis, manufacturability evaluation, and parameter updates as a node graph. Rather than evaluating performance, material properties, and manufacturability separately, we believe it is important to embed their interactions into the design process itself.
How does data move through Nodi from implicit model to analysis to build-ready output, and how does it connect with other tools in an existing engineering workflow?
In Nodi, the entire pipeline, from input geometry through modeling, analysis, optimization, and export, is composed as a single node graph. Because the graph preserves not only the final shape but also the input conditions, parameters, and processing steps that produced it, the same process can be re-executed after design conditions change.
That said, we do not use the same geometry representation at every stage. B-Rep is used where the mechanical design requires well-defined faces and edges, while Implicits are used for lattices, TPMS, internal flow channels, and continuously varying geometry. At the analysis and manufacturing output stages, the geometry is converted into an appropriate discrete representation depending on the purpose.
For output, we currently use common mesh formats such as STL, as well as 3MF. 3MF in particular allows the outer shell to be stored as a mesh while the internal structure is stored as a beam lattice within the same file. Since there is no need to expand every beam into a triangle mesh, it is well suited to exchanging large design data that contains lattices. However, support for each 3MF feature varies between build-preparation software packages.
At the same time, in today’s manufacturing industry, B-Rep functions not just as a geometry representation but as a common protocol connecting CAD, CAE, CAM, inspection, and more. How to connect Implicit geometry to this ecosystem remains a major challenge.
Fully automatic conversion of arbitrary Implicit geometry into high-quality B-Rep, while preserving design intent and geometric features, is not yet practical. There are approaches such as reconstructing surfaces from a quad mesh, but the appropriate conversion method depends on the required accuracy, the complexity of the shape, and the editability needed in downstream processes.
There are also cases where customers require analysis results from existing tools such as Ansys as the basis for design approval or verification. So rather than trying to complete everything within Nodi, it is important to decide, for each use case, how far to keep processing in Implicit form and at what stage to hand off to existing tools.
In the future, as analysis and manufacturing software becomes able to handle Implicits directly across a wider range, I believe the Implicit kernel itself could become a new protocol connecting geometry generation, analysis, and manufacturing. For now, however, we prioritize using B-Rep, Implicits, and meshes according to purpose, and connecting to existing engineering processes in a practical way.
What do you hope the CDFAM audience takes away from the presentation, and what are you hoping to learn from the other presenters and attendees in Tokyo?
What I want to convey through this presentation is that each design representation has its own strengths and weaknesses, and there is no need to solve everything with a single representation.
Implicits excel at complex geometry and continuous shape variation, but are weak at local edits such as selecting a specific edge and chamfering it. B-Rep excels at those kinds of mechanical design operations and at integration with existing processes. At this point, I believe the most practical approach is not to pit the two against each other, but to use them together appropriately.
Another theme is AI. Node-based design has a strong affinity with CAD as Code, allowing AI to generate design procedures and modify workflows according to conditions.
At the same time, AI cannot fully understand the intent a designer has not verbalized, the manufacturing know-how specific to each company, or the responsibility for the outcome. We need to think about how to combine what AI does well, exploration and automation, with what humans are responsible for: setting goals and making judgments.
At CDFAM, I hope to learn how other speakers and attendees are connecting computational design to real manufacturing. In particular, I would like to exchange views on manufacturability evaluation, interoperability with existing tools, and collaboration between AI and designers, and turn those conversations into new joint developments and workflows.
Masatatsu Nakamura will expand on these ideas at CDFAM Tokyo, October 8 – 9, 2026, alongside others working on computational design for manufacturing. Join us to meet them. Registration is open at cdfam.com/tokyo-2026.
