Posted this already on gpgpu.org
http://www.gpgpu.org/forums/viewtopic.php?t=1877
In a nutshell, there are optimizations for complex shapes, by porting BVH to the GPU, and Cullide. However I haven't seen basic convex collision detection on GPU. Signed Distance Maps on GPU, or other solutions?
Anyone?
Erwin
ps: please reply either on this forum or gpgpu.org, I will extract the useful data and copy here anyway.
Convex Collision Detection for Rigid Body Physics on GPU?
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
-
- Posts: 27
- Joined: Thu Aug 25, 2005 5:05 am
- Location: IDAV, UC Davis
Re: Convex Collision Detection for Rigid Body Physics on GPU
Perhaps Christer Ericson has some knowledge on the subject for us (you know, since he's on this forum)...Erwin Coumans wrote:In a nutshell, there are optimizations for complex shapes, by porting BVH to the GPU, and Cullide. However I haven't seen basic convex collision detection on GPU. Signed Distance Maps on GPU, or other solutions?
The table of contents of his book, "Real-Time Collision Detection", lists chapter 10 as:
10 GPU-Assisted Collision Detection
10.1 Interfacing with the GPU 10.1.1 Buffer Readbacks 10.1.2 Occlusion Queries 10.2 Testing Convex Objects 10.3 Testing Concave Objects 10.4 GPU-Based Collision Filtering 10.5 Summary
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Convex Collision Detection for Rigid Body Physics on GPU
Thanks for mentioning the book and chapter. I just read it, but it is not what I need. It describes a screenspace method, that just gives a boolean result.dcoming wrote:Perhaps Christer Ericson has some knowledge on the subject for us (you know, since he's on this forum)...Erwin Coumans wrote:In a nutshell, there are optimizations for complex shapes, by porting BVH to the GPU, and Cullide. However I haven't seen basic convex collision detection on GPU. Signed Distance Maps on GPU, or other solutions?
The table of contents of his book, "Real-Time Collision Detection", lists chapter 10 as:
10 GPU-Assisted Collision Detection
10.1 Interfacing with the GPU 10.1.1 Buffer Readbacks 10.1.2 Occlusion Queries 10.2 Testing Convex Objects 10.3 Testing Concave Objects 10.4 GPU-Based Collision Filtering 10.5 Summary
I am looking for methods using GPU shader calculations that gives contact details, point, normal and distance/depth between 2 convex objects. Either the deepest contact, a couple of good contacts or all contacts. Essentially enough to build contact constraints.
-
- Posts: 23
- Joined: Mon Jun 27, 2005 4:30 pm
- Location: Los Angeles
Re: Convex Collision Detection for Rigid Body Physics on GPU
I'm incredibly sceptical about the whole GPGPU thing in general. We (our team) are certainly not looking at doing any type of non-graphics computations on the GPU for our next generation games. We figure that there's so many computation-heavy graphics effects that we'll be using all GPU cycles for graphics alone (leaving no spare cycles for non-graphics stuff). It may be that I'm somewhat biased by having to target the PS3 only, where you have ample computing power on the SPUs for things such as collision detection, but I seriously doubt that you'll see people doing much non-graphics GPU computations (if at all) in the next generation.
Of course, I could be all wrong about the usefulness of GPGPU, which is part of why I included the GPU chapter in my book. I also included it for completeness and to point out some flaws in some early (and current) GPU-based collision work (namely sampling issues that cause collisions to go undetected). Because it's still too early to tell where GPGPU is headed I limited my coverage to the very basic stuff (thus the rather short chapter).
Of course, I could be all wrong about the usefulness of GPGPU, which is part of why I included the GPU chapter in my book. I also included it for completeness and to point out some flaws in some early (and current) GPU-based collision work (namely sampling issues that cause collisions to go undetected). Because it's still too early to tell where GPGPU is headed I limited my coverage to the very basic stuff (thus the rather short chapter).