Our last step before we can test our code is to add our last three functions into the update function. The final step is to set the target position to zero to reset for the next frame’s input. With the horizontal velocity lerping it’s way towards zero, we then add to the transform’s position a value equal to the horizontal velocity multiplied by time delta time. Note rather than using our acceleration to control the rate of the slow down, I’ve used a different variable (damping) to allow separate control. To do this we want to lerp our horizontal velocity (calculated constantly by the previous function) down to zero. ![]() If the player is not trying to get the camera to move we want the camera to smoothly come to a stop. While they might look different these two lines of code are closely related to the Kinematic equations you may have learned in high school physics. We then add to the transform’s position an amount equal to the target position multiplied by the current camera speed and time delta time. We then normalize the resulting vector to keep a uniform length so that the speed will be constant even if multiple keys are pressed (up and right for example). This ensures that the movement is in the horizontal plane and relative to the camera. We’ll take the x component of the input and multiply it by the Camera Right function and add that to the y component of the input multiplied by the Camera Forward function. In order to translate the input into the motion we want we need to be a bit careful. This function polls the Camera Movement action to then set the target position. The next function is the poorly named Get Keyboard Movement function. This ensures we are calculating the velocity for the frame and not from the start. After calculating the velocity we update the value of the last position for the next frame. Nothing too special in the function other than once again squashing the y dimension of the velocity to zero. It feels a bit clumsy, but since I’m not using a rigidbody and I want the camera to smoothly speed up and slow down I need a way to calculate and track the velocity (in the horizontal plane). I'll probably just figure out a way to not have 3D objects in the canvas to begin with.Admittedly I don’t love the next function. Is there a way around this? I saw another thread suggesting the use of render textures or stencils, which is far too complicated a solution in this context. ![]() But this is a non-starter.when you turn a camera into an overlay, you lose the ability to set a viewport rect for it. ![]() I also thought about making a new base camera to hold both old and new cameras. Other URP docs suggest setting the canvas camera to an overlay, but in my situation, none of my base cameras are appropriate, because they are restricted to specific parts of the viewport. I would've expected it to render directly over the existing contents of the screen. ![]() It's as if the camera is rendering to its very own screen-sized render texture, then blitting the whole thing over the screen buffer. When configured as a base camera with output texture set to "None", the canvas camera seems to clobber everything in the screen buffer, even if I set its skybox setting to "Uninitialized". To do the latter, I need to add another camera. On top of this, I'd like to add a canvas that renders 3D objects. I've got multiple base cameras rendering into different parts of the viewport.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |