I think I have discovered a HUGE flaw in your teleportation logic. Shouldn’t the final rotation (after teleportation) be rotated 180 degrees? It’s kind of hard to explain with words so I made a crappy picture in Paint to demonstrate what I mean: https://i.imgur.com/UQtjz5z.png
The red direction is what I am getting when I teleport but the orange direction should be the correct direction… right? Something is wrong here…
It should be flipped, yes. BP setup I use is about the same as the one here: A new, community-hosted Unreal Engine Wiki - Announcements and Releases - Unreal Engine Forums
Hmm, on paper I agree with you regarding the rotation. However I don’t think I do it in my own implementation. Maybe because of the way I handle the player camera on my side. I will have to check to be sure.
The only reason I can think you would not have to flip the rotation is if you had a portal pair, one facing “forward” and one “backward” (I was considering implementing like this, or as an actor where you move components around, but think I am happy with the way it has gone)
Is that not what I demonstrated in my drawing (not at the portal normal direction [blue arrow])? Or have I misunderstood what you meant to say?
Ah, I see what you mean. Though from the drawing, I can’t tell if the actor is rotated, or “internally” the portal is rotated.
if every portal actor is identical (locally, both portals portal faces forward) - the players direction should need flipping as well as portal transforming.
If portal actors come in pairs (locally, one faces forward, and one backwards) - the players direction should not need flipping as well as portal transforming.
Okay I figured out why it works fine for me. 
So I added some debug virtualization to verify the behavior of my Character and Controller class :
https://www…fr/blog/wp-content/uploads/2019/03/rotation_debug_optim.gif
The red point is the controller rotation and the green point if the character rotation. As you can see they are aligned even after crossing (if I moved my mouse they wouldn’t be anymore). I locked the framerate at 6 FPS to be sure to see any jump happening in the rotations and I you can see there are none. In my code I don’t do anything special other than what is described in the tutorial.
So the reason is that the target of the Portal is not the other portal actually, it’s a Target Point actor facing the opposite direction. So that’s why I don’t have to apply a 180 degrees rotation after crossing. My portals were never meant to behave exactly as in the game Portal but instead followed more closely Prey. In Prey the portals can be unidirectional, so that’s why I assumed the target point would need to be setup properly and could be any generic actor.
Aha, ok then it makes sense. Quick question, are your portals able to be rotated in any direction and still work (like would they be able to be placed vertically and horizontally or maybe even at a 45 degree angle)? Sometimes I get some funky teleportation behavior when I rotate my portals… like sometimes Ill fly out of them and my entire character gets tilted and in some cases even flies out upside down and lands head first. Does your teleportation logic do any rotation alignment correction like in “Portal” when you exit the portal (like this: https://youtu.be/_SmPR5mvH7w?t=442?))?
I am guessing it doesn’t since I can’t spot anything in the code that indicates that it does but just asking…
Yes, they can be rotated in any direction and they still work (I tried). That’s the whole point behind the ConvertRotationToActorSpace() and ConvertLocationToActorSpace() functions.
I mentioned it in the tutorial, implying you had to take care of that yourself :
If it helps, this is the method I use to set player rotation back to normal
Feels like it is not quite right, but works well - with the exception that it “snaps” too fast if the player is rotated more than 90degrees
Why do you use both the Lerp and Ease node? Don’t these both interpolate (basically doing the same thing twice)? The lerp’s end results aren’t connected to anything so I am guessing that the lerp is just old junk code that you never bothered to delete?
Exactly, lerp is old code no longer connected. Though not sure I prefer ease over lerp.
That aside, it may not be necessary to rotate both the actor and controller - but this seems like a safe option
Looks like the “bGameCameraCutThisFrame” variable from the “APlayerCameraManager” class will be editable via Blueprint in a future version of the Unreal Engine. The Git commit which has been approved can be seen here : https://github.com/EpicGames/UnrealE…ment-497676113 .
Yes, my first PR has been accepted
Must say thanks again @ for pointing out that var exists, and giving me the opportunity to make a nice easy first PR to epic
Been looking into raytraced portals - more difficult than I had hoped, made no real progress in this area. Mostly posting here as I was incorrect when previously suggesting it may not be so hard.
Though with a few engine modifications I have gotten a basic rendertarget setup working in VR, with correct stereo vision and late updates, but still needs some work in various areas (mostly correctly sizing render target, VR screen coords using non-hardcoded IPD, performance and recursion).
That is some great stuff. Is there a way to make it work in stereo VR?
I guess you’d have to capture the scene 2 times but with half X resolution, and apply it on a proper right or left half of the screen UV.
Just a though really.
Yes - to get it working in VR I had to expose a couple of engine functions, and add a hook after the view extension which handles HMD rotation.
Then in my local plugin I read and transform the viewmatrix directly for each eye.
I am currently using two scenecaptures/rendertargets - but it shouldn’t be necessary… the ViewFamily should be able to render in the sameway as regular stereo rendering, but I am missing something. (though, not sure it is too important, I’d like to be able to control the target rects anyhow)
Hope to tidy up and fix a few things - been going down quite a rabbit hole attempting to do more efficient rendering.
I would probably look into an entirely different approach for portals in VR; render targets and scene capture is simply far too expensive to be reasonable.
@ambershee Agreed - though the rendertarget solution does work with VR, and reasonable FPS on a very simple test level, it is rendering lots of useless pixels, and does not lend its-self well to the concept of recursive portals.
Finally been making some progress on a better rendering method this morning:
still not much to look at, but should be running faster than rendertarget method already, and avoids a bunch of issues.
Ending up making more engine modifications than I wanted to, and still quite a bit of work to do…
Whenever I press play it crashes. It seems to crash upon loading the player controller. Is there anypoint to utilize the ScaleVertex nodes if we aren’t using a mesh that can utilize it? Also setting the GeneratePortalTexture as a CanvasRenderTarget2D doesn’t allow it to be attached to a root component or be picked up by the GetPortalTexture function as it says its unable to convert from a UTexture to a UTextureRenderTarget2D. Also Im not sure how to handle the CurrentVelocity function. It’s using the UCharacterMovementComponent class correct?
