So I’m having a hard time finding any info regarding controller rotation and how it exactly works, as well as how its related to movement input…I recently setup 2 camera systems that both move the camera without changing the players forward vector. One is a freelook that I clamped to -110 and 110 degrees view yaw, think of it as turning your head left to right, you can only go so far. The other is a vanity camera that allows you to spin all the way around the character, it essentially detaches the camera from the character, and allows it to spin and pitch around the character with the character as the axis point, without affecting the characters movement at all.
I recently got my hands on some new meshes and animations (Owen). Turns out the way my cameras are setup is backwards for how the mesh responds to my inputs, and since Owens animations are a bit more how I had planned mine I now need to switch my cameras behavior. My vanity camera should be freelook and freelook vanity in terms of operation, but they use different formula for achieving their overall goal so I cant just switch the inputs and call it a day.
So what I want to do is clamp camera rotation yaw when I have use controller rotation yaw set to 0. But, I cant seem to figure out how rotation works though…I am currently watching the camerabooms relative rotation, and it rotates independently of the world plane where 0 for the camera boom is always the players current forward direction. I’m guessing this is because of how we use forward vector for player input?
However when ever I try to clamp the camerabooms relative rotation while yaw is yet to 0 it doesn’t work. All other rotations I can find are dependent on the world and always face the same direction. If we look at the world like a compass north is always 0, e always 90, ect, or its related to the translation of the mesh but never changes. I’m assuming this is world rotation, even though I was getting their relative rotations. However the cameraboom is not restricted to these rotations axis and doesn’t seem to be tied into them in any way either, but I don’t understand why. I have a feeling it has something to do with get forward vector but I’m having a hard time understanding exactly how the movement input even works…
I will upload some pics of the current logic and a video for demonstration tomorrow sleep for now though. Any help would be appreciated. Thanks
OK so as promised here is a video example showing the states in action, and my prints. https://www…com/watch?v=zAPhCFd4Smk&list=UUqM_syxaYlsQIiEK5EvgukA
This sets my current camera state and is fired off event tick. (Set Gameplay Camera State)
This is how I am getting my mouse input. I will probably be deleting pitch. As I think it is unnecessary.
This is the inside of my freelook yaw function from above. And how I am clamping it.
This is my freelook enabler. On disable I am just re-enabling Controller view rotation.
And this is my vanity enabler. On disable I am just re-enabling Controller Yaw.
After reading above I am still not quite sure what you are trying to achieve.
Could you break the problem down into a series of Inputs and desired outputs. Then describe exactly how your actual output deviates from that?
As a general strategy I usually try to attack problems in misbehaving systems by isolation. To use a military term, the tactic is defeat in detail. Break the problem up and verify(defeat) each component without contribution from the rest of the system.
Yea sorry guys, basically at this point I am trying to clamp the cameras yaw rotation. While use controller yaw bool is set to false. I’ve tried several different ways but none have worked yaw always worked as normal and wasn’t affected. At this point I just need a working clamp, I should be able to do the rest.
Unfortunately neither of the options in that thread did the trick. Whats interesting is I went ahead and clamped camera boom. The clamp works, but it doesn’t. It works in the sense that is does clamp the camera booms rotation, if you watch the relative rotation value in debug, it stops increasing/decreasing when it reaches the clamp limit. But the camera itself can move beyond the clamp freely and doesn’t get stopped from rotating, even though the camera booms relative rotation value has stopped changing.
My guess is there is some unseen controller that needs to be clamped or something…I’ve tried all the ones I could find. If it pops up under player, controller, rotation, or yaw search I’ve probably tried clamping/setting/watching it.
So I came up with a second solution of checking when I reach my max allowed rotation and then shutting off the axisinput in that direction of rotation. So you could no longer rotate in that direction. This works, but not completely. While it does stop the rotation after you reach the limit, depending on how fast you move the mouse, before you reach the limit, you can actually shoot past the limit because of the way the axis translates the value into yaw rotation. So while any additional movement of the mouse after the limit has been reached is ignored. Any left over axis value from the mouse movement before the limit was hit, Still ends up getting translated and added onto the rotations value.
Unless there is a way I can ignore any leftover axis value information after I reach my rotation limit then this way would never completely work. Its inconsistent so Its not like I could just ignore it. The higher the sensitivity of the mouse the farther past the limit it would probably go.
I’ve linked a video example of what it is I am trying to accomplish. And the blueprints of the 2 solutions I just posted about in case anyone wants to test them for themselves and see if they could come up with something. In the video if you notice the player can only rotate the head so far before they run into a limit, this is what I am trying to achieve. http://www…com/watch?v=acJQiwnUEC4&list=UUqM_syxaYlsQIiEK5EvgukA
Any other ideas?
If you try the bottom blueprint, you should get a basic idea of what I am trying to do. Top is the cameraboom clamp, bottom is the input shut off. They are 2 different solutions completely independent of each other, and I have tried combining them and got the same issue. They are running off my look left/right axis input.
If I am NOT using controller rotation yaw (Use controller rotation yaw = false). Then what rotation yaw am I using? What has become my new rotation yaw controller? As that is the one that needs to be clamped.
Still have not been able to pull this off correctly, The closest I have gotten is being able to clamp my turn/left right axis value so I no longer receive information from that axis direction when I hit my yaw clamp. Doing this no longer allows left/right input when I have reached my maximum yaw rotation, BUT the remainder of my mouse swipe is still being calculated and added on to my rotation from before the yaw clamp was hit. This is causing me to shoot past my clamp how ever much axis value was left from the initial mouse movement from before the clamp was hit.
For example If say I start at a yaw of 0.0 and rotate my mouse to the left (- Axis Value on the yaw input), slowly until I reach -110.0. I will shoot past it a random amount, up to the tenths depending on how slow I am moving the mouse (ex -110.13489537 or less). At this point I will no longer be able to move to the left (which is correct), all (-) axis value input becomes disregarded because it is clamped at this point, as I hit my trigger point which was -110. How ever if I was to do a large mouse sweep, Think if you were trying to do a 360 in game in a single mouse movement. I will end up at -122 or more, the clamp will kick in like it should but it does not stop me at -110, and how far passed I shoot is entirely dependent on the mouse sweep.
What I want to do is stop camera boom’s relative rotation at -110 (left) and 110(right). Basically a range if I am between those 2 numbers I can move left or right, but the moment I hit either one of those numbers I want the relative rotation to stop dead in that direction and not go past either of those amounts.
My movement input, I am using actor instead of control so I can rotate the camera without effecting the players direction of movement, when I activate freelook.
This is how I am enabling my freelook. Basically just turning off controller roation yaw. Then turning on the freelook boolean, which when activated uses my “clamped” input yaw.
And now my clamp. Which is connected to the long string going off screen connected to my Mouse Input branch with freelook condition in the first screen I posted.
V1, This works just not consistently. My numbers are never clamped correctly, always overshot dependent on the mouse movement.
V2, This clamps the numbers, but doesn’t stop the rotation at all. Its like the clamp isn’t even there.
V3, Does the same thing as V1, It was just a different approach…
Try using v1, but add an additional branch to each one. The first true branch add a branch that checks if yaw>110. If true, set yaw to 110, if false, add yaw input. On the second do the opposite, if yaw is<-110, set yaw to -110, if true, add yaw input. See if that helps.
So I went ahead and tried it out. It works but again only for the numbers. The rotation continues. Here are some screens that will hopefully clarify what is going on. I commented in the screenies as well.
This first screen is using the V1 clamp with your additions. It works in theory as you can see the number is clamped at -110, and the yaw input clamp then kicks in. The rotation itself, however isn’t affected. I moved the mouse as slow as possible to get as close to -110 as possible before my clamp kicked in. Notice the visibility of the structure in the background. The small decimal amount past -110 is the left over mouse axis value from before the clamp kicked in.
As you can see I can still go past -110 if I move the mouse fast enough, which means more axis value left over. Notice the visibility now. This makes the clamp inconsistent, so if someone has a fast sensitivity or does a really large swipe from side to the other this will likely happen. And we dont want that =[
