Latest revision as of 11:12, 28 October 2021

The camera described here is a map object set anywhere on the layout that will activate (change your view of the scene to what the camera sees) when a train that has focus comes within the camera view.

[edit] Placing a Camera

Putting a Session in Lineside view (press 3 to activate this view mode) will activate any camera along a route as it is encountered, but will default to Chase Mode in the absence of a camera encounter. This behavior suggests several ways that cameras can be used to enhance Driver mode. A camera can be placed strategically to view loading/unloading/coupling operations, the driver accessing the camera from the menu at the time needed. Setting up a continuous sequence of cameras can provide a driver with the option of switching to Lineside view as an alternative perspective on his train in motion, whereas starting a Session in Lineside view will automatically trigger a camera's view as the train comes into view. A continuous sequence of overlapping camera view fields provides a means of choreographing a rail-fan's view of train operations for "ride-along" sessions.

Cameras are placed and adjusted from the Tools menu in edit mode. Three tools are available: "Place camera 'A'", "Move camera 'M'", and "Delete camera 'D'". A camera can be placed when editing either a Route or a Session. A camera placed in a Session will only activate in that Session; a camera placed on a Route will be present in all sessions attached to that route. To place a camera, move your viewpoint to the approximate location where you wish it to be, click on Place camera "A", move your pointer to the exact location on the ground and click LMB. The camera view will appear with the view area marked by four corner angle lines, and a flashing green light in the lower left indicating the camera has been created and set in 3D space—you are now in Move camera "M" mode. Use the pointer and RMB to better fix the spot for the camera.

Adjusting the actual view to just what is desired is accomplished with the arrow, PgUp, and PgDn keys on the numeric keyboard, allowing you to pan left or right (camera azimuth), up or down (camera zenith or tilt), or move forward (PgUp or zoom in key) or backward (PgDn or zoom out key). Actually, two options exist for making these adjustments by selecting either "Roaming" or "Walk" modes from the list of camera views. Walk places the camera on the ground and then affects a straight-forward "walk" backwards and forwards, right or left (using the arrow keys) without changing the camera's azimuth or tilt. Azimuth and tilt are accomplished with these same arrow keys in Roaming mode. PgUp and PgDn only work in Roaming mode and can be used in conjunction with the RMB to make larger adjustments in camera location.

The camera location and mode are fixed by clicking on Place camera "A" a second time. Use the PgDn to back off and see the camera (if nothing happens you are in 'Walk' mode). Not satisfied? Click the pointer on the camera body and click Delete camera to remove the camera, allowing you to start over in a more desirable position using your pointer. Or, the Move camera tool can be used to adjust the camera view and position. Find the camera, select Move Camera "M", and LMB click on the camera body to bring up the camera's view, although in 'roaming' mode, this may change the camera's previously set position. Now the camera can be adjusted as described and the adjustments saved by LMB on Place camera "A". Again, backing off to view the camera is a check on your not having created accidentally a second camera.

The camera itself has a distinctive icon (a camera body and a hood indicating the direction the camera is pointing) and has two settings or camera types: Static and Tracking. Get in the habit of selecting static or tracking before fixing the location of the camera. This property can be changed by deleting and starting over or by making sure you move the camera some small amount after changing the type.

[edit] Static Camera

The Static and Tracking cameras have different icons and different behaviors. The Static camera view has a fixed view frame: an arc of about 65°; the camera has a red hood; and the camera is activated as a train enters the view area AND is within 200 meters (650 feet) of the camera. The Static camera view is triggered on by the forward end of the consist and triggered off as the end of the consist leaves the camera view or the middle of the train reaches 200 m distant from the camera. Because the Static camera has a fixed view frame, the points of activation (turn-on) and deactivation (turn-off) are a function of distance between the camera and the active track: a camera set close to the track will 'see' a shorter segment of track than a camera set farther back. However, a Static camera will watch the entire consist as it passes by. A Static camera pointing down the track will be subject to the distance rule in that direction instead of the start or end of the train.

Note that for a Static camera, the location of the consist within the frame of the camera view determines whether the camera turns on or not; and distance to the active track establishes how long the camera remains on. Setting up a camera in Roaming mode determines the activation frame. The camera tilt (up/down arrows) can only be set in Roaming mode. Walk mode is useful for making fine adjustments in location, but Roaming mode is necessary to set the frame that establishes when the camera will activate and deactivate (turn on and off). The borders of the frame determine when a view is acquired from another camera and when the view is passed to the next camera in sequence. For further discussion on handing off the camera view to another camera in sequence, see the section, Continuous Camera Sequencing, below.

[edit] Tracking Camera

