in a fps type game, whats the best way to deal with 3rd person view camera vs intervening walls in interior scenes?

the camera can zoom in and out (a la oblivion). it already handles ground collisions: while camera below ground, reduce zoom. the zoom center point is the middle of the player's model, so this is guaranteed to work, although it many require reducing zoom to 2-3 feet behind the model, depending on camera direction. when looking up in 3ps view with the camera zoomed way back, the normal camera location is usually below ground.

it doesn't do anything about intervening trees and such in exterior views. i've seen titles where intervening trees and such faded out, but i doubt i have the clock cycles to spare for such "eye candy" effects. simply culling is one thing, but fades are a performance hit. any thoughts on this issue?

for interior, i'm thinking something like: while camera outside room, reduce zoom. all interiors except caverns are one-room structures, so this should work fine for those.

caverns are multi-room with intervening walls. there i suppose i'd start the camera at minimum zoom, then zoom out until i got to the current zoom distance or hit a wall, which ever came first.

but i've noticed this can lead to somewhat odd camera angles in Oblivion when you're in combat in 3rd person view with your back against a wall. its almost like first person view, but a little bit from above and behind, almost like a disembodied spirit. the fact that your avatar disappears at such close ranges doesn't help either. the result is 3 bad guys hacking away at an invisible player trapped in a corner. kind of hard to aim in 3rd person view when you can't see your own guy!

Right now it does nothing, its up to the player to manually zoom the chase cam close enough to see whats going on in a room - or a dense outdoor scene like woods.

thoughts, suggestions, how have you dealt with this in the past?

also, 3rd person view in general gives an unrealistic advantage in situational awareness. so i'm thinking that doing stuff like culling intervening trees may have a negative effect on that challenging aspect of the game. limited situational awareness is one of the challenges of fps view. if that challenging aspect of the game is removed or compromised to too great a degree, the game may become too easy in 3rd person view. this is why 3rd person point of view flight sims tend to be "arcade", "action" or "casual", while first person point of view flight sims tend to be "hardcore", or "realistic".

OTOH, while the game supports 3rd person view, you must still aim up and down like in first person view. not so easy with no laser target designator strapped onto your primitive bow or wood throwing javelin! <g>.

still haven't figured out what to do about that. it may be that making 3rd person playable will make it too easy and unrealistic. maybe it shouldn't be supported ?

thoughts? comments? suggestions?

It's a very difficult problem to solve well, and big games can easily invest many man months on a solution.

However, a reasonable starting point that is fairly easy to implement is to either:

- Use your physics system to move a small box from your character's head position (or whatever you're using as your pivot) back to the max distance position. When you hit something, stop.

- Use your line of sight system to fire off a collection of rays. A central one that's from your character's head position back to the max distance position, plus a number of extra ones at various angle offsets. Find the lowest distance.

Both will produce similar results, choose according to which is easiest within your engine. You can then quickly interpolate the distance you acquired from the character's head position to avoid sudden jumps (note that this is different from interpolating the camera position, because that would make it lag when you're running around).

As for your worries about the player gaining a tactical advantage from using 3rd person, if your game is a multiplayer competitive fps, then I would not allow them to choose between 3rd person and 1st person mode. I would only let them do it when spectating, or tie it to your weapon (maybe melee weapons are 3rd person, guns 1st person). I just think it'd be too hard to balance otherwise.

Here's another simple idea to try ... move your 3rd person camera as normal, allowing user input to control yaw, pitch and zoom. At the end of the frame (before rendering) use your physics system to cast a ray from the camera's position to the camera's eye and if there is a collision, then adjust the camera's position to a little bit in front of the collision (use a point on plane to figure out which way to push the camera position to be in front of the collision hitpoint),

- Use your physics system to move a small box from your character's head position (or whatever you're using as your pivot) back to the max distance position. When you hit something, stop.
- Use your line of sight system to fire off a collection of rays. A central one that's from your character's head position back to the max distance position, plus a number of extra ones at various angle offsets. Find the lowest distance.

these are both variations on "start at pivot point, move back until just before obstacle", the algo i described for caverns.

As for your worries about the player gaining a tactical advantage from using 3rd person, if your game is a multiplayer competitive fps, then I would not allow them to choose between 3rd person and 1st person mode.

single player only. between scene complexity and simulation depth and accuracy i can barely do single player. simulation accuracy precludes slow networked play entirely.

At the end of the frame (before rendering) use your physics system to cast a ray from the camera's position to the camera's eye and if there is a collision, then adjust the camera's position to a little bit in front of the collision (use a point on plane to figure out which way to push the camera position to be in front of the collision hitpoint),

in the case of multiple intervening walls, a "front to back" search - from pivot point back to camera - will be faster than a back to front search - from camera towards pivot point. front to back you're done as soon as you hit the first wall. back to front, you have to go all the way to the camera, noting the last wall hit as you go.

now what about when your back is against a wall?

and what can i do about aiming missiles up and down in 3rd person view?

