"What is that meant to do? Is it to stop the camera being behind a wall? If so it'd only work with the EntityPickMode of the level set to something. But surely it's more slow than just using Sphere->Polygon collision, since you could end up doing hundreds of CameraPick()s in one frame. Or am I missing something?"
Hmm... if this is doing what I think it's doing, then this is pretty clever actually.
Just because your camera can collide with the level, doesn't mean that it won't get stuck behind something.
This appears to check if there is anything between the center of the camera view and the player, and if so, it keeps moving the camera forward, and then moves it up or down so that it is exactly 4 units above the player, and then points it at the player again.
Hm... Well, maybe it's not the best solution, but I guess it might move the camera out from behind SOME obstacles. For example, if there was a pillar between the player and the camera, this would push up against the pillar until it slides around it. But if the camera was caught behind a wall, it might not succeed in getting around the wall by moving forward, it might just end up wedging itself into a corner.
But the idea of using camerapick to dtermine if something is between the plauer and the camera is pretty clever.
I think this algorithm could be improved by sampling four points to the left right, top and bottom of the camera and seeing if any of those can see the player, and if so, the camera will move in that direction. However, you don't want the camera to avoid going behind trees completely. So if the camera is moving, then you would want to sample an additional time in the direction of motion to determine if the camera will only be blocked temporarily or not. Or maybe if you know where the destination of the camera will be you could check to see if that is blocked before you move there. Hm...
Making a good camera is a lot of hard work, I don't envy someone trying to implemnet one. :-)
Hmm... if this is doing what I think it's doing, then this is pretty clever actually.
Just because your camera can collide with the level, doesn't mean that it won't get stuck behind something.
This appears to check if there is anything between the center of the camera view and the player, and if so, it keeps moving the camera forward, and then moves it up or down so that it is exactly 4 units above the player, and then points it at the player again.
Hm... Well, maybe it's not the best solution, but I guess it might move the camera out from behind SOME obstacles. For example, if there was a pillar between the player and the camera, this would push up against the pillar until it slides around it. But if the camera was caught behind a wall, it might not succeed in getting around the wall by moving forward, it might just end up wedging itself into a corner.
But the idea of using camerapick to dtermine if something is between the plauer and the camera is pretty clever.
I think this algorithm could be improved by sampling four points to the left right, top and bottom of the camera and seeing if any of those can see the player, and if so, the camera will move in that direction. However, you don't want the camera to avoid going behind trees completely. So if the camera is moving, then you would want to sample an additional time in the direction of motion to determine if the camera will only be blocked temporarily or not. Or maybe if you know where the destination of the camera will be you could check to see if that is blocked before you move there. Hm...
Making a good camera is a lot of hard work, I don't envy someone trying to implemnet one. :-)