Chase camera system with constraints?

[arparso]

I'm looking to implement a chase camera system (where the camera follows another object, mostly behind it) and I'm wondering if it's feasible to do this using joints and constraints. The camera needs to be able to collide with other geometry, so it doesn't end up on the inside of walls or other objects. Modelling the camera as a physical entity like a sphere and attaching it via joints to the entity it's chasing seems to make sense to me in that regard, but I don't have much experience with BEPU or physics engines in general... I'm not sure if that's really a good idea. Is there a way to make the camera collide with other entities, but without effecting those entities in any way? E.g. it should simply slide across the surface of a colliding entity, but not push it around like if the camera were an actual physical entity with mass in the game world.

Same would apply for the joint: the chased object would be dragging the camera around, but shouldn't be slowed down by the added "weight" of the camera. Also if I manually move the camera, it shouldn't have any effect on the entity it's attached to - the joint would just be used to restrict the camera's movement, nothing more.

Is that a feasible solution and if it is, how would I configure the camera, the joint(s) or BEPU in general for this to work?

If that isn't going to work, how else would I check for collisions between the camera and any static geometry or dynamic/kinematic entities without having to roll my own collision detection system? Seems wasteful, if BEPU physics is already so good with that stuff.

[Norbo]

Is that a feasible solution and if it is, how would I configure the camera, the joint(s) or BEPU in general for this to work?

Since that approach is very nonphysical, the physical constraints would have to be hacked quite a bit to make it work. Even if the collision rules and masses could be tuned to get it close, there would still be awkward corner cases. For example, if the camera got behind a camera obstacle as the look at target moved away, the camera could get stuck with very few options (all of which are ugly).

If that isn't going to work, how else would I check for collisions between the camera and any static geometry or dynamic/kinematic entites without having to roll my own collision detection system? Seems wasteful, if BEPU physics is already so good with that stuff.

The usual approach is to perform a ray cast from the look at target location to the camera goal location. The camera is then placed a bit in front of the first hit, if any. A filter can be supplied to the ray cast to prune out unwanted candidates such as the look at target object itself as well as collidables associated with transparent geometry (if desired).

An example of this can be found in the BEPUphysicsDemos Camera class, in the main source download. The chase camera mode is used when the vehicle is activated (with the V key).

[arparso]

Ah, I see. I'll have a look at the sample and see what I can come up with for my little project. Thanks for the fast response and helpful advice