Hacker News Reader

Comment by philipov | Hacker News Reader

These all look like physics engines for graphics rendering. They all say 2d or 3d, and that means they surely can't handle concepts like relativistic spacetime.

Do you know of any libraries for doing 'backend' physical simulations, such as calculating scattering amplitudes, making projections of spacetime models onto either space-like or time-like slices, and, especially, using tensor networks for modelling condensed matter interactions?

View on HN

Writing a general engine to do all these things is likely not a reasonable thing to do.

Complicated dynamical systems usually involve solving PDEs and for that you need to discretize your domain. How you choose to do so will drastically affect the numerical properties of your simulation. Most "real-physics" simulators tend to be specialized to a given task or even a given domain (for example simulating heat diffusion in an engine part). There's a whole literature on finite element methods to simulate various physical phenomena though it can be quite dense.

The generic game physics engines use very simple models of mechanics and allow for numerical issues (e.g. by using finite differences) in exchange for being real-time. If you're looking to simulate more advanced physical phenomena for a game, you're going to have to make similar trade-offs and will have to choose which ones make for the best gameplay.

Thank you, that all sounds right. I've been looking for, perhaps not a single engine, but rather specialized libraries I could glue together that handle different aspects of the problem. Sounds like I'll have to roll my own from scratch.

Can you recommend any general-purpose libraries (preferably with python bindings) for tensor calculus?

Take a look at SageManifolds: https://hyperspace.uni-frankfurt.de/2017/01/20/sagemanifolds...

My understanding is the numerical GR community is moving in this direction. The theory people tend to roll their own inside of Mathematica or Maple. Some Maple users use GRTensorIII (https://github.com/grtensor/grtensor)

Disclaimer: I am a co-creator of GRTensorIII

Thank you! This is exactly what I was looking for.

> The generic game physics engines use very simple models of mechanics and allow for numerical issues (e.g. by using finite differences)

Most modern game physics engines aren't actually discretizing an ODE or a PDE, at this point. The current standard techniques (see Nvidia's PhysX, for example) are instead solving something that look like a constraint satisfaction problem but gives force-like effects. You don't even get consistency under refinement with these methods, but they are cheap, and importantly, stable when terminated early (to remain under strict time budgets required of game based physics).

Interesting. So are these minimizing some constrained energy based on the physical properties and current state of whatever you're trying to simulate? If so, I don't quite understand how you avoid solving (or approximating) a PDE/ODE. My research is mostly in meshing and I'm not familiar with real-time simulation stuff. Do you have a link to a good paper on the topic?

Check out 'Position Based Dynamics' by Matthias Mueller, it was the first paper on the topic.

Most games aren’t using anything remotely near as sophisticated as that. Most games use rigid body simulations, and while the details of each implementation is different, most of them work in a similar way. The common method in open source engines is a projected gauss Seidel [0] which is used in bullet physics. Most other engines (PhysX and Havok) are to the best of my knowledge using something very similar.

[0] http://www.bulletphysics.com/ftp/pub/test/physics/papers/Ite...

> Most other engines (PhysX and Havok) are to the best of my knowledge using something very similar.

PhysX is position based dynamics. The Mueller guy who wrote that paper was a Co-founder of PhysX (back when it was NovodeX, then purchased by Ageia, then purchased by Nvidia) and is now a lead researcher at Nvidia. [1]

> The common method in open source engines is a projected gauss Seidel [0] which is used in bullet physics.

PGS is just the numerical method that Bullet uses to solve for the collision impulses between the rigid bodies (there are tons of other possible methods, Nvidia again had a cool paper a few years back, there are also global approaches with better convergence, etc). This is solving a so-called 'Contact Dynamics' contact model [2], which originates in the work of French mechanicians in the 70s and 80s.

Actually, if op is interested in PDEs in games, check out 'Digital Molecular Matter' [3]. It was used in some Star Wars games, iirc. It is a pretty straightforward Lagrangian discretization (linear shape functions on tets) of a linearized hyperelastic energy density. They added a simple fracture model on top which allowed for cool destruction effects in games.

[1] http://matthias-mueller-fischer.ch [2] https://en.wikipedia.org/wiki/Contact_dynamics [3] https://en.wikipedia.org/wiki/Digital_Molecular_Matter

Great answer!

This might be of interest for spacetime modeling: https://arxiv.org/abs/1712.07658

It isn't, mainly because it solves classical physics, i.e. Newtons equations. In contrast, your linked paper discusses numerical relativity, that's an approach to solve Einstein's general relativistic theory of gravity. While nowadays we do have a mathematically kind-of-similar formulation (an initial value formulation of a partial differential equation system which can be solved with similar techniques as classical mechanics -- so indeed with similar techniques as the "physics engines" refered here to), the bleeding edge research is at another scale. We use high performance computers to solve a large and complex system of equations (typically several MB of source code defining the system) in very large computational domains which take GB-PB of main memory on thousands of computers.

It may be worth saying that numerical relativity played a key part in the last Nobel prize for the detection of gravitational waves.

Nevertheless it's nice to refer to this analogy.

The closest thing I can think of is [Geant4](https://en.wikipedia.org/wiki/Geant4), which is a monte carlo-based particle simulator. It doesn't have facilities to work with geometric models of spacetime, of course, but it's used extensively in the high energy physics community and medical imaging communities.

There's Grid https://github.com/paboyle/grid , which is a general data-parallel code in development with the help of Intel. And there's the USQCD software stack http://usqcd-software.github.io/ which has communications and data-parallel layers (and then applications layers which you don't need unless you're doing lattice QCD). That stack tends to be annoying to compile and can be tricky to use---I'd look at Grid.

you should add pybullet as well.

Reply on news.ycombinator.com