"Set Game Camera Cut this frame" doesn't work

[Fibulator]

I’m trying to create a seamless portal, which “cut this frame” when porting should… ya know… cut the frame out.
However, it doesn’t. At least the blueprint version doesn’t.

Easy to see that something is wrong: Set it to “cut this frame” every tick, which should result in showing 0 frames… but it doesn’t. It just makes the shadows pixelated.

Or I’m doing something horribly wrong? Is there some order of operations, or specific tick group needs to be set to player/player camera?

I’ve tried a couple different combinations but the one extra frame is always there.

Right now I have it set to line-trace to see if the camera crossed the portal threshhold, if so, “cut this frame” and “Set world location/rotation of root” to the correct place. I move correctly, but the frame is still there.

[jwatte]

which should result in showing 0 frames

I believe that “Set Game Camera Cut This Frame” means that “the camera did a jump, rather than a move, so don’t assume smooth camera motion.” There are some comments in the code in this area mentioning motion blur and scene occluders as possibly affected objects; maybe MIP map loading and shadow smoothing also. It also apparently affects the audio player; probably for Doppler reasons? And looks like distance fields and Lumen also use it, and there’s a constant shader parameter that essentially every shader can read to know whether the camera “teleported” or not.

I e, the meaning is “hint to the renderer that there was a camera cut/jump;” it is not “cut out the camera rendering.”

If you want the screen to go black, you can do that with a post processing material, or just add a fat black quad across the viewport using a UI Widget.

If you want rendering from another point of view, you can create a new camera object in the new location, and call Set View Target With Blend on the player controller, with a blend time of 0. Or move the current camera object to where you want it to be rendered from, and call the “Cut” function to tell the system to avoid smooth-movement assumptions.

When you say “one extra frame,” it’s not clear to me what that really means.

Do you mean that the camera went through the portal, and is actually rendering from behind the portal, even when you already moved it?

Or do you just mean that simulation said “player went through portal” and the rendering is still from the in-front-of-portal position? Is this perhaps related to triple buffering, where the displayed frame is actually somewhat behind the simulated frame all the time?

Also, the near clip plane can make it so that even a camera that’s very close to a wall, may render through the wall, because the wall is so close as to be clipped out.

[Fibulator]

Thanks.
Once the player camera passes the portal threshhold there is an “extra” unwanted frame while the player is on the ‘wrong side’ of the portal that needs to not be rendered. I don’t want it to go to black, I just want that single frame to be skipped.

Basically, The player camera is checking every tick if it’s transitioned from one side of the portal mesh to the other. The frame where it does transition is the same frame it teleports… but it’s still showing the stuff behind the portal for that single frame.

In a single tick, the player is “in two places at once”, behind the portal before the teleport, and at the other portal after the teleport. I want it to display the “after” the teleport portion of the ‘tick’.

[Fibulator]

I’m trying to ‘translate’ this c++ into blueprints

FSceneView* UPortalPlayer::CalcSceneView(class FSceneViewFamily* ViewFamily, FVector& OutViewLocation, FRotator& OutViewRotation, FViewport* Viewport, class FViewElementDrawer* ViewDrawer, int32 StereoViewIndex)
{
FSceneView* view = Super::CalcSceneView(ViewFamily, OutViewLocation, OutViewRotation, Viewport, ViewDrawer, StereoViewIndex);
if (camCut) view->bCameraCut = true;
return view;
}

I’m looking for the SceneView’s “CameraCut” variable. The above code works flawlessly in C++, but I’m trying to move entirely into blueprints.

[jwatte]

@Fibulator

I just want that single frame to be skipped.

That’s not what this flag does – I don’t think there’s anything that actually skips renders.

Maybe you have a tick order problem?

You’ll want to detect the position, and set the cut flag, after physics, but before rendering.

The default is to tick before physics, so you’ll probably want to change your character tick time:

Of course, that means that controls will lag, instead, because tick phase is per-actor. Maybe moving the camera to another actor is the best option there.
Or, perhaps, your portal can have a trigger volume behind it, and in the “on volume overlap” function for the camera, you move the camera and set the cut flag?

[Fibulator]

“On volume overlap” can never be seamless. You’ll always end up teleporting before the camera crosses the threshhold.

I’ve now set it up to teleport during “post physics” tick. I then ran it frame by frame. It “teleports” in one frame, before visibly crossing threshold (as intended)… then another frame after the teleport shows up behind the portal… then the next frame is correct. It’s like it’s adding a frame in the middle for no apparent reason.

Setting the camera to another actor will run into the exact same problem: When to transition.

I’ve tried the teleport during every tick group, with the same results.

[Fibulator]

I’ve added a very small secondary collision box that is attached to the camera which only interacts with the portal teleport “on volume overlap”.
Although not completely seamless, it’s incredibly close.

I still see “Cut this frame” not actually cutting the frame as either a bug, or terribly misleading naming. “disconnected camera movement” or anything else would be far better name… or better still, having a way to remove a frame before it’s rendered would be even better.

Thanks for all your help.

[jwatte]

@Fibulator

I still see “Cut this frame” not actually cutting the frame as either a bug, or terribly misleading naming

Language do be like that. Especially in English, where “cut” is the same in all tenses!
If they added “was” to the name, I think it would indeed be a lot clearer.

[Fibulator]

“cut” wasn’t the misleading part… “Frame” is. No frame is/was actually cut. Cut=removed.

And cut isn’t the same in all tenses. “Will cut”, “cut”, “is cutting”, “was cut”.

[jwatte]

“Frame” is “rendered frame.” Unreal does most of its timing and simulation in frames – it has had a variable frame rate physics engine since forever, for example, to make physics line up to rendered frames. And, in this case, “cut” is “camera cut” (the cinematographic term,) not “scissor cut” (the snipping term.)
It’s an absolutely legitimate interpretation, it’s just 100% ambiguous – both of them are valid!
As they say: two things are hard in computer science: cache invalidation, and naming things…

[Fibulator]

“Camera cut” in cinematographic terms is to “remove frames from a series” So… it’s not valid if no frame is removed.
It’s not ambiguous, it’s flat out wrong.

[maciej-mo-sys (Maciej)]

Fibulator, “Camera cut” is in fact a term that is explained in Wikipedia: Cut (transition) - Wikipedia. Even the name in parentheses seems to explain it.

Naming aside, I was wondering if sudden camera transition can cause a skipped frame in the rendering and if “Set Game Camera Cut” can contribute to it? I am working on a project that it is essential to have a constant time bewtween the command to cut and actual cut happening.