The Meshing Bottleneck.

Traditional FEM/CAE pipelines often spend major time on volumetric meshing & geometry repair: fragile, memory-heavy, hard to parallelize.

WoSX aims to make physics simulation more like rendering: embarrassingly parallel, localized & free of volume meshes.

On the GPU, WoSX reduces warp divergence in its Monte Carlo random-walk solvers using dynamic load balancing through a persistent-threads implementation.

PDEs and boundary conditions are written in Slang (https://shader-slang.org), natively supporting CUDA, Vulkan, and Direct3D.

Releasing Walk on Spheres Extensions (WoSX): a GPU-accelerated C++/Python library for Monte Carlo physics simulation on complex geometry

Think path tracing but for physics beyond light transport: heat, electrostatics, potential flow, deformation & more!

https://github.com/nv-tlabs/wosx

WoSX aims to be for MC physics what PBRT (https://www.pbrt.org) is for rendering: clear, inspectable, extensible software researchers & engineers can build on

It currently targets steady-state problems, not general multiphysics—but more features are under active development!

“Rendering” Physics.

WoSX uses Walk on Spheres-style random walks to solve Laplace, Poisson, and screened Poisson problems with Dirichlet, Neumann, and Robin boundary conditions.

Estimate physical fields only where needed, using boundary queries via BVHs or SDFs.

Interactive Electrostatics: Electric potential and field magnitude computed on-the-fly for a moving micro-electronic comb drive

Bypassing the volume-meshing step entirely allows for real-time feedback during geometric articulation

Exterior Potential Flow: idealized flow around arbitrary geometry, inspected locally on a slice plane

This is a setting where generating a volume mesh is not just inconvenient—the exterior domain has infinite extent

WoSX includes several engineering-inspired demo applications, with more on the way

View-dependent Thermal Analysis: Steady-state heat conduction on a Mars Rover. WoSX effortlessly handles the raw, unoptimized asset (millions of triangles), evaluating the field only where needed

@Colonthreee Checkout this tutorial for more details: https://rohan-sawhney.github.io/mcgp-resources/

The most significant difference is that all the methods you list rely on spatial discretization, i.e., they break up space into little pieces in order to form a finite set of linear equations. As a result, they must approximate the geometry, and the solution space.

@Colonthreee No different than on the CPU.

For any random walk, the next walk location is picked uniformly on the sphere. More advanced estimators do essentially the same.

The PDE solution can be evaluated at fixed or random sets of points in the domain -- depends on the application.

@muthutalks @nvidia @rohansawhney1 I give a talk that sketches all this out here: https://www.youtube.com/watch?v=bZbuKOxH71o

@muthutalks @nvidia @rohansawhney1 So for instance, just like it's common to use ray tracers to explore how lighting/illumination might look in a building, it becomes easy to ask questions about things like the thermal performance of a building—without converting the building model to a simulation-ready model.

@keenanisalive @nvidia @rohansawhney1 Physics runs on enough linearity to get benefits almost everywhere SIMDing Monte Carlo to start, but the idea of handling integral steps in the GPU itself, maybe on the same footing with ML kernelization, is also rly interesting

@muthutalks @nvidia @rohansawhney1 This is valuable because “what you see is what you get”: you don't have to worry that the meshing / gridding / discretization process changes the specification of your problem, or causes errors in the solution.

@muthutalks @nvidia @rohansawhney1 This difference can save you hours of setup time, which in turn makes it easier to explore different designs and solutions without having to wait a long time for each iteration.

@muthutalks @nvidia @rohansawhney1 Algorithmically, you also avoid extremely difficult sub-problems, like coming up with a high-quality volume mesh of the domain—and can instead just need closest point queries, which (like ray tracing) are way faster to implement.

@rohansawhney1 How is the sampling done on the GPU, and are those fixed amounts samples?

@muthutalks @nvidia @rohansawhney1 Monte Carlo walk on spheres avoids spatial discretization entirely, working directly with the original, unmodified description of the domain boundary.

E.g., if it's a smooth implicit or NURBs surface, you don't have to mesh the surface, or construct a volume mesh/grid.

@L8BL0oM3r Yes, the library at present handles only steady-state problems. But this isn’t a fundamental limitation on the scope of the Monte Carlo framework, and we’ll support broader classes of problems in the future :)