Can physics on a GPU be made to actually impact gameplay?

[Plimogz]

From my gross understanding of how big, 3D games work, the CPU works out where and how everything in the engine interacts, and then sends the data off to the VGA for everything to get skinned in eye-candy.

I figure that the evolution of 3D adapters has been to off-load more and more of the actual processing of the visuals to the GPU; with the graphics cards more recently having gained the ability to add geometry or particles to the final scenes. But it seems to me that no GPU physics has yet been able to add to the gameplay beyond that extra eye-candy.

As an example, think back to the HL2 gravity gun -- That, to me, was a fun inclusion of game-world physics: Stuff reacted in a manner reasonably similar to real-world physics; it impacted gameplay in an interactive way. Suppose HL2 was given the Mafia 2 treatment, I could easily imagine there being oodles of non-interactive debris exploding from the spot on a wall where I'd shoot whatever was loaded into my gravity gun, but I'd still only be able to go pick up the one object I'd initially picked up and shot; the debris are there in appearance only; I can't actually go pick one of them up and shoot it out of the gravity gun. See what I mean?

Is it even feasible with current hardware (but better software) to have the GPU handle physics calculations and then feed those back into the game-world in a fashion which would control interactive objects in the game? Something beyond billows of smoke, splatters of goo, shattering of glass, waving of hair, etc?

Or are the interactive parts of game physics bound to remain under the purview of the CPU, with only purely cosmetic "physics" enhancements getting done on the GPU?

 

[KingFatty]

Are you describing PhysX?

I think the company Ageia had this idea and formed a company around it and developed physx which Nvidia bought?

 

[Annisman*]

Well, some games have expanded on the HL2 approach. Probably a poor example, but think about BFBC2 or BF3, it doesn't have Nvidia 'Physx' but the buildings and debris certainly affect game play in the multiplayer aspect.

I think there are advances in physics, they have just been slow, or not expanded on in certain engines and games. I'm guess we have been spoiled a bit and expect bigger leaps in that aspect of current game engines.

 

[badb0y]

Well, some games have expanded on the HL2 approach. Probably a poor example, but think about BFBC2 or BF3, it doesn't have Nvidia 'Physx' but the buildings and debris certainly affect game play in the multiplayer aspect.

I think there are advances in physics, they have just been slow, or not expanded on in certain engines and games. I'm guess we have been spoiled a bit and expect bigger leaps in that aspect of current game engines.

I'm pretty sure the destruction in BF3 is scripted.

 

[Annisman*]

I'm pretty sure the destruction in BF3 is scripted.

To some degree I am sure you are correct, but tell me, does it not still impact gameplay ?

 

[Midwayman]

I'm sure its possible. The issue is that if it affects gameplay you have to assume that everyone has it. Not a good assumption right now. However it'll be interesting with the new consoles since both will be GCN with open CL support, so maybe they'll start writing some games based on the assumption of gpu compute.

 

[Plimogz]

Well, some games have expanded on the HL2 approach. Probably a poor example, but think about BFBC2 or BF3, it doesn't have Nvidia 'Physx' but the buildings and debris certainly affect game play in the multiplayer aspect.

I think there are advances in physics, they have just been slow, or not expanded on in certain engines and games. I'm guess we have been spoiled a bit and expect bigger leaps in that aspect of current game engines.

For instance, when I play a voxel-based game, I get this feeling that everything in the world is up for grabs, so to speak. Of course, they always look extremely blocky, and the performance can often tank because of the extreme scope of what is possible in those engines. And I believe that I see a correlation as those games are usually very CPU-intensive while also being extremely light on the GPU.

I get that this is inherent to voxel-based games VS polygon-based ones. What I'm wondering is if this GPU-less interactive physics phenomenon is necessarily inherent to poly-based games (i.e. basically all big, AAA, 3D games) or if there is hope that something akin to the hardware we're rocking today could achieve very many interactive, physically realistic objects (presumably calculated on the GPU given how highly those get touted as being "great at physics simulation") but in an honestly game-changing fashion.

And I suppose that I can look at this Voxel VS Poly game statement the other way around and ask: Could GPU processing be used to accelerate the performance of a voxel game? Afterall, if the GPU is a parallel processing monster, aren't the thousands of blocks in a Minecraft mega-explosion akin to thousands of individual particles in a cloud of realistically billowing fog around Batman's feet? Or like the thousands of little cubes which I once saw bouncing around in a GPU-physics demo, for that matter. Is it possible that this sort of thing (which is obviously too much for the CPU to handle) get handed off to the GPU which then crunches it before returning it to the CPU, or something. In order that we might have not hundreds of dead, non-interactive pieces of eye-candy emanating from an RPG hitting a wall, but rather some actual pieces of realistic flying deadly rubble (or shrapnel )which then become part of the game world.

I realize that there's an obvious and inevitable performance issue with making stuff both physically realistic and destructible. But it just seems like whenever I see a GPU-physics demonstration, it's always just very pretty ephemeral fluff or some cosmetic enhancement, never anything persistent enough to impact actual gameplay.

 

[Pia]

I'm sure its possible. The issue is that if it affects gameplay you have to assume that everyone has it. Not a good assumption right now. However it'll be interesting with the new consoles since both will be GCN with open CL support, so maybe they'll start writing some games based on the assumption of gpu compute.

Yep, it has been a terrible business proposition for the PC. You have the expense and risk inherent in writing a GPU physics engine. Then you essentially limit your audience to the people with the newest, greatest GPUs. All the performance you drain from the GPU to do that comes out of how good your game can otherwise look. And you need to take that physics stuff and make it pay off so well that everything was worth it (game design problem).

 

[gorobei]

single player game: probably
multi player game: no

you could do it on discrete gpu but it might not be worth the effort. physics simulation can be done on cpu as well. the ghostbusters game that came out in 2009ish did all its sim on cpu.
http://www.youtube.com/watch?v=H9boF-JZKcU
this was done on vanilla intel quad core with no igp.

since most games only use 2 cores worth of cpu processing power, the spare cpu cores/cycles could easily be used for simulation. since most games are pushing gpus to their limit with high levels of AA and AF, pushing more load on the gpu is questionable.
once developers have enough potential customers with 4core cpus with intel eu or amd gcn parallel processing units on die, they will likely push the gameplay affecting physics simulation to the APU/CPU and maybe let the gpu handle trivial non gameplay affecting particles.

no multi player game will ever use client side gpu physics for non trivial gameplay simply because any dynamic object that affects gameplay will have to have its state updated on the server and pushed out to the rest of the connected clients. waiting for 1 client to take an action that has to be solved on his gpu and then uploaded to the server and sent out to all the other clients makes absolutely no sense. much simpler to run the physics sim on the server and sent the update state out in the server's global package update.