COOLJAPAN
← All posts

OxiPhysics 0.1.2 Released — Real CSG Booleans, IMLS Surfaces, QM/MM, and Obstacle-Aware Motion Planning

OxiPhysics 0.1.2 — the unified pure-Rust physics engine (Bullet/OpenFOAM/LAMMPS/CalculiX replacement) replaces approximation stubs with real algorithms: winding-number CSG mesh booleans, IMLS Poisson surface reconstruction, a hybrid QM/MM module (PM3, SCC-DFTB, HF, B3LYP), obstacle-aware RRT/PRM planning, and a real BGK Lattice-Boltzmann step. 16 new correctness tests; 100% C/Fortran-free by default.

release oxiphysics physics-engine qm-mm molecular-dynamics motion-planning lattice-boltzmann csg pure-rust

The pure-Rust physics engine swaps its remaining approximations for real algorithms — CSG that actually classifies inside from outside, surface reconstruction that fits an implicit, motion planning that respects obstacles, and a hybrid quantum/classical molecular engine.

Today we released OxiPhysics 0.1.2 — a correctness-and-capability release for the unified, pure-Rust physics engine targeting Bullet (rigid body), OpenFOAM (CFD), LAMMPS (molecular dynamics), and CalculiX (FEM). Where 0.1.0 and 0.1.1 had a few methods standing in with approximations, 0.1.2 replaces them with the real thing — and adds a hybrid quantum-mechanics / molecular-mechanics module on top.

No C. No C++. No Fortran. The engine remains 100% C/Fortran-free in default features, compiles to a single static binary or to wasm32, and installs with one cargo add. What changed is the honesty and depth of the math behind several APIs.

Why 0.1.2 is a meaningful release

A physics engine is only as trustworthy as its weakest method. If union on two meshes is secretly an AABB approximation, or a motion planner’s collision check always returns “clear,” then the API lies — it compiles and returns a plausible value that isn’t physically right. 0.1.2 hunts those down and replaces them with real implementations, each backed by a new correctness test.

All of it stays honest: zero todo!()/unimplemented!() stubs, with 16 new unit and integration tests added specifically to assert the real behavior of these fixes.

Technical Deep Dive: the new QM/MM engine and the correctness work

  1. qm_mm — quantum mechanics / molecular mechanics (oxiphysics-md) The headline new module couples a quantum region to a classical force-field region. The QM region is selectable via QmMethod: PM3 (semi-empirical NDDO), SCC-DFTB (density-functional tight-binding), HF (Hartree-Fock / STO-3G), and B3LYP (Kohn-Sham LDA/VWN). The MM region uses force-field point charges, with mechanical or electrostatic embedding and hydrogen link-atom capping at the boundary. Each engine runs a real SCF loop with a Löwdin-orthogonalised generalised eigensolver, and provides numerical Hellmann-Feynman forces — so QM/MM here is a working solver, not a label.

  2. Geometry & reconstruction (oxiphysics-geometry, oxiphysics-python) The mesh-boolean path is the real winding-number classifier with mesh cleanup, and IMLS reconstruction goes PCA normals → Gaussian tangent-plane implicit → Marching Cubes via the geometry crate’s MarchingCubes. These were the two places the Python surface most needed to stop approximating, and now they don’t.

  3. CFD & planning (oxiphysics-lbm, oxiphysics-rigid) LbmGrid3D::step is a real BGK collide-and-stream with mass conservation verified by test, and MotionPlanning now does true C-space obstacle avoidance for RRT/PRM, including segment checks that stop sampling-based planners from tunnelling through obstacles between waypoints.

  4. Workspace structure (splitrs refactor) Several oversized modules (>2000 LoC) — oxiphysics-core types/pde/linalg, oxiphysics-geometry bspline, oxiphysics-rigid kinematics/mechanism_rigid, oxiphysics-lbm mixing_lbm, oxiphysics-md quantum_chemistry, oxiphysics-viz multiphysics_viz — were split into focused types/functions submodules with splitrs, and redundant #[allow(...)] Clippy attributes were removed across the workspace. Public APIs are unchanged: this is purely a maintainability refactor.

The workspace guarantees hold: pure Rust by default, single-binary deployment, WASM bindings, and zero C/Fortran in default features.

Getting Started

cargo add oxiphysics

The umbrella crate re-exports every domain module, so the core API is unchanged from 0.1.0/0.1.1:

use oxiphysics::core::math::Vec3;
use oxiphysics::core::Transform;

// Build a transform at a given position
let origin = Transform::default();
let offset = Vec3::new(1.0, 2.0, 3.0);

// Transform a point from local space into world space
let world_pt = origin.transform_point(&offset);
println!("world: {:?}", world_pt);

To advance a 3D Lattice-Boltzmann fluid one BGK step, build an LbmGrid3D and call the new real step(omega), then read the updated macroscopic fields via compute_macroscopic() — periodic streaming and collision now happen for real, not as a placeholder.

What’s New in 0.1.2

Tips

This is the foundation

OxiPhysics is the simulation layer of the broader COOLJAPAN pure-Rust ecosystem, and 0.1.2 keeps building on its siblings — solver paths lean on SciRS2 (scientific-computing primitives, via scirs2-integrate), OxiFFT (pure-Rust spectral transforms), and OxiARC (pure-Rust compression, via oxiarc-zstd) rather than any native C/C++ stack. With this release, more of the engine’s surface is backed by real algorithms end to end — sovereign, memory-safe, and honest by default.

Repository: https://github.com/cool-japan/oxiphysics

Star the repo if you want a physics engine whose methods compute the real answer — from CSG booleans to QM/MM — with no C toolchain in the default build.

Pure Rust physics is here — fast, safe, and sovereign.

KitaSan at COOLJAPAN OÜ June 6, 2026

↑ Back to all posts