We are noticing when we render out a cinematic that the warmup frames happen at the player start location and not using the camera in the shot. This causes all the lighting to warmup at the player start and then the first frame to render ends up being dark and the lights warming up during our shot. For example, maybe hte player start is outside on a street corner. The render warms up there but our first shot in the sequence is inside a grocery store. When the render actually starts on frame one everything is suddenly dark and quickly ramps up to proper lighting. But that is during the render so each shot has the ramp up.
How does the warmup node determine where to warm up? Can that be overidden, or possibly just tell it somehow to ignore the player and use the shot camera as the documentation describes?
Steps to Reproduce
Setup a scene to render. Put a player start in your scene somewhere other than where you first shot will end up putting the camera. Set the game mode override to a normal game mode such as one used for a 3rd person shooter. This is in the Global Game Overrides node. We do not want to use the MoviePipelineGameMode as our cinematic will be possessing the player. Basically, we are trying to render out a game cinematic and not a simple sequence designed specifically to be rendered out.
Set your warmup frames to something high enough you can observe it happening such as 64 frames.
Hit render and watch that the warmup happens at the player start location, most likely because the player camera is current and not the one that will be spawned when the shot starts. Maybe possession doesn’t happen until after this stage?
Hi Tom,
Are you able to reproduce this in a template project so we can compare apples to apples? I made a Third Person Template project in 5.5, enabled MRQ, made a basic sequence with one camera facing the opposite direction of the player start, and set the GameModeOverride in the Render Graph to the BP_ThirdPersonGameMode, but I am not getting the same behavior as you’re seeing. It exclusively warms up with the camera and renders as expected.
I thought I could break it by offsetting the Camera Cut Track by a few frames, but it still assumed the CineCamera was being used for warmup. I also tried putting in the Third Person pawn and setting it to AutoPossess, but that didn’t override the CineCamera either.
Are you sure there are no extra keys in your Camera Cut Track that are not the desired CineCam? Or do you have BP logic inside your character that forces the view to be set on their camera? To narrow in on the issue I recommend trying first in a basic template project. Then try migrating your character to see if they behave different than the default pawn. You can also try this in a new empty level in your project to make sure there’s no actor or Level BP stealing the camera focus.
I managed to get it to work, but I had to turn on the “emulate motion blur” setting in the “Warm Up” node. With that set, I get the proper frames and cinematic camera used. Without that set I get the player camera used for the warmup, or the cinematic camera with the player transform applied. One of those.
It is highly likely that w do indeed have overrides in place in our player blueprint to control the camera. But, I’d still put this down as a bug on the MRQ side. The sequence has cameras, and a camera cut track, so the MRQ should respect those. If the cinematic was using some blend on the camera cut track, then yeah, the player camera would probably be used to some degree. But since the sequencer is setup to 100% use the cinematic camera, the warmup node should be able to see this and correctly use that camera as well. Further, the fact that it works with motion blur emulation involved, this has already been considered in the code “somewhere” so should be made to work when this option is off as well.
Glad you found a workaround for the time being. I will make sure the product team gets the request for prioritizing Camera Cuts vs gameplay cameras.
I still couldn’t reproduce by turning off Emulate Motion Blur in a template project. If you do discover what is overriding the camera in your project we can make sure we test against that scenario.