4 ms·

It depends on the game. Physics-heavy games for example, like Kerbal Space Program or Besiege, are usually CPU-limited.

revelation 10y ago
Those are both built with Unity though, right? Where the game is basically C#. Are the actual physics even done vectorized?
- sapphireblue 10y ago
  C# is just a glue language, physics is run inside the engine as optimized C++, it is vectorized where possible.
- martindevans 10y ago
  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-in-unity-5/ http://blogs.unity3d.com/2014/07/08/high-performance-physics...
- deleted 10y ago
  [deleted]
- dogma1138 10y ago
  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.
  - KON_Air 10y ago
    Your last paragraph ticks me off so much about the current non-sequetor "industry standard". Most recent example I can give is that doesn't really care is EDF 4.1. It takes carpet bombing an entire city to make its FPS dip with hundreds if not thousands of gaint incest gibs (and four players) being flung across the map. Do they really need a bazillion shaders and dynamic shadows on everything?
    - dogma1138 10y ago
      Unreal Engine is an industry standard when it comes to commercial general purpose engines. There are more unreal engine titles for any given version than any other engine on the market on PC's and consoles. On mobile unity is probably bigger atm.
  - Chattered 10y ago
    You sure? I was playing with Unity back in 2009 and you scripted both game and IDE atop mono. The .NET flavour of JS was being pushed, with code examples additionally in C# and Boo (!). I preferred to use F#.
- bitmapbrother 10y ago
  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++.
Fifer82 10y ago
shudder unity performance....
dogma1138 10y ago
Physics are pretty cheap unless your game is a physics simulator. CPU performance is important when there is a lot going on (most of the frame latency is CPU side), and when the CPU's are really busy dealing with other stuff like heavy AI or tons of NPC's you get poor frame rates and scalability with GPU processing power. Good examples of real CPU hogs would be the latest Civ games as well as games like Assassin's Creed Unity. ACU is especially a CPU killer, if your CPU OC is stable playing ACU it's really stable, I've seen that game cause CPU's that are not technically overclocked crash on their normal boost clock when the memory XPS profile was loaded.
- justinlardinois 10y ago
  > Physics are pretty cheap unless your game is a physics simulator. The two games your parent named basically are physics simulators.
  - dogma1138 10y ago
    I'm not saying they aren't :) It's just not every type of physics. Both of them are more or less indie titles also don't expect great optimizations from them. Minecraft is also CPU bottlenecked pretty much but that's because well the game was built with Java :)
    - outworlder 10y ago
      Even though the JVM probably gets in the way of the kind of low-level optimizations we are talking about here, Java is not the main factor for the CPU usage. All those voxels take up a good chunk (heh) of processing time. They are not all static, you know. Not sure how much of that could be shifted to the GPU.
derefr 10y ago
Why can't you do physics on the GPU, anyway? The integration step is matrix-multiplication, isn't it?
- Sanddancer 10y ago
  You can. Nvidia bought physx, who made dedicated physics accelerators, and integrated its api into gpus for just that reason.
- creshal 10y ago
  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.
- olaulaja 10y ago
  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)
- kxyvr 10y ago
  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.

Those are both built with Unity though, right? Where the game is basically C#. Are the actual physics even done vectorized?

sapphireblue 10y ago
C# is just a glue language, physics is run inside the engine as optimized C++, it is vectorized where possible.
martindevans 10y ago
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-in-unity-5/ http://blogs.unity3d.com/2014/07/08/high-performance-physics...
deleted 10y ago
[deleted]
dogma1138 10y ago
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.
- KON_Air 10y ago
  Your last paragraph ticks me off so much about the current non-sequetor "industry standard". Most recent example I can give is that doesn't really care is EDF 4.1. It takes carpet bombing an entire city to make its FPS dip with hundreds if not thousands of gaint incest gibs (and four players) being flung across the map. Do they really need a bazillion shaders and dynamic shadows on everything?
  - dogma1138 10y ago
    Unreal Engine is an industry standard when it comes to commercial general purpose engines. There are more unreal engine titles for any given version than any other engine on the market on PC's and consoles. On mobile unity is probably bigger atm.
- Chattered 10y ago
  You sure? I was playing with Unity back in 2009 and you scripted both game and IDE atop mono. The .NET flavour of JS was being pushed, with code examples additionally in C# and Boo (!). I preferred to use F#.
bitmapbrother 10y ago
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++.

Fifer82 10y ago

shudder unity performance....

dogma1138 10y ago

Physics are pretty cheap unless your game is a physics simulator. CPU performance is important when there is a lot going on (most of the frame latency is CPU side), and when the CPU's are really busy dealing with other stuff like heavy AI or tons of NPC's you get poor frame rates and scalability with GPU processing power. Good examples of real CPU hogs would be the latest Civ games as well as games like Assassin's Creed Unity. ACU is especially a CPU killer, if your CPU OC is stable playing ACU it's really stable, I've seen that game cause CPU's that are not technically overclocked crash on their normal boost clock when the memory XPS profile was loaded.

justinlardinois 10y ago
> Physics are pretty cheap unless your game is a physics simulator. The two games your parent named basically are physics simulators.
- dogma1138 10y ago
  I'm not saying they aren't :) It's just not every type of physics. Both of them are more or less indie titles also don't expect great optimizations from them. Minecraft is also CPU bottlenecked pretty much but that's because well the game was built with Java :)
  - outworlder 10y ago
    Even though the JVM probably gets in the way of the kind of low-level optimizations we are talking about here, Java is not the main factor for the CPU usage. All those voxels take up a good chunk (heh) of processing time. They are not all static, you know. Not sure how much of that could be shifted to the GPU.

derefr 10y ago

Why can't you do physics on the GPU, anyway? The integration step is matrix-multiplication, isn't it?

Sanddancer 10y ago
You can. Nvidia bought physx, who made dedicated physics accelerators, and integrated its api into gpus for just that reason.
creshal 10y ago
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.
olaulaja 10y ago
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)
kxyvr 10y ago
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.