View Full Version : collision detection using shaders
04-02-2006, 05:12 PM
recently few researches in collision detection are addressed using GPU. Govindaraju is a major contributor in this area, but he uses NV_GL_OclussionQuery OpenGL extension for pruning non collide objects. But the NV_GL_OclussionQuery is a little limited, i would like to implement a shader with NV_GL_OclussionQuery functionality and more other functionalities, for instance, to obtain what objects and where are colliding. I would thank if you know any paper or web site talking about this subject.
04-14-2006, 12:12 AM
physics on the GPU would be interesting in the academic sense, though it seems like GPUs are generally too busy doing graphics to deal with collisions, at least in games. The PPU, like AGEIA's PhysX or something similar, would be great as a dedicated processor, but this seems to be catching on slowly (it's tough convincing people to layout yet another bundle for the latest thing). Plus it seems like the API itself would be strained and awkward in this context. I'd love to see something mainstream emerge in this area.
04-16-2006, 05:26 PM
physics on the GPU is not just an "academic thing" it's real, but according to the latest info from Nvidia it's not used on gameplay objects (players world geometry and such) but FX objects (particles, debris and such), and these are mostly cosmetic, but it is a good idea because a gpu is far more powerfull than the cpu (a 3ghz intel has about 6 Gflop and a GF6800 has around 80Gflop).
Regarding AGEIA's PhysX, yes it's a good idea, but what would be a better idea is to put it on the GFX card as an extra feature.
04-17-2006, 06:52 AM
There is no point in putting it on a GFX card. The two most important things required by physics calculations are branching and vector processing and modern day GPUs are inherently vector processors. Both ATI and nVidia have effectively demoed their GPUs being used as physics processors. I think nVidia has even teamed with havok to add support for physics calculations on their GPUs.
As for branching, they are catching up and will soon be very fast to be readily usable in graphics hardware. I think people need good game play rather than fancy physics or even graphics for that matter, but that's a separate discussion altogether :) .
04-17-2006, 09:25 AM
The only problem with physics on gameplay objects is that you actually need the data on the CPU for gameplay decisions, so if you put this on the GPU, you would actually have to upload the data, do the physics computation, download it again, modify the data to reflect game logic decisions, and then finally upload it again to draw it.
Of course, for pure "eye candy" physics where you directly draw the result without ever looking at the result data, that's a different story ;)
Also, the question comes to mind: What do you need a multi-core CPU for when it does nothing than transferring data from one specialised unit to the other?
04-17-2006, 11:35 AM
physics on the GPU is not just an "academic thing" it's real, but according to the latest info from Nvidia it's not used on gameplay objects (players world geometry and such) but FX objects (particles, debris and such), and these are mostly cosmetic, but it is a good idea because a gpu is far more powerfull than the cpu (a 3ghz intel has about 6 Gflop and a GF6800 has around 80Gflop).True, but Yalmar was referring to occlusion queries, so I can only assume he had "real" objects in mind -- though I'm not entirely certain how an occlusion query would do collsions (not really sure I want to).
Regarding AGEIA's PhysX, yes it's a good idea, but what would be a better idea is to put it on the GFX card as an extra feature.I don't see this happening. Although a console-on-a-stick might prove to be interesting, it'll take up too much space, generate too much heat and require too much power, and cost too much; and if you want to replace just the PPU, you have to replace the whole unit.
I'd like to see PCs get much more modular, like stereo systems, slide-in processors that can be chained together and the like.
04-17-2006, 11:38 AM
I think people need good game play rather than fancy physics or even graphics for that matter, but that's a separate discussion altogether :) .I couldn't agree more ;)
04-17-2006, 11:40 AM
Also, the question comes to mind: What do you need a multi-core CPU for when it does nothing than transferring data from one specialised unit to the other?I don't know about you, but I'd love to do some good AI for a change ;)
04-18-2006, 12:05 AM
Well you need Dual core CPUs because on a high quality scene the graphics card can (and does) become the bottleneck, and then you need the CPU for your physics, AI etc. So, if you have the option of doing physics on CPU or the GPU, you could dynamically shift your load depending on which hardware is becoming the bottleneck.
Btw, i have seen a couple of demos doing AI on the GPU, path finding, decision making etc.
Originally posted by yalmar:
...But the NV_GL_OclussionQuery is a little limited, i would like to implement a shader with NV_GL_OclussionQuery functionality and more other functionalities, for instance, to obtain what objects and where are colliding...Is this the "only" extra thing you need?
I would say this could be done, but I cannot tell when it's going to be good.
Check out uberflow, a GPU-accelerated particle system. They have some limited form of intra-particle collision checking. If I remember correctly, they used a unique ID for each particle. In your case, this could be the various colliders.
Unluckly, they didn't have enough processing power to perform a full-scale CD. There's also the problem that actual GPUs hardly allow any kind of evolved structure, often requiring a n^2 search.
Although it's probably out of topic, ATi also has a paper on rendering crowds which is playing with IDs. Also check for this, maybe it'll give you some extra idea.
I would say the communication latency is the problem here. PCIex greatly improved this (I've seen some apps going twice as fast), yet I think you need many thousands colliding objects to pay well. In this case, you'll have to avoid full-scale collisions. Solution seems to be not trivial, at least.
I would say that for non-major colliders (such as walls or floors for example) this could be feasible, especially when running the integrator at a fixed step. For major colliders, a delay of 1/40th of second is unacceptable.
I'm pretty interested in this.
Could you post the various papers you checked out?
I find it very funny: Havok claims dedicated physics processors are not necessary. But then they put their calculations on the GPU to speed things up.
Now the question comes to mind: What do i like better? To buy a 300$ PhysX processor, which i can plug into my existing PC, which i can use in my future PCs and which does not possibly interfere with the graphics, or do i want to buy an additional 600$ SLI graphics card, which is misused to accomplish the same task with reduced speed, only on FX objects (not all objects), which i need to re-buy, when i change my graphics card (again 600 bucks..) and which most certainly produces much more heat and noise than a dedicated processor.
I am not saying everybody should buy the PhysX processor, my point is just about the discussion if dedicated hardware makes sense or not. Some people say "oh, you won't convince people to buy yet another card only for physics", but well, in the end it's more like "you won't convince people to by (yet another) graphics card, if the PPU is cheaper and much better".
Just my 2 cent.
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.