I know it's been asked before, but the previous threads didn't really satisfy me. In an FPS, I know you can use ray intersection to detect whether or not you've hit an enemy when you fire. Just check for an intersection with a ray and any visible enemies' bounding boxes, and so on. Is THIS the easiest way to do it? It seems like there should be an easier way. Maybe not with true 3D. Anyone?

I dunno about easier but you can always just put a good old fashioned bullet into the world with a velocity. Then just do normal collision detection with that bullet. What it hits, it hits.

-me

What seems difficult to you about this method?

Quote:Just check for an intersection with a ray and any visible enemies' bounding boxes...

Checking a ray against a bounding box is one of the fastest intersection tests there is.

http://www.siggraph.org/education/materials/HyperGraph/raytrace/rtinter3.htm

It doesn't seem difficult, I just wondered if there were other methods.

If you are using openGL, you could use object picking to see if the bullet intersects an object.

http://www.lighthouse3d.com/opengl/picking/

Quote:Original post by Palidine
I dunno about easier but you can always just put a good old fashioned bullet into the world with a velocity. Then just do normal collision detection with that bullet. What it hits, it hits.

-me

that generally isn't a good idea with small, fast moving projectiles like bullets. Lets say that you have a bullet which is 1 pixel away from a window (with a thickness of 10 pixles) in one frame, and you're using a pixel-perfect collision detection algorithm, ie, your bullet does not collide with the window. the next frame, you displace the bullet using its velocity (maybe 100 m/s / 60 fps = 1.67 m/frame), which ends up displacing the bullet by, say, 40 pixels. the bullet is now on the other side of the window, but when you run your collision detection, it will not detect that the bullet is colliding with anything, because it isn't currently. thus, your bullet passed through an object without every registering a collision, which is bad. its much easier to just have a ray representing the bullets path that frame, and test if it collides with anything, which is, to answer the original question, very fast.

Quote:Original post by jdaniel
If you are using openGL, you could use object picking to see if the bullet intersects an object.

Isn't that really slow since it requires essentially a second rendering pass for the picking?

plus it only tells you which object it hit, not necessarially where the point of contact was, so if you want to have your object rebound....

Quote:Original post by Anonymous Poster

Quote:Original post by jdaniel
If you are using openGL, you could use object picking to see if the bullet intersects an object.

Isn't that really slow since it requires essentially a second rendering pass for the picking?

plus it only tells you which object it hit, not necessarially where the point of contact was, so if you want to have your object rebound....

Yeah, it's slow. It's not really true 3D either. And it is relatively easy to use. It seems to address the OP's question.

Treating bullets as objects isn't a good idea, for several reasons. First, each bullet would have to be handled by the game logic or physics system as a bullet is a primary object. Imagine the extreme case where you have a chaingun firing 6,000 rounds per minute. That's 100 extra objects a second that the engine would have to handle, which would bring your engine to a crawl just processing something as insignificant as bullet objects. Consider that bullets persist over several frames, meaning that it's a cumulative increase of 100 objects a frame over however many frames the bullets are alive. I won't even get into the multiplayer case. Also consider that in any reasonable engine you'd have to allocate the bullet object just so that it can exist, so not only are you wasting memory for bullets but frequent allocation and deallocation of small blocks of memory are a bad idea in general for any type of memory manager or allocation scheme. Even if the memory is preallocated from the OS, it still needs to be managed, and that's overhead you don't want each frame.

Rays are a much better alternative. There's constant memory overhead and the processing time is proportional to a weapon's firing rate, which dictates how many rays you fire per frame as the player is shooting. And most weapons don't fire insanely fast. Not only that, but collision detection is perfect. You can't "pass through" an object like you can with just checking for object-object collision. As a matter of fact, you'd probably end up performing ray-based intersection each frame with an object-object collision scheme just so you don't pass through objects! The only downside with a ray-based approach is that bullets need to hit their target instantaneously (no delay), or else the persistence of the bullet state requires engine resources akin to making bullets primary objects in the engine. That's why most games use rays for bullets, because it's cheaper and almost as good as a real projectile bullet.