I've been reading about and experimenting with collision detection and physics, settled on Bullet, and have implemented simple box-based collision detection in my application, a script-driven game engine using Ogre3D for rendering. I'm not clear on a few things, however, and would appreciate clarification on a few things.
For one thing, I don't know how most games now handle collision detection for the player. In the past, when I did more game programming than engine programming, the wall-sliding, collision fixing, etc. were all done by the engine, not by a physics engine. Has that changed? Is using physics calculations for the player a good idea now?
If not, how much logic is required on the part of my engine? Many collision detection libraries only tell me "these two objects are inside each other, deal with it" and I would have to figure out what the most feasably accurate last good position was, etc. but Bullet seems to provide this for me with collision manifolds. Am I correct? If so, what do the points it gives mean? Do I average them to find a reasonable collision point, or should I do something else entirely with them? Do they represent vertices or something else?
The world is currently all dynamic objects (for simple tests), but I'll be implementing static meshes fed into an Octree soon for optimization. Since the meshes stay conceptually separate in the engine, am I supposed to feed the triangles from the meshes separately into Bullet, or is there a better way?
Thanks, and sorry for all the questions.
Starting out with Bullet and collision detection
-
- Posts: 1
- Joined: Tue Jul 22, 2008 4:31 pm