> Physics are pretty cheap unless your game is a physics simulator.

The two games your parent named basically are physics simulators.

C# is just a glue language, physics is run inside the engine as optimized C++, it is vectorized where possible.

Unity scripting is in C#, but the engine itself isn't necessarily written in C#. The physics are based on physx (which I assume vectorises things).

http://blogs.unity3d.com/2014/07/08/high-performance-physics...

No part of a Unity game runs in a .NET VM or any other VM. They chose C# as the scripting language because C# is one of the most popular programming languages, it's extremely popular in the non-game dev development community, and it's probably the only non-Web language that most code academies teach for traditional development maybe other than Java.

It's syntax is also pretty close to C and C++ which means developers with game dev background will feel at home as most game development is done in C++.

Unreal Engine uses Unreal Script which is now pretty much C++ but it is also not compiled directly (although with Unreal Engine 4 and onwards it's much closer to direct compile than any other scripting language).

Unity engine has it's own interpreter which then builds highly optimized C++ code and compiles it when you build the game.

Unity Engine is a pretty decent engine with kickass performance when optimized, without fine optimization any general purpose engine including Unreal 4 acts like utter crap. I'm alpha/beta testing a few UE4 games atm and you can see just how bad performance can get even on a solid defacto industry standard like UE4 like when dynamic shadows tank a GTX Titan X (Maxwell) SLI setup to below 20 fps any time there are light sources that are not properly fenced and culled - e.g. explosions.

I'm surprised by how many people think Unity games are "basically C#". That's like saying Unreal Engine games are coded in Lua. Like Lua, C# is nothing but the scripting language. The Unity game engine that does all of the heavy lifting is coded in C++.

You can. Nvidia bought physx, who made dedicated physics accelerators, and integrated its api into gpus for just that reason.

Occasionally you can, but it comes with caveats, even for PhysX:

• Only works on Windows

• Only works with Nvidia graphics cards (and only them, cheap nvidia card for physx + AMD card for graphics will disable PhysX)

• Not guaranteed to be faster for all cases, needs to be evaluated on a case-by-case basis

So even if the physics engine can, not all game engines use it. The Unity devs e.g. stated that they won't bother with it, as the limitations make it unattractive to pour effort into.

Collision detection and response are the hard parts and they are poorly suited for GPU implementation. Some specific cases (fluids, particles, maybe cloth) that don't require these in full work quite nicely and are used often enough (see common PhysX usage)

Sometimes, yes. Other times, no. If you're using an explicit integrator like a Runge–Kutta method such as RK4, then the answer is yes and the algorithms map pretty well onto a GPU. In that way, GPUs have been a huge boon to the scientific computing world. Though, personally, I find them a pain to program. However, if you use an implicit integrator like a backward Euler method, the answer is no because we need to solve a linear system. Yes, if we have a well defined problem it may be possible to design a custom preconditioner based on the physics of the problem that maps really well to a GPU. Those preconditioners take a huge amount of work to develop and, honestly, if you look at the last step of something like a multilevel method, it comes down to a direct factorization. Basically, direct dense and sparse factorizations do not currently map well to a GPU and these factorizations are extremely important to many scientific problems. Specifically, implicit time integrators depend on them to solve the linear systems involved and we need implicit integrators for stiff systems. Outside of integration, there are other situations where GPUs don't work well. In large scale optimization with equality constraints, there are linear systems that need to be solved and, most of the time, we need a direct factorization to solve these systems. That's why reduced spaced methods for things like parameter estimation are so popular. Basically, they're null space algorithms that eliminate the equality constraints by doing an implicit linear system solve using an explicit time integrator, which can map to something like a GPU. This leads to a host of other problems, but at least we can scale, sort of, sometimes.

At the end of the day, most scientific problems based on continuum mechanics need really fast level 1, 2, and 3 BLAS operations. That's mostly enough for simulating physics based on explicit time integrators. For elliptic problems or problems that require implicit time integrators, we need factorizations. Most of the time, we can get away with LU, Choleski, QR, and SVD. Both dense and sparse are required. For optimization with equality constraints, factorizations are also required.

By the way, if anyone wants to figure out how to do faster factorizations, dense and sparse, on whatever new hardware is coming out, that'd have an enormous impact on the scientific community. There are people working on it. There's not a lot of them.

You can. The problem is that there is a multi-frame (33ms * 2 or so) delay in getting any results back to the CPU. The GPU is set up for streaming, you compile command lists dynamically and feed it to it, this means it usually has at the very least 1 command list in execution and 1 being built on the CPU (the GPU is always kept busy, stalls are cycles going to waste). Hence the delay in getting results back.

And you will need some of those results on the CPU.

Physics for particles is not uncommon to be done on the GPU though. There is no feed-back to the CPU required so latency becomes a non-issue.