Lights & Cameras
Contents
Introduction to Lights & Cameras in Massive
Massive supports animated lights and cameras. These can either be manually created or imported from a DCC such as Maya.
By default, Massive creates 4 lights and 4 cameras. The lights created are:
- key
- sky
- bounce
- ambi

You can adjust the shader/render properties to match your current renderer and control the light attributes such as direction, size and shadows etc.
Lights are not often used in production shots in the majority of cases, due to the fact that most crowd shots are not rendered directly from Massive. Rather simulations are rendered externally via rib or arnold files imported into other rendering packages such as Maya or Katana. As such this section on lights will not go into great detail
Cameras
Cameras in Massive can be used for two main purposes
- Used for direct rendering from Massive
- Identifying the FOV of shot cameras, to aid placement, performance and reduce wasted sim time
As with lights, most renders are performed externally from Massive, via proxies referenced in Maya or Katana etc
Camera Properties
When selecting a camera on the scene page, you are able to adjust it’s properties from the attribute panel at the bottom of the window.
You can change the name of the camera by editing the text field.
The action editor button opens up the Camera, Light and Terrain action editor tool, allowing you to edit/create animations for your camera
The Yellow frustum button will turn on a visual representation of the camera’s field of view. note: you must turn on camera visibility via the View -> Cameras menu item.
Transform
The transform tab allows you to manipulate and keyframe the position and orientation of your cameras
Once keyframed, you can use the Camera Action Editor to edit the animations and select the keyable attributes
rx, ry & rz sets the rotation of the camera (in world space)
tx, ty & tz sets the translation of the camera (in object space)
cx, cy & cz sets the translation of the camera (in world space)
Constrain
The constrain tab allows you to dynamically animate your camera based on agents, segments or ground planes.
To constrain a camera to an agent, first select the type of constraint, then shit left click the desired instanced agent, finally click set agent and the agent ID will appear in the agent text field.
Types of constrain:
- off – Camera isnt constrained
- look at – Camera rotates to keep specified agent in the centre of view
- agent – Camera is constrained to the agent axis
- segment – Camera is constrained to the agent’s selected segment
- pov – If an agent’s segment (i.e. head) has vision enabled, and vision is on, the camera is constrained to this segment
- follow ground plane – Camera is constrained to an agent but conforms to the ground plane (i.e. X & Z translations)
- follow 3d – Camera is contrained to an agent but can translate in all 3 axis (X, Y & Z)
Projection
The projection tab is where you set the properies of your camera’s view.
- fov x & y – dimensions of camera’s field of view.
- pixel aspect ratio – used to change the pixel aspect ratio of the camera in both the viewport and massive generated renders.
- filmback x & y – used to represent the physical size of the film or sensor of a camera.
- 35mm – preset for setting the camera’s filmback to a 35mm sensor
- zmin – near clipping plane
- zmax – far clipping plane
Animation
the Animation tab is where you can scrub the keyframes for your camera and load/save animation files (.act)
Background
the background tab allows you to specify a background plate for your camera.
The image can be a single frame or sequence of files. Note: file format is limited to either jpg or tif
Render
The Render tab is where you specify any camera specific render settings such as volume or lens shaders.
This is rarely used unless rendering is being performed directly from Massive.
Importing Cameras
Cameras can be imported via:
- File -> import maya ascii
- File -> import fbx (Massive prime only)
Note: Camera animation need contain per-frame keys. Sparse keyframes are not supported in Massive
Examples
lane.x
You can use this channel to find out where your agent is, laterally, across the current lane.
lane.x has a range of -1 (fully left) to +1 (fully right) with a value of 0 in the centre.
Left in lane | Centre in lane | Right in lane |
---|---|---|
![]() |
![]() |
![]() |
lane.y
You can use this channel to find out where your agent is, vertically, across the current lane.
lane.y has a range of -1 (bottom of lane) to +1 (top of lane) with a value of 0 in the centre.
Bottom of lane | Centre in lane | Top of lane |
---|---|---|
![]() |
![]() |
![]() |
lane.z
You can use this channel to find out where your agent is, along the current lane.
lane.z has a range of 0 (start of lane) to 1 (far end of lane) with a value of 0.5 in the centre.
Start of lane | Centre of lane | End of lane |
---|---|---|
![]() |
![]() |
![]() |
lane.ax vs lane.ox
lane.ax and lane.ox look very similar at first glance. They both calculate the angle of the lane which an agent is on. With 0 to -180 being a left turn and 0 to 180 being a right turn.
Both can be used to help an agent make turns. However, they calculate the turn differently if you are using look-ahead (see below for look-ahead details)
The main difference is:
lane.ox calculates the angle of turn based on the agent’s predicted orientation.
lane.ax calculates the angle of turn relative to the agent’s current orientation
lane.ax can generally give better turn results than lane.ox.
Below is an example of a right turn, lane.ax and lane.ox are used and setup identically. You can see from the final frame, that lane.ax better anticipates the turn amount needed and as such keeps the agent more centred in the lane, whereas lane.ox results in a wider turn and can even cause the agent to walk off the side of the lane completely
Start of turn | Mid turn | End of turn |
---|---|---|
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
lane.h
lane.h is very useful for when you have overlapping lanes and dont want to confuse your agent. You can assign a colour to your agent to follow the corresponding lane of that colour.
In the following example, a condition of 0.3 is fed into the lane.h fuzz node, and notice how the agent has ignored the red and blue lanes and kept walking along only the green lane.
