A better third person camera
Author
I'm working on a 3D 3rd person action game and like most games in the genre the scenery can obstruct the view of the player.
I've managed to get around this by doing the following,
Each frame the camera will start at the player
It will attempt to move up and away a certain amount
It will be clipped in to the game world
This works but has two distinct errors,
1) The camera "jumps" if the player walks behind a pillar and then emerged from behind it quickly.
2) In cramped situations the camera can appear very close to the player and therefore obstruct the view of the game.
Anyone got an suggestions for making a better camera..? Anyone done anything like this before..?
Some games make the obstructing world geometry slighty transparent.
I've never liked that method though.
To be honest I don't think there is a solution...
I've never liked that method though.
To be honest I don't think there is a solution...
You could make the player's object transparent when the camera is real close - that helps.
When you walk behind a pillar, I think it's acceptable for the camera to 'snap' close. However, when you walk out, have the camera interpolate it's position so that it slides out to where it wants to be.
When you walk behind a pillar, I think it's acceptable for the camera to 'snap' close. However, when you walk out, have the camera interpolate it's position so that it slides out to where it wants to be.
In relation to problem 1: The easiest way is to flag the offending pillars to be ignored by the camera system. This is a bit of a hack, but does fix the jumping issue. Another possible method is to add a predictive system that detects the occlusion early, and then plans a short camera path to smooth out the motion. This is a ton of work though, and may not be necessary depending on your situation.
In relation to problem 2: In addition to the methods described by the above posters, Brian Hawkins suggests moving (or ignoring) geometry that makes the camera move too closely. As an example, you could remove the wall that is causing the camera to be too close from a room. This allows you to place the camera slightly outside the room but still have a clear view of the action. This won't buy you much room, and can be quite useful depending on the situation. This method is described in his book on Real-Time Cinematography for Games.
I've actually just finished my PhD on this sort of problem and there are MANY different methods for handling this, so if you have any further queries just ask [smile].
In relation to problem 2: In addition to the methods described by the above posters, Brian Hawkins suggests moving (or ignoring) geometry that makes the camera move too closely. As an example, you could remove the wall that is causing the camera to be too close from a room. This allows you to place the camera slightly outside the room but still have a clear view of the action. This won't buy you much room, and can be quite useful depending on the situation. This method is described in his book on Real-Time Cinematography for Games.
I've actually just finished my PhD on this sort of problem and there are MANY different methods for handling this, so if you have any further queries just ask [smile].
Author
I did consider making the walls become transparent. That might be the easiest solution really...
I believe most commercial games actually tell the camera where best to position itself in certain scenes from the way they pan around. Either that or they anticipate the best location to be in.
I could give the transparency thing a go though. Cheers, guys.
I believe most commercial games actually tell the camera where best to position itself in certain scenes from the way they pan around. Either that or they anticipate the best location to be in.
I could give the transparency thing a go though. Cheers, guys.
You need a good fast ray intersect tracing function, where you gives the player position point where the camera is looking at, and the current camera position, the function will return TRUe if an imaginary ray betweent those two points is intersected by any polygon from the world geometry, or false if there is not ray intersect (it is very usefull to have some partitioned geometry scheme in your world like BSP, quadtree, octree, etc for making this rutine really fast).
This is what i am doing in my engine:
1.- Move the player,
2.- Calc the new camera position based in the new player positon.
3.- check if the new camera position is valid (if it is not inside a wall, etc)., if not valid point then do step 5.
4.- test ray intersect from those two points.
5.- if there is a ray intersection or if the camera position is invalid then found a new camera position using some predefined criteria...if you dont found a new valid camera position then you can choose to use the last good valid position.
The trick is how found a valid clear oclusion camera position,
* rotate your camera in spherical way using as center your player position and as radius the distance you normally used to put the camera behind the player, you rotate (in Y axis) the camera tring from 0 to 360 degree for get a new camera position and doing again ray intersect to check if that new point is clear, if not then increment next degree until found a valid position.
* trying whole 360 degree could be too much, so maybe is enough just trying 45 degree increments like 0, 45, 90, 135, 180, 225, 270, 315.
6 - Once you found a new valid camera position with clear view then move the camera interpolating from last valid position to new valid position.
7.- If you have already working a pathfinding algoritm for your non playables characters then you can also consider use that rutine for move the camera to the new found position avoiding any obstacles in between, somtimes it doent look quite righth just moving the camera linearly going trough obstacles.
It works preaty well, it gives the camera engine a way to automatically adjust it selft to a valid position; somtimes the camera shake a litle or looks a litle out of control when the player gets into some very populate occlusion geometry but in those cases it is responsability of the level designer to put manualy fixed cameras in the best position view in that zone and add trigers to the player path to switch to the fixed camera position when walkiing in that zone.
good luck.
tp.
This is what i am doing in my engine:
1.- Move the player,
2.- Calc the new camera position based in the new player positon.
3.- check if the new camera position is valid (if it is not inside a wall, etc)., if not valid point then do step 5.
4.- test ray intersect from those two points.
5.- if there is a ray intersection or if the camera position is invalid then found a new camera position using some predefined criteria...if you dont found a new valid camera position then you can choose to use the last good valid position.
The trick is how found a valid clear oclusion camera position,
* rotate your camera in spherical way using as center your player position and as radius the distance you normally used to put the camera behind the player, you rotate (in Y axis) the camera tring from 0 to 360 degree for get a new camera position and doing again ray intersect to check if that new point is clear, if not then increment next degree until found a valid position.
* trying whole 360 degree could be too much, so maybe is enough just trying 45 degree increments like 0, 45, 90, 135, 180, 225, 270, 315.
6 - Once you found a new valid camera position with clear view then move the camera interpolating from last valid position to new valid position.
7.- If you have already working a pathfinding algoritm for your non playables characters then you can also consider use that rutine for move the camera to the new found position avoiding any obstacles in between, somtimes it doent look quite righth just moving the camera linearly going trough obstacles.
It works preaty well, it gives the camera engine a way to automatically adjust it selft to a valid position; somtimes the camera shake a litle or looks a litle out of control when the player gets into some very populate occlusion geometry but in those cases it is responsability of the level designer to put manualy fixed cameras in the best position view in that zone and add trigers to the player path to switch to the fixed camera position when walkiing in that zone.
good luck.
tp.
How bout going Tomb Raider all over the camera? :D
they simply reversed the camera if the player was close enough to the walls, i.e you'd be looking at the main character instead.
This may or may not work, depending on your game thou...
they simply reversed the camera if the player was close enough to the walls, i.e you'd be looking at the main character instead.
This may or may not work, depending on your game thou...
Author
Cheers for that, Anon.
I was looking at a few PS2 games the other night and noticed how they do it and it sounds a lot like your idea.
I've decided against the transparency thing since it can have poor side effects like revealing the outside of the game world... :|
I was looking at a few PS2 games the other night and noticed how they do it and it sounds a lot like your idea.
I've decided against the transparency thing since it can have poor side effects like revealing the outside of the game world... :|
Unreal TOurnament 2004 handled the camera collisions excellently. I would think the trick lies in how you do collision detectioning, consider small objects like a lamp should not be collided with the camera but something larger should.
So what I am saying is that essentially you need 3 worlds, your character/camera collision world, your ray trace/projectile world and your render world.
That would handle most of the smoothing issues.
So what I am saying is that essentially you need 3 worlds, your character/camera collision world, your ray trace/projectile world and your render world.
That would handle most of the smoothing issues.
Personally I prefer a 100% player controlled camera, Mario 64 style. It annoys me greatly anytime the game starts moving the camera around on me, especially if it moves at a critical moment and causes me to mess up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement