Volumetrics, Thermals and Fields: Expanding Grasshopper 2 into Mechanical Engineering Workflows
Interview with Rhino developer Mathias Fuchs
As Rhino’s Grasshopper 2 moves beyond parametric modeling into simulation-native territory, developers like Mathias Fuchs are helping expand its role from geometry engine to integrated design-analysis platform.
With TRmesh and TRfem—two plugins that bring tetrahedral meshing and real-time heat simulation directly into the Grasshopper environment—Fuchs is helping to unlock new workflows for mechanical engineers, product designers, and anyone working with field-driven geometry.
In this interview ahead of his presentation at CDFAM Amsterdam, he shares how the core architectural updates in GH2—native parallelism, field-first data structures, and built-in visualization tools—support these advanced capabilities.
The conversation explores how simulation can drive topology and performance, how volumetric data can be applied in additive manufacturing, and why GH2’s architecture eliminates many of the bottlenecks in traditional multi-software pipelines.
Can you start by telling us a little about your role at McNeel and how you first became involved in the development of Rhino and Grasshopper?
At McNeel, I have the honor to work fully on Grasshopper 2, assisting the great David Rutten with a few coding tasks here and there, particularly some math-heavy or computational ones.
These days, I am mainly working on solvers for water shedding but topics I have contributed to include meshing, improving visual and analytical precision, Voronois, ODE solving and other tools to enrich the design toolbox.
Apart from particle-based simulations, the accurate flow simulations we are seeing are very rudimentary.
Obviously, we target a large architectural audience, but we have identified many tasks, say in mesh processing and display, that are very hard with the existing tools, and a flow analysis, regardless of whether it is for architecture or for a direct design intent in any other discipline, is one of them. It goes without saying that almost the entirety of Grasshopper 2 is his – I am just adding a bit of extra Math feature flavor. This is an extremely challenging but rewarding thing to do!
I met David at the Rhino World conference in Barcelona in 2023. At first, we spoke about the real numbers over a piece of paper and he asked me about convergence speed estimates – a topic he has always been intrigued by. Later, we spoke about my plugins and about algorithms in computational geometry. Our shared interest was in field visualization, and in that topic Tweener might have caught his interest – maybe, the aesthetic appeal of harmonic color gradients or my stubbornness about finite elements … Of course, I also showed him TRmesh and TRfem for heat simulation.
GH2 is intended to have a deeper focus on Math than GH1 – and computational geometry is certainly hard enough to keep two people busy!
Contributing to GH2 is, of course, more than I would ever have dared to dream of, it’s a great honour for me. I learned a lot from David, in particular from his attention to detail and his impressive intuition about great UI/UX.
What will you be presenting at CDFAM Amsterdam, and how does it connect to the broader developments you’ve been working on?
I will present Grasshopper 2, will shed some light on why I think it is an ideal platform for simulation, analysis and visualization – in comparison to GH1.
I will then present my own plugins TRmesh and TRfem for the generation of tetrahedral meshes, heat conduction simulation, and the generation of isosurfaces.
I would like to have simulation and geometry go hand in hand instead of seeing them spread out over a variety of tools, and I hope that offering a tet mesher together with a heat solver shows that the bad reputation of tet meshes is, in some parts, undeserved.
A modern tetrahedral mesher, if properly incorporated into the CAD environment, is very robust, versatile, accurate, expressive, and performant. Currently, a production-grade topology workflow that incorporates simulation with external tools is incredibly cumbersome, and I want to show that Rhino and GH2 can be used for simulation beyond mere “physics-inspired” design. I hope this will significantly lower the barrier for designers to engage with analysis.
TRmesh enables tetrahedral meshing directly inside Grasshopper, skipping export steps, and TRfem enables design-time heat conduction analysis.
These can be used for material studies, sustainability, and much more.
One overarching way to generate geometry is isosurface generation, and I want to show how we can use it to bridge form-finding and topology optimization.
The whole workflow is to go from geometry to a tetrahedral mesh that is used for heat simulation, and I will do a first public showcase of how such a temperature field can then be used and processed in the “GH2 way”: through live, composable components that consume, process, and visualize fields by treating them, along with functions, as first-class citizens.
Your work with TRfem and TRmesh brings volumetric data into the Rhino and Grasshopper environment. How are you approaching the input, representation, and export of volumetric domains — and have you explored using 3MF or other formats for additive manufacturing workflows?
Another great question. I’m excited about the possibility of exporting scalar fields such as temperature from TRfem into formats like the 3MF volumetric extension. It should be a great feature, and not too hard to write, to generate a voxel field for export. So far, my focus has been on setting up a robust mesher, TRmesh, with a basic heat conduction solver, TRfem. Export to voxel-based formats is not yet there but will be a great addition!
As for a comparison of tet meshes vs voxel-based formats: Voxel grids are easy to generate and store. There are very effective heat solvers on voxel grids, but other types of simulation such as linear elasticity are harder to do accurately on voxels using finite differences. Voxels require very high resolution to overcome aliasing and achieve acceptable accuracy. On the other hand, tetrahedral meshes are very hard to generate. But once generated, they are highly versatile and well-suited to a broad range of simulations.
For many decades, they have been the most popular substrate of finite element methods, and they are very unlikely to go away anytime soon. Once a rough tetrahedral mesh that describes the basic features of a given geometry has been generated, it is easy to refine one either locally or globally and keep the preservation of geometric features and enhance the numerical accuracy.
So, it is almost as if there was a bit of a “duality”: voxels are easy to generate but not very straightforward to simulate on. Tets are hard to generate but once they are there, they are easier to use for an adaptive simulation. However, this duality should not be taken as a mutual exclusion. In fact, TRfem could support both with appropriate tooling.
That being said, an export option of a TRfem temperature field to a 3MF volumetric is an excellent idea! If 3MF (perhaps with some sort of “tet mesh extension”?) becomes the file format of choice for users of TRmesh/TRfem, I would be very happy with it!
From a business use case perspective:
In additive manufacturing, especially multi-material and functionally graded printing, I assume there’s a growing need for designs that encode internal behaviors, not just outer shapes.
Most current workflows only support surface-level geometry (via STL or basic 3MF), but the real value comes when you can define what’s happening inside the part: thermal gradients, stiffness variation, internal cooling channels, or embedded functionally graded materials.
TRfem and TRmesh, by working directly with volumetric scalar fields on tetrahedral meshes, can generate exactly the kind of high-resolution internal data that could guide such next-gen prints. If there’s a path to resampling those fields to 3MF-compatible voxel grids, even at lower resolution, you have a bridge from simulation to fabrication, where what you simulate is what you print, and not just in shape, but in function.
How does TRfem fit into the broader set of capabilities becoming available in Grasshopper 2?
In Grasshopper 2, a field is essentially a function that assigns a value (like temperature) to each point in space. Grasshopper 2 comes with a few great components for field manipulation, where a field can be thought of as a fairly general, or even black-box, function of x,y,z. If one has the derivatives (gradient and Hessian), then even better, but they are not required.
TRfem is a “match made in heaven” for those because a temperature field is, well, a field, in that exact sense, tautologically. In concrete terms, you can take a temperature field generated by TRfem and visualize it in GH2, apply David’s exquisite color gradients, and first and foremost, use it to guide the generation of other downstream geometry.
For example, temperature gradients can be used to thicken walls, open pores, or align structures to heat flow directions.
So the combination of TRfem with GH2 brings the best of four worlds: physical simulation with finite elements for accuracy, the world-class CAD modeling capabilities of Rhino, Grasshopper’s unmatched parametricism capabilities, and GH2’s field visualisation and manipulation components, all together on one platform.
Ideally, an entire topology optimization workflow can be done without leaving GH2 and without doing any file IO – and without having to wait for days for it to succeed, like when scripting topology optimization loops between Rhino and other huge desktop apps that use very different paradigms.
To summarize, TRfem fits into GH2 because the data structures match up naturally, and no extra plugins are needed for a full top opt workflow.
In particular, the “no file IO” point removes the friction and fragility of multi-tool workflows. This allows for rapid iteration and reduces failure modes in automation-heavy setups. This enables architects, engineers, and designers to simulate and shape geometry interactively, without ever leaving the Grasshopper canvas
For those familiar with Grasshopper 1, what would you highlight as the major changes or improvements in Grasshopper 2?
Apart from the fields concept mentioned above, GH2 features far superior performance due to its in-built parallelism, a very thoroughly thought-through and well-implemented concept of metadata generation and manipulation (think BIM), a large number of components for data analysis and statistics (just the histogram component on its own, to name just one example out of many), and thoroughly rethought display settings dialog for easy, clear, and beautiful visuals, plus a broad set of new components everywhere. In GH1, parallelism was only possible via plugins or scripting; now it’s built in.
Display settings in GH1 often required hacks or scripting for clarity. GH2 solves this natively.
Fluid shedding analysis is just a tiny part of those. And then the list goes on: a great documentation platform that is almost a bit of a literate programming environment in itself in the sense that example definitions can be tried out straight from the documentation itself. And a lot more!
Finally, what are you hoping to gain from participating in CDFAM Amsterdam, and what kinds of conversations or collaborations are you most interested in?
Aside from the obvious wish to gain new GH2 and TRmesh/TRfem users, I am looking forward to inspiring conversations in which I learn more about the day-to-day needs in additive manufacturing!
To learn more about how these tools are reshaping computational workflows—from volumetric simulation to real-time field-driven design—join us at CDFAM Amsterdam, July 9–10, 2025. You’ll have the chance to connect with Mathias and others who are building the next generation of design and engineering software, and see how these capabilities are being applied across architecture, manufacturing, and advanced geometry.