Lock a camera behind character (Ball template)
Hello good people, i was wondering if there is any way to lock a camera behind the character, meaning you can NOT walk towards the camera (like in the thrid person template) ?
I am trying to create a game where you play as a spere racing around, but the camera set-up is really wonky for this as is, so i would like the camera to react to the "forward" motion of the sphere, always giving you a view of whats in front of you.
I have tried multiple ways in the "Ball template", but noone seems to work.
Perhaps its just as wise to start from a first person template and just offset the camera and change the character?
Any input would be appreciated!
asked Jan 22 '19 at 06:33 PM in Blueprint Scripting
Here's my take on how the whole thing would work. It builds upon what Alex O wrote, but also includes Pawn movement and a smoothly interpolated camera. Hopefully you find it useful.
I started with the Roller Ball template and just modified a couple of things within. I guess I kind of went against what we discussed earlier, because I didn't use any assets or scripting snippets from the Third Person template. (I didn't even open that template at all.) So if you're starting from the Roller Ball template, you can follow these steps and arrive at the same result I did.
Once you start up your Roller Ball template, the only asset that needs to be modified is the ball pawn blueprint. The default name for this asset is 'PhysicsBallBP' but I made a duplicate and renamed it 'BP_CustomPhysicsBall'. The name isn't important, but I wanted to clarify in case the name in the screenshot is confusing.
You're going to modify the template's behavior for the ball's left/right and forward/back movement. Here's what my graph looked like after I made the modifications:
Left-right movement nodes:
And now, the forward-back movement nodes:
If you compare those screenshots to the template's original setup, you'll see the primary difference is we're using the camera's current view direction to determine into which directions the ball should roll when A/D and W/S are pressed. Instead of just rolling into the world's fixed X axis (for left/right inputs) and Y axis (for forward/back inputs), as the template does, we're creating vectors that point into the camera's forward and right directions.
That's all there is to getting the ball to move relative to the camera's current orientation, but the result right now won't seem any different than the template default. This is because the camera isn't rotating yet, and the camera's forward and right vectors are (more or less) aligned with the world X and Y axes. So the next step is to implement the camera rotation stuff.
The following screenshot shows how I implemented the camera orientation behavior. You'll have to add all of these nodes in yourself if you're using the Rolling Ball template. Have a look and try setting this up in your project:
I commented a few nodes, so I hope it makes sense without much more explanation. But take special note of that RInterpTo node, which adds some real nice smoothness magic to the camera rotation. Without this interpolation node, the camera would be glued rigidly to the ball's velocity direction. With the node, the camera turns gently, which feels much better. As an added bonus, this interpolation of the rotation negates the need to disable the 'backward' input like I suggested earlier; with this node, moving backwards is not a problem and, in fact, works great for improving control of the ball. Cool!
If you want to adjust the speed of the rotation smoothness, feel free to tune the 'Interp Speed' parameter on that node. Smaller values result in a slower camera turn.
Hopefully this helps you understand how these elements work together, and hopefully it creates the effect you want. Let us know if you have any more questions!
answered Jan 23 '19 at 12:35 AM
This is weird and terrible - but it might help you get started!
Starting from another template is probably the way to go - rolling ball template is kinda wonky to begin with. (No stable forward vector on this pawn is why I needed to base it off of velocity instead of just "what direction are you facing")
answered Jan 22 '19 at 08:41 PM
Alex O ♦♦ STAFF
Follow this question
Once you sign in you will be able to subscribe for any updates here