* Adding some first pass UI for editing the Universal Object Locators that are used to bind objects to tracks in Sequencer. This is currently in the form of:
* An 'Add Empty Binding' item in the + Actor to Sequencer menu
* A 'Binding Properties' sub-menu in the object binding track properties that allows you to modify the array of UOL's that bind objects to the track. This allows you to specifically select certain UOL types and then fill in the data that makes up that UOL. This is necessary for example for the FortAIPlayerPawn binding we plan on adding for UEFN.
* Major refactor of MovieScene binding code to more seamlessly allow for the use of the Locator resolution, especially in the case of supporting locators that spawn actors, either in the case of editor preview actors or future runtime 'spawnables'. This was necessary to consolidate the cases where locator resolve params were being created to as few places as possible for simplicity.
* Add the concept of 'default' editor and runtime flags to locators to make it easier for Sequencer to know how to interact with bindings of different types. These flags are then stored with the binding in Sequencer and editable by users as necessary. Sequencer treats 'load'/'unload' in this case similar to 'spawn'/'despawn' and generally speaking resolving a locator with editor flags of 'load' will expect the locator to spawn an actor for preview, while resolving a locator with runtime flags of 'load' will expect the locator to create a 'spawnable' character.
* To manage lifetime of these preview/spawnable characters, created an interface for a 'LocatorSpawnedCache' which the locators interact with when creating or destroying an actor. This allows the resolver of locators to differentiate between cases where they expect multiple resolves of the same locator to create duplicate actors vs. resolve to the same actor and track the lifetimes of these spawned actors.
* Sequencer implements the above cache within its own object cache in evaluation state.
* Expand the role of the previously created Binding Lifetime track to trigger loading/unloading via locators in the cache. The Binding Lifetime track will now automatically be added to a binding if its locator type contains 'Load' as a default editor or runtime flag.
* Some other editor updates to support the above.
Future issues to be resolved:
* We want to more easily expose the editing of binding properties when necessary rather than having it buried in a sub-menu. Ideas for this include some kind of UI on the track itself, for example a combo box with binding types on it, as well as potentially the properties menu appearing on hovering over the possessable icon on the object binding track. We also want to expose properties based on selection, for example object binding properties, track properties, and section properties, in another external window.
* We want to eventually replace the 'Actor to Sequencer' and 'Assign Actor' menu with this once the UX is better.
The above was all tested with a Fortnite NPC Locator type which will be added in a separate changelist.
[REVIEW] [at]ue-sequencer
#jira UE-199299
[CL 30596833 by david bromberg in ue5-main branch]
Level Sequences now use UOLs for their bindings.
Level Sequence player context is now an ALevelSequenceActor if possible.
All bindings (including the extreme-legacy lazy object ptr bindings) are now upgraded to use the UOL binding mechanism.
Introduced a new concept for reasoning about object hierarchies in Sequencer: object schemas. Schemas allow customization of how Sequencer handles finding 'parent' and 'child' objects, which allows us to genericize lots of the hard-coded Actor-Component logic. This is just a first pass - there are still many places that directly deal with AActor and UActorComponent, which will be gradually migrated with upcoming work.
#jira UE-199305
#rb david.bromberg, ludovic.chabant
[CL 29932924 by andrew rodham in ue5-main branch]
This is the third step in the overall refactor to remove the dependency of Sequencer evaluation code on IMovieScenePlayer. It puts most of the spawnables/possessables logic into playback capabilities, so that systems concerned with them can find them there instead of depending on the player interface. In order to do this, many APIs previously taking a player pointer now take a shared playback state reference, which is where they find the playback capabilities.
To keep the changelist to a manageable size, we don't deprecate the previous APIs right away except where we don't have much choice, such as the virtual methods of the spawn register. Everywhere else, passing a player is still a valid call.
Some other APIs have also changed, because the shared playback state structure often gives all the information someone may ever need, and this renders many parameters obsolete. This is for instance the case with sequence updaters.
One aspect of this change that needs to be carefully handled is the initialization and re-initialization of a sequence hierarchy prior to playback. Now that evaluation code relies on playback capabilities, these capabilities need to be added to the sequence hierarchy's shared playback state in a timely manner, and they need to react to changes in the hierarchy. The following changes have therefore been made:
- Playback capabilities can implement callbacks for initialization and for when a new sub-sequence instance is added.
- Sequence instances have a new Initialize method that needs to be called shortly after creation. This is especially needed for root instances, as it gives time for the caller to setup their playback capabilities before finishing the initialization.
Another aspect of this change is that it unearthed a problem with the capability storage, where we could stomp memory and crash while relocating capabilities to make room for a new one. This happened if we did not reallocate a new buffer (i.e. relocating in place). Moving headers could stomp the space of the first couple capabilities before we had a chance to move them. The code now moves things from back to front, first the capabilities, and second the headers.
Finally, this change adds the ability to overwrite a capability with a new value. This is needed for the way the level sequence player initializes itself (see the comment in the code).
The following things have been made into playback capabilities, or have had a new capability interface created around them:
- FMovieSceneEvaluationState, for access into object caches.
- IMovieScenePlaybackClient, for dynamic binding overrides.
- The player index, for retrieving the player interface, if any (mostly for legacy evaluators).
- Notification callbacks for when object bindings change.
- Static binding overrides.
- Storage and management of sequence director blueprints.
Since the player interface is now an optional playback capability, some progress has been made to gracefully handle the case of no such player existing.
#jira UE-199669
#jira UE-199668
#rb Andrew.Rodham
[CL 29895537 by ludovic chabant in ue5-main branch]
This can happen if a level sequence is re-initialized with a sequence that it was already set to.
#rb max.chen
[CL 28141287 by ludovic chabant in ue5-main branch]
This change tries to address various problems with the camera cut evaluation logic:
- Use the pre-animated state API to properly handle restoring things, instead of doing it partially "by hand". This removes the need for a few hacks like the carry-over of previous view-targets from one sequence to the next.
- Move the code from FSequencer and ULevelSequencePlayer into the track instance (and some related helper classes). Not only does this remove a bit of code duplication, this also lets us take a first step towards removing the dependency of evaluation code on the player API.
#rb max.chen
#jira UE-194692
[CL 28093600 by ludovic chabant in ue5-main branch]
This was because calling GetViewTarget does some internal checks. If a spawnable camera has just been unspawned (i.e. the actor is PendingKill) then this trips those checks and the view target is reset to the pawn before we can even do anything. Because we are restoring the view target to the pawn, this is registered as "not changing anything" and we skip everything in UpdateCameraCut, including setting the camera cut flag.
We therefore don't use GetViewTarget, and grab the view target directly from the public member to manage things by hand.
#jira UE-190045
#rb max.chen
[CL 26550161 by ludovic chabant in ue5-main branch]
#jira UE-180753
#rb richard.malo, andrew.rodham
#preflight 644fad875875c7d4b4c0b3bf
#rnx
#tests LevelSequence test group + multitude of WP Level Instance use cases (regular WP and instanced)
[CL 25284484 by patrick enfedaque in ue5-main branch]
Tested compiling fortnite, unrealeditor, lyra, qagame with non-unity/pch
#preflight 63635997876630122adeab9f
#rb none
[CL 22958990 by henrik karlsson in ue5-main branch]
- Remove all instances of Master from the UI - ie. Replace Create Master Sequence with Create Sequence with Shots
- Internally, remove Master - Master Tracks in the MovieScene can just be Tracks
Deprecations (Properties):
- UMovieScene:MasterTracks deprecated for Tracks
- UMovieSceneFolder:ChildMasterTracks deprecated for ChildTracks
- FLevelSequencePlayerSnapshot: MasterName, MasterTime for RootName, RootTime
- UMoviePipelineSetting_BlueprintBase: bIsValidOnMaster for bIsValidOnPrimary
Deprecations (Functions):
- UMovieScene: GetMasterTracks, FindMasterTracksByType, FindMasterTracksByExactType, AddMasterTrack, RemoveMasterTrack deprecated for GetTracks, FindTracksByType, FindTracksByExactType, AddTrack, RemoveTrack
- UMovieSceneFolder: GetChildMasterTracks, AddChildMasterTrack, RemoveChildMasterTrack deprecated for GetChildTracks, AddChildTracks, RemoveChildTrack
- FMovieSceneTrackEditor: FFindOrCreateMasterTrackResult, FindOrCreateMasterTrack deprecated for FindOrCreateRootTrackResult, FindOrCreateRootTrack
- ULevelSequenceDirector: GetMasterSequenceTime deprecated for ULevelSequenceDirector::GetRootSequenceTime
- UDaySequenceDirector: GetMasterSequenceTime deprecated for UDaySequenceDirector::GetRootSequenceTime
- UMoviePipelineSetting: IsValidOnMaster for IsValidOnPrimary
- UMoviePipelineBlueprintLibrary: GetMasterTimecode, GetMasterFrameNumber for GetRootTimecode, GetRootFrameNumber
- UMoviePipeline: GetPipelineMasterConfig for GetPipelinePrimaryConfig
- UMovieSceneAudioTrack: IsAMasterTrack
Classes Renamed:
- FAnimTypePreAnimatedStateMasterStorage for FAnimTypePreAnimatedStateRootStorage
- UMovieSceneMasterInstantiatorSystem for UMovieSceneRootInstantiatorSystem
- ULevelSequenceMasterSequenceSettings to ULevelSequenceSequenceWithShotsSetting
Note, the following instances of master still occur and a "KnownCase" has been added for them in CheckAcceptableWords.cs:
- Deprecated properties (MasterTracks -> Tracks) and functions (ie. GetMasterTracks -> GetTracks)
- masterclip in FCPXML since it's an industry standard term
- masteraudiosubmix in AudioCaptureProtocol
- mastersubmix in MoviePipelineAudioRendering
- masteertimecode, masterframenumber, masterconfig, validonmaster in MovieRenderPipeline
- mastersequencetime, mastertime, mastername in LevelSequence
#jira UE-158660
#preflight 634645e48a0a7b2adc5722e7
#rb matt.hoffman, andrew.rodham
[CL 22739302 by Max Chen in ue5-main branch]
Captain's log of the reason behind why this is required:
When spawning a replicated Level Sequence Actor on the server, a SequencePlayer subobject is also created and replicated along with it. If the sequence player is interacted with directly (by way of calling things like PlayLooping, which adjust the loop count of the player's playback settings directly), there can be a justifiable discrepancy in playback settings on the server between the actor and its player. This is not a problem in practice because the Actor's playback settings are only used for initialization.
When these 2 objects are replicated to the client, the client receives the properties for both the actor and sequence player in the same network bunch, applies them, then calls PostNetReceive on both objects. Unfortunately it can call ALevelSequenceActor::PostNetReceive before UMovieSceneSequencePlayer::PostNetReceive, which means the Actor ends up calling Initialize on the player (because it hasn't been set up yet - it's only just been spawned by the net code), which ends up trampling over the player's PlaybackSettings that were just applied by the net replication.
Since the shadow state on the server thinks it has already sent those properties to the client, it never sends them again, so the client doesn't think it's looping when the server does.
#rb Ludovic.Chabant, Max.Chen
#preflight 63345955031c90cb0bab2afb
[CL 22240516 by max chen in ue5-main branch]
Before:
3648 unity files
Total CPU Time: 47886.140625 s
Total time in Parallel executor: 498.81 seconds
After:
3548 unity files
Total CPU Time: 46643.828125 s
Total time in Parallel executor: 486.06 seconds
#jira
#preflight
[CL 22173263 by marc audy in ue5-main branch]
Fixed include paths to be relative to the private or public folders.
Hid or removed includes that reached into other private module folders.
Updated PublicInclude paths when necessary.
#jira
#preflight 631a717cec45fbf3d74d4ba7
[CL 21916033 by bryan sefcik in ue5-main branch]
