Jitter GL Camera help

I am attempting to create a world in Jitter in which the camera is controlled by the keyboard like a video game. I was wondering if it is possible to constrain the camera view to a bounding box (much like a video game) rather than traveling through walls or separate models.

HI. That’s a fairly advanced question. I can’t help, and experience has been you may have to wait a while for a response when you’re pushing the frontier a little, but don’t be discouraged. And it may be some others are active on that, but it may not be very many people.

Jit.anim.drive has a @ui_listen mode that allows you to do keyboard/mouse driven navigation. Double-clicking the jit.anim.drive lets you edit the controls dictionary. Hook jit.anim.drive @ui_listen 1 to your jit.gl.camera and you have FPS camera.

one way to do this is to use two jit.anim.nodes. the first anim.node is controlled by a anim.drive (which receives key and mouse input), and is bound to your gl.camera. the second anim.node is parented to the first, and controls a kinematic rigid body (jit.phys.body @kinematic 1).

this will sync the camera with a rigid body, and cause other rigid bodies to "bounce" off the camera, as well as allow you to retrieve and process collision information from the phys.body.

if you don’t want objects to "bounce" off the camera, you can instead use a phys.ghost.

— Pasted Max Patch, click to expand. —

Copy all of the following text. Then, in Max, select New From Clipboard.

@Andrew : actually, it is not a fps camera, because the rotation is calculated on a mouse speed basis, as oppposed to a real fps where it is calculated on distance of current mouse location relatively to a fixed center location. So you can continually turn without haivng to constantly move the mouse, and you don’t have that effect where you spin 81225° all of a sudden because you gave a little hiccup to your mouse :p

here’s a slight variation of the previous patch that employs a different technique, and will keep a camera inside of the phys.world worldbox.
instead of controlling a kinematic body with an anim.drive, we instead control the @position2 attribute (world-space position) of a constraint, that in turn constrains the position of a dynamic rigid-body. we then sync the position of our camera to this rigid-body.

this technique requires some extra setup, but works quite well.
obviously there’s still lots of variation that can happen here, to tweak the movement.

— Pasted Max Patch, click to expand. —

Copy all of the following text. Then, in Max, select New From Clipboard.

Attachments:

I’ve been trying to follow the ideas here to create a modified patch where the object-tied-to-the-camera can be collided into and respond, throwing the camera amuck. Having a little trouble figuring out where to intervene. Any pointers would be appreciated.