Cameras

A camera object decides what your visitor sees and how they move around.

Control modes

Mode	The visitor…
none	cannot move the camera — you drive it yourself
orbit	drags to rotate around a target, scrolls to zoom
fly	flies freely with keys and mouse
firstPerson	looks around from where they stand, pointer captured
lock	pointer captured, but the camera keeps following its object

lock is the one you want for a character

firstPerson hands the camera itself to the pointer controls, which detaches it from its object — fine for a viewer walking around a model, useless for a character, because the camera stops following the body.

lock captures the pointer the same way but leaves the camera attached, delivering the mouse movement to your script instead. That is a first-person game.

Orbit settings

orbit is the default because it suits product viewers, and it has the most to tune:

Setting	Does
target	the point being orbited
enableRotate · enablePan · enableZoom	which gestures are allowed
minDistance · maxDistance	how close and how far the visitor may get
minPolarAngle · maxPolarAngle	how far they may swing above and below
enableDamping · dampingFactor	how much the motion glides after they let go
autoRotate · autoRotateSpeed	a slow idle spin

Limiting the polar angle is worth doing on almost every product viewer: it stops people orbiting underneath the floor and seeing the scene from below, which no amount of lighting makes look intentional.

Lens

fov is the field of view in degrees — 50 is a natural default, lower is more telephoto and flatter, higher is wider and more dramatic.

near and far bound what gets drawn. Objects closer than near or further than far are clipped away.

A huge far/near ratio causes z-fighting

Surfaces close together start flickering as the depth buffer runs out of precision. If you see that, raise near before you lower far — near has far more effect on precision.

Fly settings

fly mode moves with keys, and the keys are configurable — including following one of the project's named bindings instead of naming keys directly. Speed and a boost multiplier (held Shift by default) control how fast.

Extra views

An extra view renders a second pass from a camera, on top of the main one. This is how you build a minimap, a rear-view mirror or a security monitor.

Put it on an object that already has a camera, and pick where it goes:

Target	Renders into
screen	a rectangle of the canvas — position and size in fractions of the screen
texture	an offscreen image, which a material can then display

The texture target is the fun one: render a camera's view into a texture, put that texture on a screen object in your scene, and you have a working monitor showing another part of the world.

Extra views draw after the main pass, in the order you give them.

Every extra view is another full render of the scene

Two monitors mean the scene is drawn three times. They are worth it where they matter, and worth switching off where they do not.

Which camera is active

A scene renders through one camera at a time. A script can ask which one and switch it:

ctx.camera.entity();
ctx.camera.setActive(securityCam);
ctx.camera.pose();

The camera's transform is always the source of truth — write to it to move the camera. Note that in orbit and firstPerson the controls own the rotation, so a rotation you write will be overwritten; position is respected. See the ctx API.

And if game controls are driving a camera, that camera's own control mode is ignored — the rig would fight it every frame.

---

Next: Resources — models, images and sounds.