Installation and Setup

The Riveting Realms camera system is designed to be easy to set up and get started with. You can be up and running in minutes.

Basic Installation

• Acquire the plugin, if you haven't already:
  • For standard license customers, purchase and download the Riveting Realms camera plugin .zip file for the version of the engine you're using.
  • For studio customers with source access, follow the separate directions to download the source code provided in the studio onboarding link.
• Unzip the contents of the downloaded plugin files, and place them in the UnrealEngineInstallDirectory/Engine/Plugins/Marketplace directory.
  • If the Marketplace folder doesn't exist yet under Engine/Plugins, you may need to create it.
• Start the editor and enable the plugin(s).
  • Edit → Plugins → Enable the RR camera plugin, and restart the editor.

Optional Enhancements

• If you would like the enhanced UI experience while editing camera styles, download, install and enable the free Riveting Realms Enhanced Data Asset Editor plugin from the Unreal Fab marketplace.
  • NOTE: This plugin is distributed separately due to Unreal EULA restrictions on distribution of plugins that modify engine code and/or link against editor libraries.
• For real-time feedback when editing all camera values - including when clicking-and-dragging component values of vectors and rotators - add the following setting to your Editor.ini (ex., YourGameFolder/Config/DefaultEditor.ini):

  [ConsoleVariables]
  Slate.bAllowThrottling=0
  

Game Project Integration

• The RR camera system integrates as a layer between your game, and the engine's default behavior.
• It does this by extending classes that are part of the engine to add/replace built-in functionality.

Player Controller Settings

• In order to use the RR camera system, your player controller class must be set to use the RrPlayerCameraManager, or a custom Blueprint or C++ class whose parent is RrPlayerCameraManager.
• (Optional) RrCameraPlayerController exposes useful camera functions directly on the player controller.
  • To gain access to this functionality, change your player controller class in Blueprint or C++, whose parent is currently PlayerController, to derive from RrCameraPlayerController instead.
• (Optional) The RrCameraDebugController provides functionality for in-depth debugging of camera modes while the debug camera is active (typically bound to ; (semicolon) while playing).
  • To use it, change the debug camera controller class on your cheat manager to RrCameraDebugController, or, if you already have a camera debug controller, change its parent from DebugCameraController to RrCameraDebugController.
  • If your game doesn't have a cheat manager class yet, you can create one and set it to be used by your player controller, as in the example setup image shown below.

Example Configuration

A sample setup using Blueprints, as shown in the image below:

• YourGameMode is a Blueprint derived from GameModeBase, and is set as the default game mode for the project.
  • Note that individual levels can also override the game mode, so setting the default may not set the game mode in all cases.
• YourPlayerController is a Blueprint derived from RrCameraPlayerController, which allows functionality provided by the RR camera player controller to be used.
  • The PlayerCameraManagerClass is set to RrPlayerCameraManager.
  • The CheatClass is set to YourCheatManager.
• YourCheatManager is a Blueprint derived from CheatManager.
  • The DebugCameraControllerClass is set to RrCameraDebugController.

Set up camera styles for cooking

• You can add the below snippet to your DefaultGame.ini, or configure this through the editor.

[/Script/Engine.AssetManagerSettings]
+PrimaryAssetTypesToScan=(PrimaryAssetType="RrCameraStyle",AssetBaseClass=/Script/RrCamera.RrCameraStyle,bHasBlueprintClasses=False,bIsEditorOnly=False,Directories=((Path="/Game"),(Path="/RrCamera")),SpecificAssets=,Rules=(Priority=-1,ChunkId=-1,bApplyRecursively=True,CookRule=AlwaysCook))
+DirectoriesToAlwaysCook=(Path="/RrCamera")

• The above setting will include all camera styles from your game, and the RR camera styles as well. You can adjust the filter to exclude RR styles and/or only look for camera styles in certain folders.
  • NOTE: If you exclude RR camera styles from packaging, make sure you replace any referenced RR styles and other assets in the camera settings with replacements/copies in your game as well, to ensure everything works properly.

Using the precompiled/standard plugin with source versions of the Unreal Engine