The Tracking and Static cameras have different icons and different behaviors. The Tracking camera follows the train engine and is activated when that engine enters an area defined by a sphere with a radius of about 200 meters (~650 feet); the camera hood is green; and the camera turns off (the driver's view is passed to another camera or to Chase mode) once the train leaves the sphere centered on the camera or enters the sphere of another camera (see below). Note that for a Tracking camera, both the pan and tilt of the camera will be determined by the location of the focus engine, so you need only adjust the closeness to the track (PgUp/PgDn) and position relative to the ground (up/down arrows) when in Roaming mode. In Walk mode, the camera is set on the ground and the arrows move the camera to the right or to the left or forward/backwards. Thus, for a "person watching" point-of-view, Walk mode offers a way to make fine adjustments in the camera's location.

A Tracking camera will focus on a train coming from either direction and point towards the approaching engine, then follow it past the camera to the point where the camera hands off the view as determined by the engine. Realize, that camera-on/camera-off is shorter in time (actually distance along the track) the farther the camera is set from the track, and will not occur for a camera set beyond the activation radius of 200 meters. This fact can be useful in setting up cameras in complex track areas, where cameras are intended to activate only for a specific section of track and not another track nearby.

Camera-off occurs when the focus engine reaches 200-m from the camera. Thus, camera-on and camera-off are not influenced by train length. The trigger is the engine, entering then leaving the 200-m radius sphere. For further discussion on handing off the camera view to another camera in sequence, see the following section, Continuous Camera Sequencing.

[edit] Continuous Camera Sequencing

Placing cameras at particularly interesting points along a route will result in the view shifting from Chase to Lineside view as the train progresses and encounters the camera triggers (if in Lineside view mode). Chase mode views are set up and adjusted by the driver and Lineside mode views—set up by the developer—may conflict with the user's preferred way of following his train. This fact suggests that if Lineside view is going to be used as the Session setting, the experience should be a continuous one for at least some distance of travel if not the entire layout. Lineside view becomes a tool that can be developed to display a route/session in a manner at the control of the developer, particularly suitable to ride-along scenarios. Setting up a series of cameras that move the view from camera to camera as a train progresses along a track can be a fairly complex undertaking, requiring not only consideration of the best separation between cameras, but some appreciation of cinematic principles. Cameras must be chained together so that the view is handed off smoothly from one to the next camera in sequence; cameras set too close together will produce short bursts of views and a jerky experience; too far apart and the driver will experience the view jumping back and forth between a Lineside view and Chase view. Camera views are the equivalent of a rail-fan's experience of your route and this may be an important consideration in where you place each camera relative to the ground.

Camera sequencing amounts to placement of cameras close enough together to produce smooth transitions (camera view hand-offs) in Driver mode. Accomplishing this can be done by hit or miss, by using the Ruler tool (for Tracking cameras, separation should be around 1000 ft or 300 meters), or by employing the guide camera sphere <KUID2:70337:23049:1>, a tool object that, set directly on the ground beneath a Tracking camera, draws a transparent green "influence" sphere showing where the distance of 660 feet (200 meters) is located from that camera in all directions. A serviceable older guide is <KUID:70337:23048> that draws a 200 m purple cylinder around the center point. The guide camera static <KUID:70337:23050> provides a similar tool for setting up a Static camera, although a bit trickier to use. Of course cameras need not be placed at the point where two adjacent hemispheres just touch or just overlap, but approaching this maximum spacing will establish a longer stay on each camera. The guide sphere is not visible in Driver mode, although should be deleted after use, accomplished by using Delete object in the Objects menu anywhere in or on the sphere.

Considering just the two types of camera, 4 transitions are possible; add the transition into or out of Chase mode, and eight transitions are possible (n to the third power minus non-existent Chase to Chase). Consider also, that transitions, in most cases, need to work well in either direction of train travel. The first rule is to ensure camera view overlaps, as any gaps in the next acquisition will switch the Driver's view to Chase mode then quickly back to Lineside view. Further complicating hand-offs is the fact that the ends of the consist trigger a static camera on and off. Of importance in setting up cameras to sequence views as the focus consist moves along is camera priority. By priority is meant which type of camera will prevail where activation overlaps with another camera type. It bears mentioning (and is discussed below) that some tunnel objects assert camera control as a train enters the portal.

Tracking to Tracking - Hand-off from one Tracking camera to the next Tracking camera occurs when the center of the focus engine passes a point where distance to the next camera is less than distance to the active camera. That is, view transition will occur midway between the over-lapping influence spheres of two adjacent Tracking cameras.

Tracking to Static - The hand-off from a Tracking to a Static camera is determined by the view of the latter AND the focus engine entering that view area. If there is overlap in the view areas, the switch will occur when the focus engine is equidistant from the two cameras. In essence, the static camera has priority, but the handover point is a compromise. The priority of a static over a tracking camera provides a method for selectively setting the view to one track in a session where a tracking camera covers more than one track.

Static to Tracking - Static cameras do not turn off or hand over the view until the end of the train passes out of view or reaches 200 m (650 ft) distant. A Static camera placed within the sphere of a Tracking camera results in the Static camera grabbing the view as soon as the train appears (actually the midpoint of the car entering the camera view) and holding on to the view until the train leaves (the midpoint of the trailing car). In this sequence, the Static camera has priority over a Tracking camera, which will display once the Static camera looses the consist.

Static to Static - Sequenced Static cameras need not have overlapping views, only that the front of the consist enter the 'next' Static camera before the end of that consist leaves the active camera. Thus, it is possible to set up two or more Static cameras and achieve a smooth transition, at least in theory. However, any actual gaps in camera view placement will achieve a good hand-off only for trains of a particular length or greater (that is, may not work well with shorter trains). Aiming two static cameras in sequence in different directions (one aimed up the track and one down the track) is relying on timing to affect a smooth transition, and therefore sensitive to train length (see Sequencing Problems: "Bugs").

[edit] Camera Transition Rules (Summary)

• A camera must be within 650 ft (200 m) of the track to acquire and present a view and Lineside view must be the selected option.
• Gaps in coverage transitioning from one camera to the next will result in the screen temporarily switching to Chase view.
• A Tracking camera centers the view on the focus engine, panning as the engine moves past and is controlled (turned on/off) by distance (under 200 m) from the camera.
• Hand-off from one Tracking camera to another occurs when the distance from the first exceeds the distance to the second (i.e., at the midpoint in the overlap of their respective 200-m radius spheres)
• A Static camera is activated when the front end of the consist enters within 200 m of the view frame and triggers off when the rear of the consist exits the view or moves beyond 200 m from the camera.
• A Static camera will acquire and keep the view (has priority) even where placement is within the sphere of a Tracking camera or followed in sequence by another Tracking camera.
• Camera priority is as follows (lowest to highest):-
  • Chase view
  • Tunnel
  • Tracking
  • Static

[edit] Choreographic Considerations

For those Trainz aficionados particularly into developing realistic scenery, the Lineside view provides a bounded canvas for adding detail that will be noticed by the driver. In general, small objects are not necessarily seen by a driver in the more commonly used Cab or Chase views. Lineside view is an opportunity to develop focused detail on your layout, including objects that themselves move (persons walking, persons with body movements). Because the train moves through a fixed view, a Static camera is particularly well-suited to setting up this sort of detail to emphasize activities ongoing beyond the train and track: small dioramas that enhance the enjoyment of both the route developer and route drivers. Starting a ride-along session (train under AI control) in Lineside view can be an excellent introduction to your route, especially if coupled with triggered message pop-ups (See: Message Popup Rule) that describe what is displayed.

[edit] Opening Session Camera View

On the start of a Session, you may wish to have the view focused on a particular train or some other object. The default will be a Chase Mode view of the engine of the first driver listed in the Driver Setup under Edit Session, whether an AI Driver or First Human Player. Unsetting the Driver Setup Rule "Focus camera on first Driver" shifts this initial focus to the First Human Player. You can also control this initial opening using the Set Camera Rule, which allows choosing the view upon rule execution; focus might be, for example, on the station platform. Combined with a trigger, this rule may be used at any point in a session, opening up choreographic possibilities other than those discussed here considering just Lineside Camera view. If you wonder how the "camera" knows where to be when you run the session, it will be the view as seen when you selected the object to focus on before you closed editing the rule. Realize that specifying an engine other than the one you wish to follow will shift Session focus to that other engine.

Another rule that works (does not work in TRS2019Beta) in a more or less similar manner is the Focus Camera Rule. This rule differs from the previously described Set Camera Rule only in that no list of objects to choose from is provided (the Set Camera Rule provides an incomplete list of objects). An option for setting the camera pitch and yaw has no effect. Set View Mode will influence what you get with whatever driver does have focus at start of Session. Indeed, in TRS2019Beta both rules produces no predictable outcome other than preserving whatever view was present when you saved the Session edit.

A third rule for controlling screen view, especially at the start of a Session, is the Cinematic Camera Rule, ostensively providing "several different cinematic style cameras with animations". The animations work, but the list of focus objects is a mixed bag of train cars, engines, and a small number of named objects. Zoom and circle object do work, but the rule must not implement until the scene is fully painted, requiring some sort of delay (or perhaps circling twice).

[edit] Tunnels

When a train enters a tunnel, the screen view will be altered in a manner dependent upon the tunnel asset itself. A camera following a train in Chase Mode may suddenly be viewing the train from inside the mountain—undesirable because from outside, the tunnel walls become invisible, as does the ground above. The camera angle may shift to looking directly down on the engine, but still hovering above it. In other cases, presumably tunnels meeting the latest standard, the camera will come to rest on top of the engine, and the view becomes one of riding along inside the tunnel feature.

In Lineside Mode, a shift as described above may or may not occur, depending on the tunnel asset. Ideally, the train disappears into the tunnel and a Tracking camera continues to follow it, pointing at where the engine is under the ground. In TRS2019, this is not the case: the tunnel grabs the view from the camera, forcing the view onto the engine inside the tunnel. Worse, once grabbed, the view is fixed and no switch to any view, manual or otherwise (except Cab view), can be made. This "bug" has been fixed in TRS2019Beta.

A Tracking camera above the tunnel will point downward towards the engine, showing just the ground surface; a Static camera continues to point to wherever it was set-up to point as long as the consist is within range. You could prevent this behavior by making sure the camera loses control just as the train enters the tunnel portal (be sure another camera picks it up outside the other end). In Lineside Mode, how the screen view is treated after the train "disappears" requires some thought. If the tunnel is long, to prevent a switch to the engine inside the tunnel may require having one or more additional cameras located on the mountain above the tunnel. This will work as long as the distance to the train below is less than 200 m. Remember, this distance is measured from the camera to the train—as the train progresses, its distance from the camera will steadily increase.

The view of the landscape above the train sans train will need attention, if only to obviate temporary boredom. One consideration might be placing a triggered message (see Message Popup Rule), such as one providing tunnel name and length; or one describing the view that is displayed.

[edit] Problems

• TrainzPlus SP4 solves problems described on this page and camera use in TRS2019 is mostly problem free. An exception is manifested as a placed camera becoming inaccessible to editing or deleting. The camera works as intended in a session, but cannot be moved, adjusted, or removed in surveyor mode. This problem is caused by placement of the camera too close to some other object (such as a boulder). For this same reason, you will not be able to adjust a camera with the camera guide present. Moving the object away from the camera object (or deleting the guide camera sphere) will allow access to the camera again.

• Because a camera is an object (although cannot be moved in Object mode), adjusting an existing camera by clicking on the camera body with Move camera "M" will have the annoying effect of causing the camera to jump away from its original position, obviating the making of minor adjustments to the view. The distance of the jump can be minimized by approaching the camera from directly overhead.

• In Driver mode, a small, but sudden shift in the view likely means you have accidentally set two cameras in very close proximity, an easy mistake to make when adjusting a camera by selecting the Place camera "A" tool instead of the Move camera "M" tool. Delete one of the cameras. Large shifts in the view (jumps to a more distant camera) indicate imperfect placement of cameras set in sequence.

• Various Session Rules that might be used to set the camera view (not the Camera object) produce problematic results in TRS2019Beta but may be useful to set an initial scene for a Session. In their absence, the start-up Session view will be the focus engine in Chase mode (in TRS2019Beta, it is last view present when the Session was saved).

In TrainzPlus, a Static camera may not always operate as expected under the rules outlined above. After handing over to another camera in sequence, the Static camera will flash back on. The trigger seems to be when the train engine reaches a point equidistant from the active camera and the previous (Static) camera. This action is, however, dependent upon both camera placement geometry and train length. Short trains will not trigger the undesirable action; very long trains will result in a back and forth switching between the two cameras ("flicker"), suggesting that the engine reaching a certain distance from a camera is not the only trigger. Making sure the Static camera is outside the influence sphere of the Tracking camera appears to avoid this problem, but having inconsistent rules for handing over to a next camera in sequence suggests other problems are lurking within the code. This bug appears to have been partially fixed as of TRS2019 SP4 (build 114800), but not with respect to sequenced Static cameras: a back and forth "flicker" occurs between two Static cameras so long as any part of the consist remains within view of the first camera. This behavior is odd, because it says any movement (not the lead end of a consist) will turn a Static camera back on unless the focus has been acquired by a Tracking camera. This behavior is contrary to the Camera Transition Rules and clearly a bug because camera behavior should not depend on the length of a consist. Placing a Tracking camera between two Static cameras causing camera "flicker" prevents the problem from occurring.

[edit] Cameras in the Future

Future versions will include a "timeline" mode that will allow setting a variety of camera controls to capture the perfect video footage using the trackside cameras. This system would include tweaks to the tracking cameras; adding pans, zooms, etc. to any camera (Tony Hilliam, Forum, March 11, 2019).

[edit] Trainz Wiki

Related Tutorials and Guides to Using Trainz Help: Driver Menu Camera Session Rules (Camera rules explained) How to Guides (How-to Menu)