How to Place and Use a Camera - Revision history

Sourtoe: Older guide; work-around for flicker "bug"

2021-10-28T01:12:33Z

Older guide; work-around for flicker "bug"

← Older revision		Revision as of 01:12, 28 October 2021
Line 39:		Line 39:
	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.		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 <b>guide camera sphere</b> <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. 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.		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 <b>guide camera sphere</b> <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 (<i>n</i> 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 <b>camera priority</b>. 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.		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 (<i>n</i> 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 <b>camera priority</b>. 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.
Line 106:		Line 106:
	<td>		<td>
	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 <u>engine</u> 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.		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 <u>engine</u> 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 <b>TRS2019 SP4</b> (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.		This bug appears to have been partially fixed as of <b>TRS2019 SP4</b> (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. <b>Placing a Tracking camera between two Static cameras causing camera "flicker" prevents the problem from occurring</b>.
	</td>		</td>
	</tr>		</tr>

Sourtoe: Bug not fixed in SP4

2021-10-28T00:49:36Z

Bug not fixed in SP4

← Older revision		Revision as of 00:49, 28 October 2021
Line 49:		Line 49:
	<u>Static to Tracking</u> - 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 <u>train</u> 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.		<u>Static to Tracking</u> - 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 <u>train</u> 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.

	<u>Static to Static</u> - 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.		<u>Static to Static</u> - 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 [[#Problems\|Sequencing Problems: "Bugs"]]).

	===Camera Transition Rules (Summary)===		===Camera Transition Rules (Summary)===
Line 106:		Line 106:
	<td>		<td>
	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 <u>engine</u> 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.		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 <u>engine</u> 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 fixed as of <b>TRS2019 SP4</b> (build 114800).		This bug appears to have been partially fixed as of <b>TRS2019 SP4</b> (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.
	</td>		</td>
	</tr>		</tr>

Sourtoe: More details on static vs tracking cameras in sequences; fewer problems w/ SP4

2021-10-26T18:23:21Z

More details on static vs tracking cameras in sequences; fewer problems w/ SP4

← Older revision		Revision as of 18:23, 26 October 2021
Line 45:		Line 45:
	<u>Tracking to Tracking</u> - 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.		<u>Tracking to Tracking</u> - 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.

	<u>Tracking to Static</u> - 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. <!-- However, if the consist is backed in, this splitting does not occur. The focus engine remains the trigger and the switch over to the Static camera occurs when the engine enters the Static camera field of view.-->		<u>Tracking to Static</u> - 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. <!-- However, if the consist is backed in, this splitting does not occur. The focus engine remains the trigger and the switch over to the Static camera occurs when the engine enters the Static camera field of view.--> 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.

	<u>Static to Tracking</u> - Static cameras do not turn off/hand over the view until the end of the train passes out of view or reaches 200 m (650 ft) distant~~, regardless of the next camera in a sequence~~. A Static camera placed within the sphere of a Tracking camera results in the Static camera grabbing the view as soon as the <u>train</u> appears ~~to it.~~ and holding on to the view until the train leaves. In this sequence, the Static camera has priority over a ~~tracking~~ camera.		<u>Static to Tracking</u> - 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 <u>train</u> 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.

	<u>Static to Static</u> - 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.		<u>Static to Static</u> - 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.

	===Camera Transition Rules (Summary)===		===Camera Transition Rules (Summary)===
Line 89:		Line 89:
	=Problems=		=Problems=

	*TrainzPlus ~~Beta continues to have the numerous~~ problems described on this page~~; otherwise,~~ camera use in ~~Trainz~~ is mostly problem free. An exception is manifested as a placed camera becoming inaccessible. 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, <b>you will not be able to adjust a camera with the camera guide present</b>. Moving the object away from the camera object (or deleting the guide camera sphere) will allow access to the camera again.		*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, <b>you will not be able to adjust a camera with the camera guide present</b>. 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.		*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.

Sourtoe: "Flicker" bug fixed in SP4

2021-10-26T16:02:25Z

"Flicker" bug fixed in SP4

← Older revision		Revision as of 16:02, 26 October 2021
Line 106:		Line 106:
	<td>		<td>
	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 <u>engine</u> 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.		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 <u>engine</u> 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 fixed as of <b>TRS2019 SP4</b> (build 114800).
	</td>		</td>
	</tr>		</tr>

Sourtoe: emphasize adjusting with a guide in place

2021-10-18T18:03:46Z

emphasize adjusting with a guide in place

← Older revision		Revision as of 18:03, 18 October 2021
Line 89:		Line 89:
	=Problems=		=Problems=

	*TrainzPlus Beta continues to have the numerous problems described on this page; otherwise, camera use in Trainz is mostly problem free. An exception is manifested as a placed camera becoming inaccessible. 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 guide ~~camera sphere~~ present. Moving the object away from the camera object (or deleting the guide camera sphere) will allow access to the camera again.		*TrainzPlus Beta continues to have the numerous problems described on this page; otherwise, camera use in Trainz is mostly problem free. An exception is manifested as a placed camera becoming inaccessible. 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, <b>you will not be able to adjust a camera with the camera guide present</b>. 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.		*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.

Pware: /* Camera Transition Rules (Summary) */ reformatted section

2021-03-09T22:31:41Z

Camera Transition Rules (Summary): reformatted section

← Older revision		Revision as of 22:31, 9 March 2021
Line 53:		Line 53:
	===Camera Transition Rules (Summary)===		===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.~~<br>~~		* 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.~~<br>~~		* 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~~<br>~~ is controlled (turned on/off) by distance (under 200 m) from the camera.~~<br>~~		* 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 ~~<b>~~Tracking~~</b>~~ camera to another occurs when the distance from the first exceeds the distance to the second~~;<br>~~ i.e., at the midpoint in the overlap of their respective 200-m radius spheres~~.<br>~~		* 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~~<br>~~ when the rear of the consist exits the view or moves beyond 200 m from the camera.~~<br>~~		* 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'''~~<br>~~ camera or followed in sequence by another '''Tracking''' camera.~~<br>~~		* 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.
	~~<b>~~Camera priority~~</b>~~ is as follows (lowest to highest): Chase view - Tunnel - Tracking - Static.		* '''Camera priority''' is as follows (lowest to highest):-
			** Chase view
			** Tunnel
			** Tracking
			** Static

	=Choreographic Considerations=		=Choreographic Considerations=

Sourtoe at 17:12, 30 December 2020

2020-12-30T17:12:36Z

← Older revision		Revision as of 17:12, 30 December 2020
Line 85:		Line 85:
	=Problems=		=Problems=

	*~~TrainPlus~~ Beta continues to have the numerous problems described on this page; otherwise, camera use in Trainz is mostly problem free. ~~One~~ exception is manifested as a placed camera becoming inaccessible. 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 guide camera sphere present. Moving the object away from the camera object (or deleting the guide camera sphere) will allow access to the camera again.		*TrainzPlus Beta continues to have the numerous problems described on this page; otherwise, camera use in Trainz is mostly problem free. An exception is manifested as a placed camera becoming inaccessible. 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 guide camera sphere 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.		*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.

Sourtoe: Still no fix for TrainzPlus Beta

2020-12-30T17:11:09Z

Still no fix for TrainzPlus Beta

← Older revision		Revision as of 17:11, 30 December 2020
Line 85:		Line 85:
	=Problems=		=Problems=

	*~~Camera~~ use in ~~TrainzPLUS~~ is mostly problem free. One exception is manifested as a placed camera becoming inaccessible. 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 ~~large~~ object (such as a boulder). For this same reason, you will not be able to adjust a camera with the guide camera sphere present. Moving the object away from the camera object (or deleting the guide camera sphere) will allow access to the camera again.		*TrainPlus Beta continues to have the numerous problems described on this page; otherwise, camera use in Trainz is mostly problem free. One exception is manifested as a placed camera becoming inaccessible. 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 guide camera sphere 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.		*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.

Sourtoe: mention tunnel camera control

2020-12-14T16:11:22Z

mention tunnel camera control

← Older revision		Revision as of 16:11, 14 December 2020
Line 41:		Line 41:
	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 <b>guide camera sphere</b> <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. 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.		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 <b>guide camera sphere</b> <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. 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 (<i>n</i> 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 <b>camera priority</b>. By priority is meant which type of camera will prevail where activation overlaps with another camera type.		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 (<i>n</i> 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 <b>camera priority</b>. 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.

	<u>Tracking to Tracking</u> - 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.		<u>Tracking to Tracking</u> - 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.

Sourtoe at 01:47, 10 December 2020

2020-12-10T01:47:43Z

← Older revision		Revision as of 01:47, 10 December 2020
Line 59:		Line 59:
	A '''Static''' camera is activated when the front end of the consist enters within 200 m of the view frame and triggers off<br> when the rear of the consist exits the view or moves beyond 200 m from the camera.<br>		A '''Static''' camera is activated when the front end of the consist enters within 200 m of the view frame and triggers off<br> when the rear of the consist exits the view or moves beyond 200 m from the camera.<br>
	A '''Static''' camera will acquire and keep the view (has priority) even where placement is within the sphere of a '''Tracking'''<br> camera or followed in sequence by another '''Tracking''' camera.<br>		A '''Static''' camera will acquire and keep the view (has priority) even where placement is within the sphere of a '''Tracking'''<br> camera or followed in sequence by another '''Tracking''' camera.<br>
	<b>Camera priority</b> is as follows (lowest to highest): Chase ~~mode~~ - Tunnel - Tracking - Static.		<b>Camera priority</b> is as follows (lowest to highest): Chase view - Tunnel - Tracking - Static.

	=Choreographic Considerations=		=Choreographic Considerations=