Archives Discussions

[dirus]

While writing a Design Doc for an MORPG game with FPS type combat I started thinking about the collision detection on the server side. Specifically tracking bullets.

I remember when I first started playing FPS' 32 players on a server was more or less the max, iirc largely due to the servers at that time not being able to handle the stress of more players without significant lag, due to the servers inability to keep up with every bullet flying around. I know Planetside had a 10k player max and the same goes for Battleground Europe. The bullet's also only flew so far before they just disappeared.

So I started wondering, since AMD is now really starting to push the GPU into a GpGPU would it be useful to try and harness the power of a GPU to do just collision detection. I know there is costs associated with the transfer of data across the PCIe bus and back, and in most cases that cost negates any benefit and can even make it worse. However I honestly don't have any serious expertise when it comes to coding anything for the GPU themselves.

Ultimately what I'd like is the ability to have the CPU send the vector/velocity info of all the moving objects such as bullets, players, vehicles etc to the GPU and have it run all the collision detection work, then if there is actually a collision the GPU would report that back to the CPU, which could then do any required calculations.

One of the main things that got me thinking about collision detection in the first place is that I think it would be awesome to have a mass battle with 1000 or so players where not only can you get hit by stray bullets(since most FPS' do that already) but also where the projectiles interact with each other. For example player 1 throws a knife at player 2, however while in flight a stray bullet from player 3's gun hits the knife and knocks it off course (I know this would be extremely compute intensive). Or the ability to shoot RPG's out of the air etc.

[Meteorhead]

You are right, that PCIe communication can significantly throw back performance, and in cases like the one you mention, where you only do a portion of the physics (namely coll. det.) on the GPU the overhead relative to amount of work increases.

Possible solution to your problem could be to compute all aspects of phyics on the GPU. Particle-like physics systems can all be paralellized by the number of objects, including collision detection. This way you can reduce all incoming transfer to avatar input and the output to new model coordinates. These hopefully can fit into PCIe buffers. Biggest problems arise during GPU physics destruction of the environment. Deforming existing objects, spawning new ones, and breaking existing ones (which is deforming and spawning). Implementing such capabilities into a gpu-accel game engine would be revolutionary.

Unfortunately crafting such an engine requires serious gpgpu expertise to know where one can cut-off memory bandwith efficiently and not waste shader capacity, specially if you're looking to make something better than usual MMO engines limited to some 32 players.

Most likely the best solution to your problem could be the new gen Llano processors. Quad-core processor with an extremely potent and programmable IGP. Best part of the APU setup (the one that causes the biggest problem in your case) is that PCIe communication is negated alltogether. Mapping and unmapping of objects between host-device will most likely be just pointer passing from IGP to CPU.

However if you can create an engine that runs well on a discrete graphics card, than game servers can upscale practically indefinately.