• If you are using a source version of the Unreal Engine, you may need to modify UnrealBuildTool to build successfully with the precompiled/standard version of the plugin.
• To point UBT at the correct intermediate directory for the precompiled camera plugin, add the code block indicated by RR BEGIN/RR END below to the GetModuleIntermediateDirectory() function in UEBuildTarget.cs, after ModuleConfiguration is set:

	private DirectoryReference GetModuleIntermediateDirectory(ModuleRules ModuleRules, UnrealArchitectures? Architectures)
	{
		// Get the root output directory and base name (target name/app name) for this binary
		DirectoryReference BaseOutputDirectory = GetBaseOutputDirectory(ModuleRules);

		// Get the configuration that this module will be built in. Engine modules compiled in DebugGame will use Development.
		UnrealTargetConfiguration ModuleConfiguration = Configuration;
		if (Configuration == UnrealTargetConfiguration.DebugGame && !ModuleRules.Context.bCanBuildDebugGame && !ModuleRules.Name.Equals(Rules.LaunchModuleName, StringComparison.InvariantCultureIgnoreCase))
		{
			ModuleConfiguration = UnrealTargetConfiguration.Development;
		}

		// RR BEGIN - For precompiled plugins (such as the RR camera standard plugin), use the plugin's intermediate directory.
		if (ModuleRules.Plugin != null &&
			ModuleRules.bUsePrecompiled &&
			ModuleRules.Plugin.Type != PluginType.External &&
			!ModuleRules.Plugin.bExplicitPluginTarget)
		{
			DirectoryReference PluginIntermediateDirectory = DirectoryReference.Combine(
				new DirectoryReference(ModuleRules.PluginDirectory), 
				GetPlatformIntermediateFolder(Platform, Architectures, false), 
				GetTargetIntermediateFolderName(ModuleRules.Target.Type == TargetType.Editor ? "UnrealEditor" : "UnrealGame", IntermediateEnvironment), 
				ModuleConfiguration.ToString(), 
				ModuleRules.Name);
				
			return PluginIntermediateDirectory;
		}
		// RR END

		...
	}

Camera Styles

• Camera styles represent distinct modes of operation for the camera system.
  • In addition to a default/navigation camera style, your game may want to make use of additional, distinct styles for different navigation modes, gameplay functions, and scripted interactions. Typically these will correspond to features/modes of play in your game.
    • For example, depending on the type of game you're making, you may want to have camera styles separate from your default camera defined for modes of gameplay such as Swimming, Ladder Climbing, NPC Interaction, and Cover.
  • The RR camera plugin allows you to build these styles separately, and let the camera system handle smooth blending between them automatically.
• Camera styles are composed of smaller, reusable pieces of camera functionality - CameraTraits - which are described below.

Adding Initial Camera Styles

While you can make camera styles from scratch, the easiest way to get started is to copy an existing sample style provided with the plugin, and start modifying it from there to get the exact behavior that you want.

• Riveting Realms-authored sample styles can be found in the plugin's content folder, and are prefixed with Rr to avoid style name conflicts with any styles you might create for your project.
  • Some example styles included with the plugin:
    • RrThirdPerson - This style is designed to be a good starting style for a 3rd person navigation camera.
    • RrOverTheShoulder - This style is designed to be a good starting point for a 3rd person over-the-shoulder camera, such as those found in shooting games.
    • RrLookAt - This style is designed to be a good starting point for building camera styles that look at a target, such as lock-on-target cameras, or cameras that look at POIs.
  • Other provided utility styles that are used by default, but can also be changed in the Riveting Realms Camera System settings:
    • RrCameraActor - This is the default style used when the view target is set to a camera actor, such as when a Sequencer camera is active.
    • RrFixed - This style replaces the engine built-in functionality when using the fixed camera style.
    • Styles starting with RrDebug... - These are used by the enhanced camera debugger. More information about using the debugger can be found below.
• To test out any of these styles, you can use the engine's built in camera stylename command to switch to the style for debug testing/preview while playing the game.
  • For example, the console command camera RrThirdPerson switches/blends to the 3rd person example camera style provided with the plugin.
  • Information on switching styles via other methods is provided below.
• When you find a useful style to serve as a basis point for your camera, an easy way to get started is to copy that file into your own project's content folder, and rename it to something unique, using the following naming convention: CameraStyle_StyleName.
  • The name of the camera style asset is the name it will be referenced by in Blueprint, etc.
  • CameraStyle_Default is recommended for the default camera style, but you can change the default style name in the camera system settings if desired.

Live Editing with Play-In-Editor

• You can make changes to any of the configurable properties of a camera style while using Unreal's Play-In-Editor (PIE), just by editing the properties of the associated camera style asset.
  • This also works while the game is paused, and even when using the camera debugger.
• Traits included with the plugin are also built to be able to handle being added-to/removed-from the style, and enabled/disabled dynamically during play.
• If you have disabled Slate throttling as described in the Setup section, you can also click-and-drag on any property value that supports it, and see the effects in real-time.

Setting/Switching Styles

• The RR camera plugin hooks into existing functionality for setting the camera style, but also extends it for more developer control.
• For debugging purposes, you can change styles with the camera StyleName debug command.
• For setting/switching the style in Blueprint or C++, you can use SetCameraStyle, PushCameraStyle, and PopCameraStyle with or without a transition/blend.
  • These functions are exposed on the RrPlayerCameraManager, and also via forwards on RrCameraPlayerController (if your player controller class derives from it).
  • Pushing/popping of camera styles refers to the camera style stack, described below.
• The engine's built-in PlayerController functions SetCameraMode, ClientSetCameraMode, and ResetCameraMode are also supported.

Camera Style Stack

• The RR camera manager maintains a stack of camera styles, allowing you to push a style to switch to it, and then pop back to whatever the previous style was, when you want to switch back.
  • This helps to simplify the camera logic in many scenarios by not requiring your code/BP logic to know/remember what the previous camera style was.
• If you set the camera style, it's equivalent to resetting/clearing the stack, and then pushing just that one style that's being set.
  • The engine built-in set/reset camera mode functions are also considered "set" operations.

Smooth Blending

The camera system is designed to blend smoothly between camera styles.

• To achieve a smooth blend, simply set the style's Default Transition In → Transition Time to the amount of time in seconds you would like the transition to that style to take. Or set it to zero for a camera cut.
  • In some scenarios/functions, a transition time less than zero - such as -1.0 - is used to indicate that the default transition time for that style should be used.
• To override the default blend-in time of a camera style, you can set SpecificStyleTransitionIns and SpecificStyleTransitionOuts to use a different blend for a specific style-to-style combination.
  • While the ability to set both custom transition-in and transition-out settings are provided for convenience, only one transition configuration can be used at a time. In the case where both are specified, the camera system will use the "transition-in" setting.

Blend Algorithms

By default, the RR camera system uses a custom curve to define the transition between styles. But, if desired, you can also use any of the base blend algorithms provided by the engine.

• Curve - This is the default blend style for RR cameras; uses a custom-tuned curve asset to map the transition from one camera/camera style to another.
  • *In newer versions of the engine, you can refer to the curve blend algorithm in some engine camera/view target functions that take an EViewTargetBlendFunction parameter, by selecting VTBlend_PreBlended.

Blend algorithms provided for compatibility with the base engine:

• Linear - Simple linear blend.
• Cubic - Uses cubic interpolation.
• Ease in Out - Ease in and out algorithmically.
• Ease In - Ease in, linear out.
• Ease Out - Linear in, ease out.

Blend Settings Example

1. Transition Time - The amount of time taken to complete the transition to the camera style, from another camera/style.
2. Interpolation Algorithm - The algorithm used when blending between styles.
3. World Space Blend Weight - The weight given to world-space blending.
4. Local Space Blend Weight - The weight given to camera-local space blending.
5. Target-Relative Blend Weight - The weight given to blending in target-relative space (blending based on where the target is in camera space).
6. Relative to Target - Allows you to specify which target target-relative blends apply to.
7. Specific Style Transition-Ins - Allows you to define custom transitions when switching to this camera style from other specific styles.
8. ** Specific Style Transition-Outs** - Allows you to define custom transitions when switching away from this style to other specific styles.

Camera Volumes

• RrCameraVolume is a placeable volume that pushes a style specified by its CameraStyle property onto the style stack a player enters it, and pops the style back off the stack when the player leaves.
• You can also optionally specify a camera track to apply the setting to.
  • If this is none/left blank, the camera style will be pushed to the default track.

Camera Traits

• Camera Traits are individual pieces of camera logic that are designed to be combined together to compose the overall output of a camera style.
• Traits make their contribution to the overall behavior of the style, by making changes to the transforms of the the camera track currently being updated.
• The traits execute in order, and are not aware of each other, so ordering does matter.
  • A simple way to think about it when determining order, is what (if any) other traits its functionality might depend on having already been factored in.
  • As an example, the Collision Avoidance trait needs to know where you otherwise want the camera to be in order to adjust the final location of the camera properly - so collision avoidance should be placed after any other traits that move the camera, that you want collision to care about.
  • Because this is intended to be a dynamic, customizable system that supports any sort of custom traits developers might want to create - that could serve any function, and need to be ordered in any possible way - we don't hard-code dependency order, and instead leave it up to the developer.

Traits Included with the Plugin

Debug Traits

These included traits are used by the camera debugger, and likely not something you want to include in shipping camera styles.

Trait Instance Data

• Camera trait instance data is runtime data used by an instance of a particular trait.
• If there are multiple copies of a trait present - due to duplication in a camera style, or multiple cameras active due to running in split-screen or with multiple tracks - each trait instance will receive their own unique copy of the instance data.

Named Instance Data

• Some traits that use instance data will provide the option to name the instance data.
• Naming instance data allows consecutive camera styles that have the same traits to re-use the same already-initialized data from the previous style, to reduce/eliminate discontinuities.
  • For example, you have smoothing/damping or gamepad look input acceleration applied to one camera style, and then switch to another that also utilizes that behavior - rather than stopping and restarting the effect, it can simply continue smoothly.
  • This is somewhat similar to the way CameraModifiers work in stock Unreal, but with the key difference that you do not have to manually manage the state of camera traits.

Creating New Traits

• While the traits included with the camera plugin cover a wide range of game camera needs, sometimes some game-specific custom camera functionality is needed.
• You can write your own traits in Blueprint or C++ - including exposing tunable properties - and add and tune them in your camera styles, just like traits that come packaged with the plugin.
• If your traits need to retain information across frames, you can create a corresponding trait instance data class to store that information - just as with the built-in traits.

Creating/extending traits with Blueprint

• You can extend from RrCameraTrait in Blueprint or C++ to create custom traits.
• You can find an example Blueprint-created trait (BP_RrCameraTraitExample) the plugin's /BlueprintTrait subfolder
  • This trait demonstrates adding a smoothly-interpolated world-space offset based on the character's velocity, for example purposes.
• Studio license customers can use the implementation of existing plugin traits in C++ - found in the /RrCamera/Traits subfolder - as a reference for building code-based traits.
• A complete documentation reference on building traits is in-progress and will be available prior to the 1.0 release.

Camera Targets

• Camera targets are essentially a generalization of the Unreal Engine concept of the "view target".
• Targets are referred to by gameplay tag, in the following format: Camera.Target.TargetName

Uses of Targets

Some of the implemented use-cases for targets:

• An attachment point to set the camera's base location and other POV information from.
• A target to look at, such as a point-of-interest or focused enemy.
• A safe point for collision to pull back toward, or ensure visibility/clearance to.
• A reference point for target-relative camera style transitions.

Types of Targets

View Target

• The View Target (Camera.Target.View) corresponds to the Engine-defined target of the same name.
• The Engine typically handles setting this target for you.
• The view target is usually set to the possessed pawn while playing (typically a player character), or the player controller/player state at times when there is no pawn available (such as while spectating, or before the character is spawned in).
• In most games, most of the time, the camera will be setup to attach to this target.

Collision-Safe Target

• Camera.Target.CollisionSafe is the default target used with the Collision Avoidance trait to determine where the camera pulls in toward in the event of a collision/blocked view.
• If Auto Set Collision Safe Target is enabled in the camera settings (Project Settings → Riveting Realms Camera), the camera manager will automatically sync this target to the view target.

Look-At Target

• This target is defined by the plugin for convenience as the default target for look-at type functionality.
• Because look-at targets are always game-specific, this target must be manually set in order to be used.

Pawn Target

• Target that is automatically/always set to the owning player's controlled pawn (if any).
• While the controlled/viewed pawn/character is usually the view target, the view target typically changes when using camera actors, Sequencer, etc. So if you need a reliable reference to the pawn specifically - such as for target-relative transitions - this target can be used.

Debug Target

• This target is used by the debug camera style inspector.

Game-Defined Targets

• You can add as many additional targets for your game as you like. Targets are identified by their associated Gameplay Tag.
• To add a target, simply add a gameplay tag for it (ie. Camera.Target.TargetName), and then you can reference that tag wherever camera targets are specified.

Setting a Target

• Targets are set per-player/camera manager, and may be set globally for all tracks, or for a specific track by track tag.
• A number of ways to set a target are exposed in both C++ and Blueprint, with or without a blend:
  • Set Target by Interface - If you have an object or actor that implements the IRrCameraTargetInterface, you can set the target that way.
    • The camera target interface allows you to write custom logic for updating the target's POV
  • Set Target by Actor - Set the target to a specified actor; the derived POV will be based on the associated target settings and components that the actor has.
    • If allowed to use camera components, the POV will be derived from the camera component.
    • If a bone or socket name is specified, and the actor has a skeletal mesh component, the target will attempt to find that bone/socket and extract transform information from it.
    • If no relevant components are found, the target's POV will be set based on the results of calling the GetActorEyesViewPoint() function, which can be overridden in C++.
  • Set Target by Location - This allows setting a target to a specific location, and optional orientation.
  • Set Target by Camera View - This allows setting a target to a FRrCameraViewInfo - useful in some scenarios for "freezing" a viewpoint previously calculated for a camera track or target.
  • Set Target by View Info - Similar to setting by camera view, this uses the engine's built in FMinimalViewInfo struct instead.
• You can also remove a target with RemoveTarget.
  • Note that you can't remove the view target, due to it being tied to automatic/engine functionality.

Blueprint Set Target Example

• Setting the Look-At target to an actor named LookAt in the level.
• No track is specified, so it will be set as a global target.

Target Parameters

• In addition to specifying what the target is, you can also specify parameters that determine the behavior of the target.
• Currently there are two ways to specify target parameters:
  • Per-target defaults on the camera style
  • Explicitly set parameters for a given target in Blueprint or C++.
    • The RrPlayerCameraManager exposes Set Target Params and Clear Target Params for setting/clearing target parameters respectively.

Target Parameters Settings

1. Target Tag (Key) - The target to set parameters for, referred to by its gameplay tag.
2. Bone or Socket Name - When attaching to a target actor with a skeletal mesh component, you can specify a bone or socket name to attach to on that component.
3. Component Name - For actors with multiple skelmesh components and/or camera components, to disambiguate you can specify a specific component name so the target code will only look at the specific component whose name matches.
4. Fixed FOV - When using the target as an attachment target with camera styles that derive FOV from the attachment target, and the target does not have a camera component or interface that specifies FOV a different way, you may sometimes want to set a fixed FOV for the target. FOV Scale - Allows you to apply a scaling modifier to whatever FOV would otherwise be computed for the target. FOV Offset - Allows you to apply an additive offset (in degrees) to whatever FOV would otherwise be computed for the target.
5. Can Use Camera Component - If set, the target is allowed to look for and pull POV data from a camera component owned by the target actor.
6. Location Offset World Space - Enables you to offset the computed location of the target in world space.
7. Location Offset Target Relative - Enables you to offset the computed location of target in target-relative space (based on its rotation/orientation).
8. Zero Location Valid - Some actors are spawned at the origin, and/or zero may be treated as "unset" - this option allows you to specify whether or not the world origin (0,0,0) is considered valid for the target.
9. Post Process Blend Weight - When using a target as an attachment target, you can also specify post-process settings to apply to the camera, if the blend weight is > 0.
10. Post Process Settings - The post-process settings to use, if the blend weight is nonzero, and the camera style is configured to copy post-process settings from the attachment target (bSetPostProcess is an option on the Attachment trait).

Example setting default target parameters on a camera style:

Camera Tracks

• A camera track is an independent viewpoint that keeps track of its own state.
• Active camera styles and their contained traits influence the track's output POV by making changes to its transforms and other data.
• Tracks are also responsible for handling their own transitions/blends.
• A single camera track can support an unlimited number of camera styles and targets, including smooth blending between those styles and targets. Additional tracks are only needed when your design requires keeping multiple viewpoints active/updated for the same player simultaneously.

Track POV Composition

The POV for a camera track is composed from several separate transforms:

• The BaseView persists between frames, and is usually updated based on the current attachment target.
• Offsets are combined with the base view.
• If a camera transition (blend) is active, it applies its contribution to the final output POV at the end.

Track Base View

• The base view maintains the persistent base view of the camera track, including its point-of-view (location, rotation, FOV), and other related data, such as the aspect ratio, aspect ratio axis constraint, and post-process settings.
• The base view POV is usually set via attachment to a camera target, using the Attachment trait.

Track POV Offsets

Offsets are combined with the base view after the camera update is completed. This allows traits to contribute to offsets largely independently, and without repeating a lot of the same POV composition math in different locations.

• Offset lifetimes/persistence:
  • Persistent offsets persist between camera updates, and are optionally reset on camera style changes, if bResetPersistentOffsetsOnBegin is set.
  • Transient offsets get reset between camera updates.
    • Traits that adjust transient offsets are expected to re-apply their changes to the offset for each update.
