There are 2 trigger volumes in the area that calls the function “Set View Target with Blend” to go between 2 cameras.
If the camera is in the middle of a transition and the function is called to make the view target go back to its previous camera, the viewport will snap to the previous camera instead of blending to it.
The View Targets Blend does not store camera location and rotation in the process of the blend. You will need to set up a movement logic which allows you to call the camera location and rotation over time. Here is one example setup using 3 camera (1 used as the player’s actual view and 2 used to denote location and rotation values (which I set up in the level to be what I would want the player to see.).
Is there any reason why View Targets Blend does not store camera location and rotation in the process of the blend?
It seems to me that this would really make SetViewTargetWithBlend much more useful as you would be able to “interrupt” the current blend and have it start a new blend with a new view target instead of having to wait for it to finish or get the horrible side effect of the pop.
There is no reason beyond the engineers wanting to keep the function as memory friendly as possible. To store the data you are referring to would require a memory allocation running on a tick that while possible would be not as cost effective for all applications of the base function itself. All that being said it is absolutely possible to achieve it with some code changes.
Thanks for the reply Eric. That makes complete sense.
I was so impressed with how clean and easy it was to use the SetViewTargetWithBlend node in BP’s that now I don’t want to go back to setting the blends up manually.
I just ran into this problem myself, but fortunately just before putting in a manual fix, I tried enabling the ‘Lock Outgoing’ checkbox in the SetViewTargetWithBlend node and this appears to solve the issue and give the desired functionality.