koobas.hobune.stream
Camera following the player in 3D - in object hirarchy or through scripts?
I am currently in the process of making a player controller script. Movement is done and I'm now facing the problem of camera movement.
Previously, I made the camera follow the player by making it a child of a child in the player - the camera pivot and the Camera itself. This let me simply offset the camera without changing the pivot and I didn't have to worry about tracking the player.
But now I'm rewriting the player controller script from scratch (as the old version was poorly written) and seeing some of the disadvantages of that system (more object references, harder-to-implement camera smoothing, etc.), I wondered if making the camera actually track the player would be better.
Though, I don't know the performance impact of using Transform.LookAt(player) and Transform.TransformPosition(offset) every LateUpdate(). Does anyone have more experience with this? I can't really use the profiler, nor can I measure performance impact in any other way that well, so help would be appreciated.
Thanks!
While hierarchy controlled camera is good as a start, as you progress into further development you will always write a script that controls this movement - when through hierarchy the movement is robotic and unnatural, which is undesirable.
Honestly, if you do not know whether or not you should use a script controlled camera or a hierarchy controlled camera, you shouldn't even begin to think about performance, let alone attempt to optimize something that is most likely already running at 1000 FPS on the weakest of devices. Furthermore, if you can't use the Profiler don't even begin to consider optimization, you'll just end up with wrong conclusions. As they say, premature optimization is the root of all evil.
So the answer is yes - you want to control the camera through scripts.
Well, I expect my game to be very performance-heavy, as hundreds (if not thousands) Rigidbodies are gonna be in the scene at one time, most of which will have a few behaviour scripts, but that's beside the point (early optimisation is always the root of all evil).
Thanks!
Well then you optimize that, not something that will have almost no load. What you're trying to do is saving pennies in a bank when you're spending 100$ bills daily, actually. If you think that your performance is going to be shitty because of physics, work on optimizing that, as that will change the performance most drastically. It is unlikely that you could create an optimized game that really sucks on a platform performance-wise, anyways, and any time you have doubts, just think about how magical the fast transform of an inverse root was and how some small changes can be game changing.
