Digital twins are becoming indispensable infrastructure for maintaining complex systems. The value proposition is obvious: to make actionable decisions about a physical system, you need a model that tracks how it actually changes over time. But the state of the art in physical simulation still struggles with numeric instability, clipping, general inaccuracy, and mesh holes. These aren't edge cases; they're fundamental correctness failures. If we're going to trust digital twins for anything beyond visualization, correctness has to come first.
Q: Can't we just do finite element analysis of the mesh and go back to playing Yahtzee?
Finite Element Analysis *is* a good start, but it is an incomplete solution. Current Finite Element Analysis uses those same flawed and hole-ridden meshes I mentioned earlier. Sure, if you can keep your point clouds up to date, but that is a big if that gets more difficult/expensive/inaccurate with *at least* O(n) time complexity. Not to mention this approach does not give you a direct avenue to answer the *What Ifs* that a correctness approach would. '
Q: Okay, so what does a correctness-first simulation actually look like?
Here is the thesis: a NURBS control point is a finite element is a PBM64 material observer. Same point. One entity, three roles, zero translation layers between them. A collection of these points is an object, which is a Material Point Method component. And the whole system only does work when a Signed Distance Field detects a collision, or when an object does not have near-infinite structural life.
That last part matters more than it sounds. Most simulation engines tick every frame whether or not anything meaningful is happening. That is not just wasteful, it is a correctness problem. Every tick accumulates floating point error. Every unnecessary integration step drifts your model further from physical reality. If a steel beam is sitting on a table and nothing is touching it, the correct answer is nothing happens. Not "nothing happens, plus some numeric drift per frame that we hope stays small enough to ignore."
The control loop architecture goes like this:
CPU dispatches all object information on initialization and then gets out of the way. GPU receives, places the object in the world, and waits. Actually waits. Not polling-at-1000Hz waits. When the SDF detects a collision or movement, a CPU interrupt fires for the event. MPM inertial reference frames are notified. Each finite element moves based on internal stresses derived from its PBM64 observation. That observation is 64 physical material properties per body: density, Young's modulus, Poisson's ratio, fracture toughness, thermal conductivity, Jiles-Atherton domain parameters, Steinmetz loss coefficients, viscoelastic storage moduli, all the way through temperature coefficients for stiffness and strength. 256 bytes, packed tight enough to live in GPU shared memory. 64 properties, 256 bytes, the full picture.
Here is where it gets interesting. Each finite element is a trivariate NURBS control point. When stresses deform the element, they distort the topology directly. No remeshing step. No separate deformation pass. The geometry and the physics are the same data structure. And when that deformation produces a singularity in the topology, that singularity is a fracture. The mesh tears, new distinct objects spawn with their own MPM inertial reference frames, and the GPU/CPU shared buffer gets written with post-mortem data so the CPU can handle the new-object event. After that, the SDF is recalculated for the new collision shapes, metadata is written to the buffer, and we ask: has this object changed less than 1% over our selected time window? An hour, a day, a year, depending on what you are modeling. If yes, the object goes to sleep. We assume near-infinite structural life below the activity threshold. If not, back to the top of the loop.
An object that is not changing does not need to be simulated, and simulating it anyway introduces error that should not exist. Sleeping is the physically correct answer.
More content coming soon...