Hi,
I'm using OPCODE for Linux 1.2.1. I created a simple example with OBB and failed to get the expected collisions. To check for errors, I duplicated the program using AABB and there it works. The OBB uses identity as transform while extents and center are identical. So in theory the OBB and the AABB should be identical. However, when collided with the same mesh, the AABB reports collisions that the OBB does not report.
The code can be found here: http://pastebin.com/f3f8589fd
Problem with OBB in OPCODE
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Problem with OBB in OPCODE
It might help if you contact Pierre Terdiman, his codercorner website has this email:
Why are you using OPCODE, and not Bullet collision detection
? The collision detection is a standalone library, and it doesn't depend or require the dynamics.
In case you use Bullet, we can help out with trimesh versus OBB, or other collision detection.
Thanks,
Erwin
Why are you using OPCODE, and not Bullet collision detection
? The collision detection is a standalone library, and it doesn't depend or require the dynamics.In case you use Bullet, we can help out with trimesh versus OBB, or other collision detection.
Thanks,
Erwin
-
jann.poppinga
- Posts: 12
- Joined: Wed Aug 26, 2009 3:32 pm
Re: Problem with OBB in OPCODE
I actually simplified my situation a bit: First I tried SOLID because it was small, recent and had the primitives I needed. But I couldn't get it to work. Since I didn't find a community site anywhere, I figured "why bother, there are so many to choose from" and turned to OPCODE. It was also small (not as scarily big as Bullet 
). But then I wanted to collide capsules with trimeshes. I started to write a work-around with OBB, but when even that didn't work, I wanted to switch again. But this time a wanted to make sure there's a community to support me with the problem I was bound to run into earlier or later. And since a colleague of mine had had bad experiences with ODE (and since it uses OPCODE for collision detection) and because OGRE looks even bigger than ODE and Bullet, I turned to Bullet.
Now I am quite happy with Bullet, I even recommended it to colleague (not the one from earlier) who just wants to do ray-casting. I only miss proper proximity queries and, if I may be a bit bold, non-convex polygons (with holes) as collision primitives. But right now I'm doing fine with triangulating them. Do you think there is much speed to be gained if I instead decomposed them into convex polygons? I am only casting spheres into a world consisting of a collection of the said planar triangulated non-convex polygons with holes.
There's one more issue but I'll post it separately
Thanks so far,
Jann
). But then I wanted to collide capsules with trimeshes. I started to write a work-around with OBB, but when even that didn't work, I wanted to switch again. But this time a wanted to make sure there's a community to support me with the problem I was bound to run into earlier or later. And since a colleague of mine had had bad experiences with ODE (and since it uses OPCODE for collision detection) and because OGRE looks even bigger than ODE and Bullet, I turned to Bullet.Now I am quite happy with Bullet, I even recommended it to colleague (not the one from earlier) who just wants to do ray-casting. I only miss proper proximity queries and, if I may be a bit bold, non-convex polygons (with holes) as collision primitives. But right now I'm doing fine with triangulating them. Do you think there is much speed to be gained if I instead decomposed them into convex polygons? I am only casting spheres into a world consisting of a collection of the said planar triangulated non-convex polygons with holes.
There's one more issue but I'll post it separately
Thanks so far,
Jann