Hello, I’m experimenting with the Gameplay Camera System and I wonder how can I achieve camera angle limiting and what is the intended way to Handle Input using this system.
Current Setup : I have a simple First Person Camera Rig using BoomArm with small X offset. Gameplay Camera Component is Attached in PlayerCharacter Blueprint to the Mesh. The Player Camera rotation is Handled in C++ PlayerCharacter using EnhancedInputComponent and passing values to AddControllerYawInput and AddControllerPitchInput. This works fine most of the time but there are cases in which I want to limit the Camera Rotation
[Image Removed]
Desired Effect : I have a case like if I’m hanging let say from the ledge in FPP, I dont wan’t the player to be able to look back , only to the sides. The Angle should be limited relative to the forward vector of the ledge that he is currently hanging on.
What I manage to achieve : I achieved the Angle clamping using the InputAxis Binding 2D ( using this I had to disable mouse look input in C++ and let this node AxisActions take over), but the clamping is relative to world forward and I would like to pass custom vector. There is CustomVariable parameter, I tried to experiment with it but seems like it has no effect. (When I use Auto Rotate Input 2D node there is a Direction Vector which works good, but still the ClampX values from InputAxis are world space)
[Image Removed]
Questions :
- Is there a built in way to solve this or I should dig into nodes and make some custom node/expose some values like clampX and manually pass in Min and Max Value relative to diresired vector?)
- How Should mouse look input be handled. Is it correct way that I’m disabling the AddControllerYaw and Pithc in C++ when Im using the InputAxis Binding node? (When I had the c++ handling enabled, those two were fighting with each other and causing look jitters)
[Attachment Removed]
Hi there! Thanks for checking out the Gameplay Cameras plugin.
> what is the intended way to Handle Input using this system.
That is the heart of the question, actually 
I’m still figuring it out during the “experimental” phase of the plugin, but as far as I can tell there are two ways to approach a camera rig’s input:
- Leave it up to the Player Controller and the rest. This is effectively what you did first, where the Boom Arm uses the Control Rotation of the Player Controller. In this case, the camera system is just a consumer, and so you need to do all the input processing and clamping yourself in Enhanced Input or Blueprints or C++ or whatever.
- Make the camera rig do its own processing by using some input nodes. This is your second attempt, with the Input Axis Binding 2D node there.
So what you did is all correct -- the only piece you were missing is one that is simple but that I only implemented very recently: additive rotation mode on the Boom Arm node (see this commit). With it, you can pre-position the camera pose in the desired “central” line of sight, and then run the Boom Arm additively from that orientation, with an input node that has clamping on it. So effectively, instead of the Boom Arm rotating from absolute north/horizontal, it rotates from that chosen orientation, and then you can clamp it to, like, 20 degrees or something. Sadly, I think I added that additive rotation mode after the cut-off for 5.7, so it’s only going to ship with the next release. In the meantime, you’d have to either make a custom node (in C++) to emulate that logic, or fall back to option 1 and handle it ahead of the camera system.
About your other questions, there is indeed some problems that can arise from mixing Control Rotation and “owned input” in camera rigs. The problem often arises if the camera system also wants to *set* the Control Rotation to the computed camera orientation (which makes camera-relative movement work, albeit one-frame-late). You’d have to make sure “SetControlRotationWhenViewTarget” isn’t set, I think. But generally speaking, yeah you should be able to use nodes like Input Axis Binding 2D even if you’re still doing all the AddControllYaw stuff. That’s because in that case, the Boom Arm doesn’t care about the Control Rotation -- it just uses the rotation provided by the input node. But there may be some other problems if two things (the input node and the Player Controller) try to read and consume from the same Enhanced Input, I’d have to check on that.
[Attachment Removed]
> for some reason the link to that commit doesnt work for me, I have 404 error
Yeah that happens if you’re not logged into GitHub, and/or if your account isn’t registered with the Epic Games organization on GitHub. If you go to the main page on GitHub you’ll see a link to a page with instructions about it. It’s pretty straightforward.
> it would be nice if the InputAxisBinding2D Node had clamping properties exposed
Yes good point! I’ll add it to the TODO list.
[Attachment Removed]
I tried the Additive Rotation Property and It doesn’t work well for me (It spins around like its accumulating rotation) , not sure maybe its because of my setup, but the c++ files are the same as the one in commit. In the video you will see me tweaking different setup and testing. (Once Enemy grab you, then the Camear Rig changes to the one in editor)
- We just use Basic Boom Arm, no input slot so it will just stay at the direction we looked at when enemy grabbed us.
- Then I plug in InputAxisBinding which allows us to look around with Y clamping
- I plugged AutoRotateInput with Direction to Enemy which will just rotate to Enemy with the Clamping Before
- I added X Clamping to Input Axis node but its in World Space, Auto Rotate will still try rotate to enemy but will be clamped
- I enabled Additive Rotation in BoomARm and it starts to spin around
- I disconnected Input node and still it spins around.
Maybe Im missing the
>With it, you can pre-position the camera pose in the desired “central” line of sight,
Because right now I just calculat that desired vector and pass it in as Parameter to Camera Rig.
Do I need to set the control rotation from c++ to that direction on tick before and then run the Camera Rig on Top?
[Attachment Removed]
Hi! Sorry for the delays, and thanks for the video.
If you think it’s maybe accumulating additive rotations every frame, it may be caused by having enabled “Set Control Rotation When View Target”, and maybe also something to make the pawn face the Control Rotation.
These settings can sadly easily create a feedback loop: the pawn faces an orientation, you push the gamepad stick to turn to the left, this turns the camera to the left but then also turns the pawn to the left so now the camera turns to the left even more, and the pawn turns to the left even more again, and so on.
> Because right now I just calculat that desired vector and pass it in as Parameter to Camera Rig.
Which vector do you calculate here? The vector for the “base” camera orientation (i.e. the orientation from which you can look around +/-20 degrees) or the “current” vector based on the player looking around?
[Attachment Removed]
I pass in the orientation from which you can look around +/- 20 degrees, so its basically a direction vector from Player to the Enemy.
I tried disabling the SetControl Rotation When View target and indeed its stops player camera spinning around, but it twist my camera by 90 degrees in the X direction, making it vertical.
but luckily I manage to solve my case by adding the SetRotation Node in Camera Rig and use that before the InputAxis Binding node and Boom Arm with Additive Rotation.
Then the clamp is in the camera Local Space.
The Auto Rotate Input 2D I pass in just forward vector because its also in local space when SetRotation is used. I also didnt have to disable the SetControl Rotation in this case
[Image Removed]
[Attachment Removed]
I don’t know why you’d get a 90 degrees extra rotation on the X axis… but glad to hear you solved your problem.
The relationship between player input, control-rotation, and camera logic is pretty tricky and I haven’t focused too much on that yet, sadly.
So we can close this ticket?
[Attachment Removed]
Glad to help! I can close it from here… Have fun!
[Attachment Removed]
Thank you! This answers my question, but for some reason the link to that commit doesnt work for me, I have 404 error
[Image Removed]Also one suggestion. it would be nice if the InputAxisBinding2D Node had clamping properties exposed, so we could create something like ClampedViewRig camera and pass in those clamp parameters alongside that desired central line of sight you mentioned
It would be useful since different modes could easily reuse the same rig with passing different parameters, like Hang , Climb , Vault would have different clamps
[Attachment Removed]
The Github works now, thank you 
Now I will experiment with the BoomCamera change that you sent and come back to you if it works
[Attachment Removed]
Yes, Thank you for help
Can I close it or you have to do it? Its my first post here
[Attachment Removed]