Back to News
    Our Story/Field note 01

    Two Simulation Worlds, One Company: How QH Build Started

    QH Build began where two engineering disciplines met: high-fidelity multiphysics and controller-aware industrial robotics. Each side could solve problems the other could not.

    QH Build 4 min read

    QH Build did not begin with a generic idea to “do digital twins.” It began with two specific engineering frustrations.

    On one side was Mehdi Abdi, working for more than seven years on high-fidelity multiphysics: laser-material interaction, melt-pool flow, heat transfer, phase change, solidification and numerical methods capable of revealing phenomena that experiments could not easily measure.

    On the other side was Tomáš Jochman, working for more than seven years with industrial robotics and simulation: CAM toolpaths, virtual robot controllers, calibration, external axes, process communication, digital twins and the stubborn gap between a virtual trajectory and the part produced by a real machine.

    Both fields had advanced tools. Both fields also had a blind spot.

    The robotics tools did not understand the material

    Robotic CAM software could generate complex multi-axis paths, avoid collisions and test kinematic feasibility. A virtual robot controller could execute the robot code and reproduce interpolation or motion blending more faithfully than a simple path preview.

    But these tools usually treated the deposited material as geometry. They could not explain whether a laser-wire process would produce a stable bead, a discontinuity, a blob, excessive remelting or thermally induced distortion.

    A robot could execute a perfectly valid path and still create a poor part.

    The physics tools did not understand the robot

    High-fidelity multiphysics solvers could model heat transfer, melt-pool dynamics, evaporation, surface tension, solidification and residual stress. They could reproduce defect mechanisms at a level that a kinematic simulation could never reach.

    But they typically received idealized trajectories and simplified boundary conditions. They did not know how the industrial controller accelerated, blended a corner, coordinated an external positioner or delayed a deposition command.

    A physics model could be highly accurate and still simulate a motion the real robot would never execute.

    The missing product was the connection

    The two engineers recognized that industry did not need another isolated simulation package. It needed a digital thread that connected:

    • the intended CAD and CAM strategy;
    • the virtual and real robot controller;
    • the actual robot and external-axis motion;
    • process commands and sensor data;
    • fast geometric deposition prediction;
    • high-fidelity melt-pool and thermal simulation;
    • inspection data from the final part.

    This became the core idea behind QH Build: connect metal 3D-printing robots to a physics-based digital twin so manufacturers can optimize process parameters and reduce time, energy and material waste.

    One platform, two complementary models

    The first joint architecture separated the problem into two models with different responsibilities.

    The Kinematic and Dynamic Deposition Model (KDDM) is the fast robotics layer. It receives controller-aware motion, deposition start and stop signals, tool speed and process information. It predicts how acceleration, deceleration, blending and multi-axis coordination change the deposited geometry. It is designed for rapid iteration during planning and virtual commissioning.

    The Multiphysics Deposition Model (MPDM) is the high-fidelity physics layer. It resolves laser-material interaction, melt-pool dynamics, thermal history and solidification. It can be coupled to thermomechanical analysis for residual stress and distortion prediction.

    The two models are not competitors. They answer different questions.

    KDDM asks: What geometry will the controller and deposition timing create?

    MPDM asks: What will the material do under those motions and process parameters?

    Together, they provide a path from a fast feasibility check to a detailed prediction of process quality.

    Why NVIDIA Omniverse became the meeting place

    A unified digital twin requires more than solver code. Robots, tools, parts, sensors and simulation results need to exist in the same synchronized scene.

    QH Build uses NVIDIA Omniverse and OpenUSD as that shared environment. The platform provides a common scene description, GPU acceleration, interactive visualization and a practical way to connect robotics, physics and future machine-learning workflows.

    This choice also supports a modular product strategy. A robot connector can be changed without rewriting the physics. A new process head can be represented through a process adapter. A new solver can publish its results into the same scene. Sensor data can be spatially connected to the machine and the evolving part.

    Built from validation, not visual effects

    There is a risk in the digital-twin market: a visually impressive 3D scene can be mistaken for a predictive model.

    Our standard is different. A QH Build model must be compared with physical data. That may include robot logs, laser-tracker measurements, thermal data, load-cell signals, microscopy, 3D scans or destructive material tests.

    The purpose of the visualization is to make complex data usable. The purpose of the model is to make a defensible prediction.

    QH Build started because two simulation worlds were incomplete on their own. Our work is to make them useful together.

    QH Buildfoundersdigital twinsroboticsmultiphysics