• Offset transform types:
  • World Space offsets are combined directly with the BaseView in world-space.
    • The world-space location and rotation are added directly to the base view's POV.
    • The world-space FOV offset is treated as a multiplicative scale, with a base value of 1.0 having no effect.
  • Local Space offsets are computed in camera space, starting from the combination of the base view + world offset.
    • The local-space rotation offset uses quaternion multiplication, allowing for adding in rotation from camera animations, etc., without euler-angle limitations.
    • The local-space FOV offset is an additive modifier - adding or subtracting from the final output FOV in degrees - with a base value of 0.0 having no effect.

Track Types

Default Track

• The automatically created and activated Camera.Track.Default is the primary gameplay camera track.

Debugger Track

• When using the enhanced debug controller, the Camera.Track.Debug track operates the debug camera, separate from the output of the active gameplay track
  • Because it operates on a separate track, using the style inspector doesn't affect the state of the gameplay camera.

Game-Defined Tracks

• To add additional track(s), first define a gameplay tag with the following syntax: Camera.Track.TrackName
• Because additional tracks may not be needed all of the time, tracks are manually started/stopped.
  • Add Camera Track and Remove Camera Track on the RrPlayerCameraManager can be used to add/remove tracks at runtime in C++.
  • Set Active Track can be used to switch the camera manager's active track.
• To set/change the camera style for a camera track other than default, specify its track name when setting the camera style.

Tracks as Targets

• Anywhere that a camera target may be specified, the tag name of a camera track can also be used in its place.
  • In this way, you can layer the output of multiple tracks together, if your specific camera setup requires it.
• The camera system will keep track of dependencies, and compute the output of dependent tracks after the tracks they depend on.
  • NOTE: Circular dependencies are not supported.

Camera Input

• Camera input serves as an generic interface layer between the game/game input processing and the camera.
  • This allows traits to get relevant input in a controlled way, without digging directly into game implementation-specific details, such as trying to grab input objects, retrieve information directly from the character or movement components, etc.
• The default camera input implementation handles input after it's been processed by your choice of camera input systems, so it is fully compatible with Engine built-in camera handling.

Camera Input Configurable Properties

• InputType - The currently active input type.
  • If not set manually/elsewhere, the camera input implementation will attempt to detect which camera input type is active for the current frame on update, and fallback to the input type used for the last frame if no input of any type is detected.
• LastFrameInputType - The input type that was active/considered active last frame.
• LookInputTouchIndex - When using touch input, which touch control index should be used for controlling look input.
• LookInputAnalogStick - For games that use analog stick controls, which analog stick controls camera look functionality. Note that if you want to change this/make it configurable, it should match the look input setup of the input component.
• AnalogStickAccelerationScale - Provides a means to globally scale Look Input analog stick acceleration for end-user control settings support.
• AnalogStickMaxAddedSpeedScale - Provides a means to globally scale the maximum angular velocity Look Input analog stick acceleration can add, for end-user control settings support.

Extending/Modifying Camera Input Behavior

• When writing your own custom traits, it's recommended - but not required - to route inputs through the camera input object, for the cleanest implementation.
  • To do that, you can create your own camera input class that extends from the plugin base implementation, in C++ or Blueprint.
• The default input implementation for the RR camera system is the RrCameraInput class.
  • You can extend from this class to modify functionality or build a custom implementation.
  • Because input is likely to be something that many games will want/need to change, we provide the full C++ implementation at all plugin license levels.
• The camera input class to create/use is specified in the camera plugin settings.
  • You can modify this setting to point to your custom camera input class/Blueprint.

Camera Settings

• You can access the camera settings via Edit → Project Settings... → Riveting Realms Camera (in the Plugins section)

Configurable Settings List

• Default Style Name - This is the name of the default camera style for your game, and the style that the camera manager will attempt to start in.

• Auto Push Camera Style Types - This is used to automatically push a given camera style when an associated actor type becomes the view target. By default, a couple of these come predefined:

  Class Type	Auto-Push Style	Notes
  PlayerController	RrFixed	When the player controller is the view target, it can create a feedback loop between player controller location updates based on the camera, and camera updates based on the controller. Auto-setting a style that does not set the camera based on the controller location is a workaround for that issue.
  CameraActor	RrCameraActor	When a camera actor becomes the view target, generally we want to view through the camera actor's camera component with no other modifications to the POV. The RrCameraActor style packaged with the plugin permits the view target to use camera components for attachment, and pulls all base transform data from that camera component.