i'm thinking i won't worry about trees in outdoor scenes and such. having them fade, etc interferes with suspension of disbelief. and 3rd person view is already bad enough in that respect. when was the last time you astrally projected yourself and could look down on your own body? for me the last time was probably the morning of day 3 with no sleep walking down the hall in the comp sci building at VA tech, going to email the source code for the group compiler project due on monday to my teammate at OSU, as i was at VA tech visiting my girlfriend. i had coded non-stop for 48 hours to complete the project. by the morning of day 3,i was so light headed, i felt like i was in a 3ps game, just watching myself go though the motions.

in the case of multiple intervening walls, a "front to back" search - from pivot point back to camera - will be faster than a back to front search - from camera towards pivot point. front to back you're done as soon as you hit the first wall. back to front, you have to go all the way to the camera, noting the last wall hit as you go.



now what about when your back is against a wall?

So if you implement the ray-casting collision yourself you might be concerned about back-to-front/front-to-back etc, however most physics engines will use some sort of BVH or space partitioning to perform the ray check.

If your back is against the wall, then the algorithm I described will truncate the camera position to be very close to the "focus" point. In that case, you could override the camera positioning and zoom into a "first person" view.

however most physics engines will use some sort of BVH or space partitioning to perform the ray check.

this puppy's all custom rolled engine. caverns at the moment are simply wall meshes specified on a "level" map. a square on the map can be open or wall. drawing simply cycles through map squares in a given bbox radius around the camera, culling and drawing wall meshes. no partitioning. i'l probably end up going with walls that are one face of a "rocky cube" as opposed to a whole "rocky cube" to reduce the number of backfacing tri's in a mesh that makes it through frustum cull. but the scenes won't be that complex, so i doubt i'll have to resort to advanced space partitioning algos.

If your back is against the wall, then the algorithm I described will truncate the camera position to be very close to the "focus" point. In that case, you could override the camera positioning and zoom into a "first person" view.

sounds like proper selection of the pivot point is critical to getting the correct effect. perhaps that point should be the head, not the midriff, as is common.

i tend to agree that resorting to first person at very close distances seems to be the best option.

that's how i usually get out of such scrapes in Oblivion! <g>. too bad it doesn't do it automatically. kinda hard to press w or s (fwd/back), a or d (left/right), left click or right click or tab (attack, block, or change wpn), e (jump), AND r (toggle camera) all at once!. <g>. but that's what it usually takes to get out alive.

i personally only play first person view games. its rare i'll play a 3rd person view game. but recently i've taken to trying 3rd person more, just to familiarize myself with the issues, as i plan to include it in this version of Caveman. i have freinds who swear by 3rd person the way i swear by first person. so i see no reason to leave them out, if adding 3rd person doesn't make it way too easy. and i suspect it won't.

the game is inherently difficult. so hard that permadeath is out of the question, and autosave is a required feature. its one of those games where you save after every little achievement, cause you can die at any moment. no hiding behind cover while your health bar regenerates from dead to full in 5 seconds, none of that BS. healing takes a REALISTIC amount of time! thats right! six frickin' WEEKS of game time to recover from near death! and NO PLACE to hide! unless you happen upon an area that has been temporarily hunted out, but even then there's bushwhackers, slavers, etc to ruin your day. difficulty settings actually adjust healing rate (among other things).

The whole game runs on random encounters. the only things resembling a hard coded encounter such as an entity on a level in a shooter are encounters with occupants of caves, rock shelters, and huts, and with hostile animals or cavemen guarding quest treasure. and there, the only resemblance is the fact that there is a feature on the map that indicates an encounter might or will occur here. but what you encounter is still randomly generated. its not just a "hard coded type 1 grunt at x,z every time you play" kind of thing.

needless to say, load and save are optimized. ~87 meg serialized in about 3 seconds flat. a save game is bigger than the whole game zipped (80 meg) ! a save game is basically a core dump of the entire game state.

so, how do they handle up/down targeting in 3rd person view shooters? cast a ray and display the name of the intersected object, like in oblivion?

"ok, move my mouse around a bit more.. there! got the bad guy high-lighted! oh wait, he moved! damn! my trigger finger is getting tired from holding this arrow!"

it just seems so HARD compared to first person... i have enough problems with friendly fire in first person combat as it is during a thick firefight melee.

"Oh, my rear was pushing against this concrete wall, that explains it! Glad I turned 180 degrees to understand this."

good point!

3rd person view helps make up for lack of other situational cues such as tactile response (feeling a wall at your back). guess it'll have to do until we all have holodecks! <g>.

wow! can you imagine how cool (and probably how much work!) game development will be when every user has a holodeck? <g>.

me personally though, i'm more into the game than the graphics side, so i'm still waiting for a cray on every user's desk so i can simulate everything at a gazillion-x accelerated time. like all of the ~5 million population of npc's in Caveman. right now, it obviosuly can't model 5 million npc's. so it generates them on the fly and tracks them as needed. but all the frequency distributions for number, type, and location of caveman encounters are set to reproduce the effects of running around in a world with 5 million npc's.

looks like i'll test for walls from the camera back for caverns, and test for "is in room" from back to camera for single room structures, or alternately, "not is in room" from the camera back - might be faster - and its the same algo as for caverns. one algo to rule them all!. just test from camera back until you hit something.

and switch to first person view if the 3rd person camera gets too close to the head, and make the 3rd person view pivot on the head.

still not sure what to do about aiming up and down in 3rd person though.....