In your example code, if cameraSlerpPositionSpeed is 1 and your game runs at 50 FPS, you’ll generally move the camera 2% closer to its target each frame. If cameraSlerpPositionSpeed is 40, you’ll move it 80% closer each frame.
Now, you can call lerps with a fixed value to create a sort of “easing” effect. If your object moves 50% closer each frame, it will start out moving very quickly, and will slow down as it nears its target… but it won’t necessarily ever reach that target.
Your variable naming and function params give me a feeling that you’re not trying to do that, though.
If you expect a rate like “camera moves X meters per frame” or “camera rotates Y degrees per frame”, you either need to set up your lerp calls with a timer, or use helper functions like Vector3.MoveTowards and Quaternion.RotateTowards:
perfectly valid; it does use some computational expensive methods but unless there is a whole lot of objects using these methods then you should be good Always a plus when programmers are thinking about performance though!
That’s perfectly fine for as far as I know, just be careful with using .transform in Updates.
You probably know GetComponent() is heavier on the system than things with variables, right?
Well, .transform is also actually a GetComponent() in disguise.
So you should consider storing the transform in a variable and then using that.
Which ends up in:
So yea, for as far as I know it’s pretty valid. However I’d be englightened if told otherwise by a more experienced Unity Programmer, so I’m only 90% sure
Also, I’ve surely seen algorithmic structures that go far far far beyond this and still work out perfectly fine, so you should be fine either way
If you like my answer enough, you can accept it, I’d appreciate it