• Camera Track Class - The class type of camera track objects. Can be modified to accommodate projects that extend the camera track with custom functionality.

• Camera Input Class - The class type of camera input objects. Can be modified to accommodate projects that extend camera input with custom functionality.

Transition Settings

• Transition Curve - The curve used to map transitions between camera/styles when the Curve algorithm type is specified for transitions. Pre-populated with a curve shape proven to work well for transitions in most scenarios.

Environment Collision Settings

• Environment Collision Curve - Curve used to map how the camera preemptively pulls in when camera environmental awareness is enabled for the Collision Avoidance trait.
• Trace Verify Environment Collision Results - Performs line-checks to verify results produced by the camera environment check. Can be expensive, and is disabled by default.

Restart settings

• Auto Reset Base Rotation on Restart - If set, automatically reset the camera's base rotation to the pawn/character's rotation on restart.

Lens Simulation Settings

• Sensor Sizes - When using FOV by Lens to set the FOV, the sensor sizes to use for computing the actual FOV and aspect ratio are sourced from here.
  • You can define your own additional sensor sizes by adding associated Camera.Sensor.SensorTypeName gameplay tags.
  • Several are provided with the plugin, but you can add your own.
  • Sizes are specified in mm.

Aspect Ratio Settings

• Simulate Constrained Aspect Ratios - Simulate constrained aspect ratios with HUD-rendered black bars rather than actually changing the aspect ratio.
  • When smoothly blending in and out of constrained aspect ratios, the constrained aspect ratio changes every frame. In stock Unreal, this triggers a buffer resize/reallocation every frame, which comes with a heavy performance hit, and added memory usage.
  • Additionally, with the stock implementation, the black color bleeds into the post process, affecting the color of the rendered cinematic.
  • To solve this problem, we offer the option to simulate the constrained aspect ratio rather than actually constraining it.
  • If you disable this, we recommend avoiding blending/transitioning in and out of constrained aspect ratios, in favor of camera cuts.
  • Note that this feature makes use of the PostRenderedActor HUD feature, and can conflict with other uses of that feature, as well as bShowOverlays.

Input Settings

• Scale Gamepad Input by Delta Time - The EnhancedCameraInput plugin is framerate-dependent by default, and - in newer versions of Unreal - input scaling logic is no longer present in default game template implementations such as the ThirdPersonTemplate.
  • If your game code/Blueprint is already handling framerate-independent control stick look input scaling, you can/should safely disable this option.
• Gamepad Look Input Speed Scale - When scaling input by delta time, it also needs to be adjusted to achieve a reasonable base speed.
  • Note that the speeds represented here in the settings are based on the axis of rotation, which is perpendicular to the actual rotation movement. Yaw rotation is "around Z", while pitch rotation is "around Y", and roll is "around X".

Debugging Settings

• Start Debugging Paused - Whether or not to pause the game when you activate the RR debug camera.
• Forward Input when Debugger Unpaused - Whether or not to forward input back to the game camera when using the RR camera debugger, and the game is in an unpaused state.
• Trait Inspector Blend Time - When using the trait inspector, you can adjust how it transitions from one trait view to another using this setting.
  • (Set to zero if you would like it to cut/snap.)
• Initial Camera Debug State - Which state to start the RR debug camera in.
• Debug Trait View Style Name - Which camera style to use when the camera debugger is in Trait View.
• Debug Inspector Style Name - Which camera style to use when the camera debugger is in the style/trait Inspector View.
• Debug Orbit Style Name - This style mimics the behavior of the Engine default debug cam orbit behavior.
• Debug Free Cam Style Name - This style mimics the behavior of the Engine default debug free-cam behavior.

Camera Debugging

The RR camera plugin extends from Unreal's built in debugging functionality.

Enhanced "Showdebug Camera" Output

The engine built in showdebug camera command has been enhanced to show additional information with the RR camera plugin:

• Camera Track - Shows the active RR camera track.
• Aspect Ratio Axis Constraint - Shows which axis the aspect ratio is being constrained by. (Affects how the view scales when the viewport aspect ratio doesn't match the desired aspect ratio.)
• Viewport Aspect Ratio - The current aspect ratio of the viewport.
• Horizontal FOV - The current horizontal FOV.
• Vertical FOV - The current vertical FOV.
• Simulated Horizontal FOV - When the FOV is constrained on the Y-axis, this shows the target X-axis FOV and aspect ratio.
• Movement Speed - How quickly the camera is currently moving in uu/sec.
• Rotation Speed - How quickly the camera is current rotating in degrees/sec.
• Targets - Lists currently active camera targets, and their POV transforms (location/rotation/FOV).
• Style Stack - Lists camera styles currently on the camera manager's style stack.
• Current Style - Displays information about the track's currently active camera style.
  • Style Name - The name of the active style.
  • Style Object Path - Where the actual camera style asset is located.
  • Traits - The list of camera traits that compose the style, and a brief description of what they are doing.
• Transition - When a transition is currently active, displays information about the in-progress transition between cameras/styles.
  • Transition Time - The total time specified for the transition.
  • Interpolation Algorithm - The algorithm selected for the transition.
  • Transition Time Remaining - How much of the transition time is left before the transition will be complete.

Showdebug Camera Example

Using the Enhanced Camera Debugger

• If you've set up the RrCameraDebugController as your controller debug class, you can use its debug camera features to help debug your camera setups.
• Toggling the debug camera on and off is normally bound to ';' (semicolon) by default.

Trait Inspector View

• The trait inspector view provides a 3rd person view of how the camera traits combine together to produce the final output, with basis vectors to indicate the in-progress transform after each trait's changes are applied to the POV.

Trait View

• The trait view shows you the view as it was composed in stages, after each trait contributed to the final output.
• The example in this screenshot shows pre-collision camera output, because a trait that comes before Collision Avoidance in the style is selected.

Camera Debugger Controls

• The debug camera controls are shown on-screen while the RR camera debugger is active, and are also provided here for convenience.
  • (We will also likely make these controls configurable in the near future to avoid conflicts with game-specific key bindings.)
• Inherited camera controls from the Engine debug camera:
  • 'O' - Orbit selected hitpoint.
  • Shift+'O' - Orbit selected actor.
• Additional camera debug controls:
  • 'C' - Switch to/from the trait inspector view.
  • 'T' - Switch to/from trait view.
  • 'Z' - Decrement the currently selected trait, in the trait inspector and trait views.
  • 'X' - Increment the currently selected trait, in the trait inspector and trait views.
  • 'P' - Toggle pause game - allows you to switch back and forth between a paused and unpaused state without leaving/resetting the debug camera.
• All non-camera-controlling debug controls for buffer visualization, view modes, etc., are expected to work as normal.

Enabling/Disabling Traits

• While editing, you can also uncheck the Enabled flag in the Debugging category on individual traits in the camera style asset to disable them.
  • Provides an easy method to do quick A-B testing with or without a specific trait being enabled.

Camera System Integrations

Integration with Sequencer for Cinematics

• When Sequencer is active, a camera cuts track (base Engine functionality) controls setting the view target/switching between camera actors controlled by the sequence.
• The RR camera plugin then sources POV information from the active camera actor, and faithfully replicates the POV and any Sequencer blends - so you can author your Unreal-based cinematics in the editor as you normally would, and they will play back as normal in-game.
• When starting/stopping a cinematic, the RR camera plugin can handle smoothly blending in and out of the cinematic, including blending into/out of constrained aspect ratios.
• Special plugin-defined camera actors intended for direct integration into Sequencer sequences are not currently a feature of the plugin, but are planned prior to the 1.0 release.

Example Blueprint for blending to/from a Level Sequence

Example screenshot showing how to play a level sequence with smooth blend in/out, from the RrCameraExamples testmap included with the plugin.

Integration with the UE5 GameplayCameras Plugin

• While the RR camera plugin does not have any special integration with the GameplayCameras engine plugin as of the early-access release, the RR plugin does support blending back and forth between camera styles and GameplayCameras-controlled camera actors.

Integration with Other Camera Plugins/Systems

If you have existing cameras you would like to integrate with, or would like to use other plugins, etc., in specific scenarios, it's usually easy to make them work with the RR camera system.

Integration via CameraActors/CameraComponents

If the plugin or system uses CameraActors and/or CameraComponents - similar to Sequencer camera tracks, or GameplayCameras camera actors as described above - setting the appropriate target and attaching to it, with a camera style that uses the Attachment trait - and allowing that target to use camera components - may be sufficient for integration.

Integration via a Custom Trait

You can also write your own trait in Blueprint or C++ that takes the output of the other camera system/plugin, and uses it to set the camera base transform, and/or any other relevant camera variables accordingly.

Getting Support

If you need help with getting set up, anything talked about in this document, or something specific - as well as suggestions and feature requests - various methods of getting in touch with Riveting Realms and other camera system users are available on our Support page.