Camera collision avoidance algorithms

Started by
6 comments, last by Rompa 15 years, 9 months ago
Hi! At the moment I have implemented a third person camera that rotates around the player and tilts up and down. The camera follows player movement in and out, and always looks at the player much like in most third person games. :) My preliminary collision detection algorithm is less than optimal though on any kind of level that isn't perfect. I've noticed that in third person games the camera does also intersect in dodgy terrain but with effort :) The algorithm I use is doing a raycast from camera position to player and then offsetting a little from where the ray intersects the wall. If concave terrain half obstructs the camera, then the raycast will not detect this. Any pointers on useful articles (books or net) dealing with camera collision detection schemes for third person games? Current camera code, FindCorrectTransform() is doing the collision detection. Thank you.
Advertisement
Yeah, the camera is usually a volume, not just a ray.

Everything is better with Metal.

In my experience, the biggest factor in making a good 3rd person camera is level design. For tight situations you can use scripted cameras, like on a rail or inside an imaginary bubble, but usually it's best not to have a lot of action in small places like that. Just keep the camera in mind when deciding how to lay things out and where to put enemies, and try your best never to let the player die because there was no good place for the camera.

For the dynamic roaming camera collision, I think the Mario 64 approach works ok, where the camera moves upward if you jam it against a wall, to maintain constant distance from the player. But unlike Mario 64, I think you should be able to rotate it smoothly around left and right, not in steps, and without having it fight against being rotated into a wall (instead just go upward like if you jam it against the wall by walking).

And for the terrain thing, you could cast multiple rays to check more than just the direct path from the camera to the player. Then rotate the camera up/down/left/right depending on which ray hit the world.
Auto-rotating cameras can be very annoying though, so maybe if the player uses camera controls to adjust it, then disable the ray checks for a length of time, or until the player has walked a certain distance from where they manually adjusted it. Basically, always assume that the player understands the situation better than your camera system.
Quote:Original post by oliii
Yeah, the camera is usually a volume, not just a ray.


I know that using a volumetric system for collision detection is commonly used, but I couldn't find any info on what kind of algorithms to use for cameras anywhere. Thanks.
a simple swept sphere test should be good enough.

Everything is better with Metal.

ok. Is there any good equations for determining volume dimensions based on camera viewport? Or it just needs trial and error tuning? Thanks.
Trial and error. The radius should be at least greater than the near plane distance of course. I dont'know if it actually needs to be greater, I suppose theoretically a camera with a radius equal to the near plane distance would be sufficient, but in practise, I'm not sure.

In any case, I dont think it will matter much as long as it is sensible. I'd go with 30 cm radius, or something like that.

Everything is better with Metal.

I think the radius should be the square root of the distance from the camera position to the top-left or top-right corner of the near plane (or view window) plus a bit to allow small amounts of collision penetration without clipping geometry visually. I seem to recall using something like that a while back, and it sorta sounds right... right? :-)

This topic is closed to new replies.

Advertisement