Modelling an "Elastic Camera" with Joints/Constraints

[mieko]

I've decided to stop trying to be clever and fake this type of movement outside of the game physics, and try to let Chipmunk handle it. I'm looking for a little guidance doing this the most straight-forward way.

The idea is: a camera that lags behind the player when the player is accelerating. In the following (debug-mode) screenshot, the player is the large white box, and is followed (slightly south-west of center) by the camera, trying to keep up (camera is collision free, of course).


(Sorry for the blur, don't want to stretch the page.)

Conceptually, the camera[0,0] is tied to the player[0,0] with a rubber-band. I've modeled this in Chipmunk by joining the two bodies via a cpDampedSpring (for the elasticity, seeking player center) and, to constrain the maximum distance, a cpGrooveJoint (groove runs fully across the player's width horizontally).

The player is represented in Chipmunk as a circle, and the body has a MOI and friction that allows the body to rotate. I'd prefer to keep this quality. Everything works brilliantly in the air, and during jumps and falls, but as the player rolls flat along the terrain, the player's rotation (around 0,0) is transferred through the joints, and causes the camera to start orbiting the player as he moves. This makes sense considering the GrooveJoint won't always be attached to the player at 0,0.

I guess I need to find a way to fake perfect, friction-free ball-bearings at both ends of the joints. I've been thinking a Gear might play into that somehow, or perhaps I'm not visualizing what SlideJoints can do fully, but I wanted an outside opinion on how this whole idea can be approached before I get too deep into it.

Thanks.

[slembcke]

You should attach both joints' anchor points to cpvzero. That way the rotation of either body cannot affect the joint.

or

When I want a similar camera behavior, I just do a simple clamped lerp. Something like this.

Code: Select all

cameraPos = cpvlerp(cameraPos, targetPos, alpha);
cameraPos = cpvlerpconst(targetPos, cameraPos, maxDist);

'alpha' is the per frame percentage you want to move towards the targetPos. alpha = 0 means no camera movement, alpha = 1 means the camera is locked to the targetPos. If you are using a variable sized timestep, you can calculate alpha = pow(1.0 - alphaRate, dt), where alphaRate is like alpha, but per second instead of per frame, and dt is the time since the last frame.

Although for platformer games you usually want the opposite camera behavior. You want it to move out in front of the player to let them see more of what's ahead:

Code: Select all

cpVect delta = cpvsub(cameraPos, targetPos);
cpVect targetDelta = cpvmult(targetVelocity, velocityCoef);
cameraPos = cpvadd(targetPos, cpvlerp(delta, targetDelta, alpha));
cameraPos = cpvlerpconst(targetPos, cameraPos, maxDist);

'velocityCoef' controls how much to exaggerate the overshooting effect.

[mieko]

Thanks Scott. I've fallen back to interpolating the camera position similar to your examples. But while it's on my mind, regarding cpvzero, please correct the error in my logic:

1. For two bodies joined with a fixed-length constraint, setting both points of attachment to cpvzero prevent the rotation of one effecting the other. This makes sense.
2. To get any travel out of a DampedSpring, but also temper the max distance with an additional constraint, I'd be restricted to using one of the other joints with "play", (e.g., cpGrooveJoint, cpSlideJoint). Otherwise the DampedSpring would just be extended to to the length of a normal, fixed-length joint.
3. During the simulation, as a GrooveJoint is actually traveled from cpvzero, toward the radius of the body, at that moment it's attached at that non-cpvzero point for the purposes of rotation

What I thought I was seeing was C, (the attachment point hitting an extent of the groove, then the GrooveJoint rotating with the body), but it could very well be the particulars of my setup. If I'm totally off here, let me know.

I still think camera-on-a-body is a cool idea, but I realized I'd be headed down the long road of subverting the engine to get all my bases covered. For the camera to seem real, it'd have to have a non-trivial mass, and that'd act upon the player via the spring, which would have to be compensated for, and so on. I'd probably papercut myself to death getting all the edge cases.

I do miss the shock-absorber effect after a collision, so I'll probably revisit this at some point.

Thanks again.

[slembcke]

Oh, I misread your original post. The problem is that you were using a groove joint then. The groove rotates with the body, so it would be pushing the camera around, causing it to orbit. You would want to use a slide joint instead if you want to try this idea again.

A fairly mathematically involved option is to use a critically damped spring equation. Taking the velocity of the camera into consideration instead of just it's position. This produces a very nice camera movement, but is a bit more complicated.

[mieko]

Thanks a lot for pointing me in the right direction, I was under the impression a slide joint would have the same effect. I'll give it a shot when I get back around to the camera code.