Hello,
I have a Third Person Character BP, with an Over-the-Shoulder setup; I’d like to give the player the ability to switch shoulders. I have a timeline with a lerp to change the socket offset of the camera boom, which works great when my character is not aiming his weapon.
The problem: I wish for the camera to remain centered on the same location when switching shoulders, so players can stay on target; effectively only the camera changes location from the player’s POV. I’ve tried using findLookatRotation, but changing only the camera’s rotation screws with the orbit, and I’ve not found a reliable way to orientate the camera boom along with it.
[Diagram of the Camera’s Original and Final Position.]
Additionally, here’s some video reference of what I’m trying to reproduce.
My solutions are either unprecise and orienting the camera at a relatively close position, don’t work for a gradual shift/rotation, or locks the camera rotation for the duration of the shift/rotation.
Any help, suggestion, specialized node(s), etc. is appreciated.
(Deleted post is identical, simply not a reply)
I think 2 cameras is a good idea, so I’ve set up an additional follow camera, with its own camera boom and socket offset (0, 100, 0 and 0, -150, 0 respectively).
I’m not sure how to use the “set view target with blend” node with these character cameras, as I can’t connect them as the target nodes. The online documentation I found only show blending to static cameras.
I’ve figured out how to make it into an actor and child of the CharBP.
I have a couple issues and also questions:
Issue 1: I can’t rotate the camera and the camera rotates with the CharBP.
Issue 2: I can’t seem to place my springarm inside the CharBP capsule, I think it collides with it otherwise and turns into a poor man’s 1st person.
Question: Should I set up my first camera as a child actor too? What about additional cameras?
It’s alright, even if it doesn’t solve my issue I’ve learnt more about cameras, so this is bound to be useful later on.
Yes, I think I should find a way to move both the Camera and the Swing Arm. I’ve tried making functions which set the control rotation to face a location relative to the Socket Offset, but that solution is actually the same exact problem with one extra unnecessary step.
Thank you for your help. ^^
I make everything harder for myself, because rather than having the left offset be the mirrored right offset, it’s different, but that’s by design; long story short I’m making 4 offset depending on shoulder and the dominant hand:
RR: 100
LL: -100
RL: -150
LR: 150
Another problem I find with simply mirroring the rotation, is that it tends to not be the exact same spot; if I can have the camera keep the exact same location I’d prefer that, so I do think “look at rotation” will be part of the equation because it’s to my knowledge the most appropriate for that.
(They should add a feature/function for cameras Swing Arms to adjust automatically to the camera’s desired rotation)
Hey, no problems; I don’t see a “results required” sign anywhere ^^
Beside, as I’ve said, I learnt stuff about cameras, so that’s always a plus.
Thank you for your help and time!
I stumbled upon that thread a couple weeks ago, and assuming I’m using it correctly, it didn’t as it screws with the Camera’s orbit around the Spring Arm.
Here’s the test function I used:
TestCamera is a secondary camera, with its own ArmSpring and socket offset.
The trace is made from the camera manager (+ (Forward Vector x 50000))
The result: (Trace from both cameras, execute function, Trace again, then switch cameras)
I think the issue is modifying the rotation of the camera without adjusting the rotation of the swing arm with it.
The inverse transform rotation node might be part of the final equation, on the other hand.
I’ve experimented some more with the 2 cameras idea, but I’ve hit a wall trying to orientate the second camera and its spring arm. If I can reliably rotate them both to face the direction I wish, then I could then add onto it a camera switch/lerp.
Something else I’ll use as a stop gap measure is a fonction which I find too complex for my taste, which is to calculate 2 square triangles:
Triangle 1:
Side a: (c² - b²)
Side b: Socket offset (100 in this case)
Side c: Swing Arm to Target Location
Triangle 2:
Same calculations, but offset is (abs) -150 (so 150)
Knowing those values, I can substract both Beta Angles (angle opposite side of b side) from 180 to know the rotation to add to the control rotation.
This works well when the switch is instant, but the pitch needs some adjustement.
Unfortunately when I tried it it didn’t do well with timelines, but I’ll try again, maybe it can be fixed.
It’s a bit funny having to use trigonometry to just keep a camera looking at a point when using spring arms. Should I e-mail the Epic Dev Team to ask them?
Something that could be useful which I’ve found out:
These 2 angles are identical, and it seems to be reproduced on other distances from camera to hit location.
If it is in fact consistent, it could be used to quickly find the correct angle for the other camera/control rotation.
Red square is current camera location
Black & white is player location
Blue is hit location of the camera + forward trace
Middle Green is final location of the Camera with final spring arm rotation.
I managed to do it with a timeline and the two traces usually done for crosshairs (one from camera to camera forward, one from weapon to end of the first trace).
Then it’s just a matter of moving the camera using the timeline, and at the same time setting the control rotation to be the rotation from the camera to the result of the trace.
During the transition you shouldn’t perform the trace, or if you do for other purposes, make sure you save the last target before the transition started, and use that to calculate the rotation.
I think the hard part is not making it work, but actually making sure that the design is correct, because the camera could potentially rotate a lot based on how far the thing you’re pointing at is from you. So you will have to think about potentially having a minimum range to allow this camera rotation, otherwise you will have some very jarring transitions
Woah, I didn’t expect this much; I’ll test your project out tomorrow morning to make sure. Thank you.
I’ll definitely have a minimum and maximum distance, during my testing a few weeks back I had problems with close ranges not working properly, plus it’s really jarring for how much the view rotates at close range when I had it working.
I’ve tested your project with different arm length for the swing arm, as well as different socket offsets and it works like a charm so far.
I’m gonna try and modify the set control rotation to add to the control rotation, rather than just set it; I had the exact same issue in an earlier test and it results in the player being unable to rotate their view while switching shoulder.
In short: Thank you. It works well, I’ll try and perfect it.
The two main problems I’m trying to fix with the current blueprint are:
Unable to move the camera while the switch is in progress. (Reason: Sets the control rotation to face the Target, which overrides the player’s input on the control rotation.)
Inconsistent Target
By simply going back and forth after the timeline has finished, I’ve noticed that the camera was not looking at the exact same point everytime, which should not happen. Additionally, it seems that at the end of the timeline, the camera moves away from the target point, which adds the significant distance away from where it’s looking.
Any idea what causes this?
I’m experimenting with a component, to have an semi-independent reference point for the camera to look at, which I haven’t been able to work, despite setting location and rotation as absolute.
Here’s a video showing the strange discrepancy. The result is the same wheter I ask the control rotation to be the camera’s lookat to the target or this component I mentioned.
I suspect is has something to do with the socket offset or the timeline, since setting the camera rotation rather than the control rotation yields the same result.
I’ll keep looking, any suggestion, idea, fix, etc. is appreciated.
