delete
With an oriented bounding box you can run into the problem of 'rotating into' an obstacle, but typically collision detection like you describe is done with axis-aligned bounding boxes, which don't have that problem.
Spheres are quite a bit easier for this purpose than AABBs, but if you want to adjust the height of your object for crouching, I suppose that won't work for you (although an axis-aligned ellipsoid might be an option).
I'm guessing your world isn't anything tidy like a BSP tree, but rather just a polygon soup? Detecting and processing collisions between an AABB and such an environment is a little complicated, but certainly doable.
Spheres are quite a bit easier for this purpose than AABBs, but if you want to adjust the height of your object for crouching, I suppose that won't work for you (although an axis-aligned ellipsoid might be an option).
I'm guessing your world isn't anything tidy like a BSP tree, but rather just a polygon soup? Detecting and processing collisions between an AABB and such an environment is a little complicated, but certainly doable.
loads of ways. Quake-based engines (quake, HL, quake2, quake3, ect..) use axis-aligned boxes.
Other use cylinders, or oriented boxes, or ellipses. Other use stacks of objects, nothing prevents you from using several spheres stacked on top of each other, for example.
here is an example.
Other use cylinders, or oriented boxes, or ellipses. Other use stacks of objects, nothing prevents you from using several spheres stacked on top of each other, for example.
here is an example.
If you haven't already, you might check out this article. I think it assumes oriented ellipsoids, but for the axis-aligned case (which I think would work well for your situation) it would be quite a bit simpler. Also, assuming your ellipsoid is symmetrical about the yaw axis, you wouldn't have any problems with rotating into obstacles. All in all, this can be a very good solution for character vs. poly soup collision.
As for what most games do, I don't know for sure, but I think pretty much any game based on the Quake engine or its derivatives uses AABB vs. BSP in some form or other. You can do AABB vs. poly soup, but it's a little more complicated than using ellipsoids.
As for what most games do, I don't know for sure, but I think pretty much any game based on the Quake engine or its derivatives uses AABB vs. BSP in some form or other. You can do AABB vs. poly soup, but it's a little more complicated than using ellipsoids.
I find that spheres work really well for the camera, because they glide smoothly across surfaces, rather than getting snagged on corners.
For the player itself, I find that a capsule (cylinder capped by spheres) works well; possibly with a ray sticking down for floor contacts/legs.
If you want code that can already efficiently collide against triangle meshes, try googling for "OPCODE". If you want a physics library and framework to go with that, try ODE.
For the player itself, I find that a capsule (cylinder capped by spheres) works well; possibly with a ray sticking down for floor contacts/legs.
If you want code that can already efficiently collide against triangle meshes, try googling for "OPCODE". If you want a physics library and framework to go with that, try ODE.
Quote:Original post by ledbyzoso
oliii: i couldnt get that source to compile, it gave me an exit error.
shoudld have an exe now. so you can see what I'm tal;king about :)
gluCylinder for collisions?
gluCylinder draws an approximation to a cylinder, using polygons.
The great thing about primitive shapes like cylinders is that they are easier to do tests for that great big heaps of polygons...
Paul Nettle (fluidstudios) did a very nice article on axis-aligned ellipsoid to mesh collision detection, including an example which allowed FPS style movement. I'll let you find the link yourself. The advantage of the ellipsoid is that it is much simpler than a cylinder, and is simpler than a capsule when axis-aligned, or when only testing against a mesh.
gluCylinder draws an approximation to a cylinder, using polygons.
The great thing about primitive shapes like cylinders is that they are easier to do tests for that great big heaps of polygons...
Paul Nettle (fluidstudios) did a very nice article on axis-aligned ellipsoid to mesh collision detection, including an example which allowed FPS style movement. I'll let you find the link yourself. The advantage of the ellipsoid is that it is much simpler than a cylinder, and is simpler than a capsule when axis-aligned, or when only testing against a mesh.
cylinders are nasty.
and no, gluCylinder, ect... have nothing to do with collisions.
flat sides won't matter. In fact, they will give you more trouble since they'll snag on things more easily than round shapes. for the best of both worlds, a capsule (like a cylinder with spherical ends).
for that, 3D object intersections.
but yeah, spheres / ellipses are easier still, especially doing a sweeping collision test.
[Edited by - oliii on August 15, 2005 11:59:50 AM]
and no, gluCylinder, ect... have nothing to do with collisions.
flat sides won't matter. In fact, they will give you more trouble since they'll snag on things more easily than round shapes. for the best of both worlds, a capsule (like a cylinder with spherical ends).
for that, 3D object intersections.
but yeah, spheres / ellipses are easier still, especially doing a sweeping collision test.
[Edited by - oliii on August 15, 2005 11:59:50 AM]
Take a look at the OpenGL 3DS Bounding Box collision example located at Apron. The downloadable demo with source is here. I've used this code plenty of times when just messing around and it works pretty good for it's simplicity.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
