fpsCameraObject->Update();
cameraPhysicsFollower->SetPosition( fpsCameraObject->GetPos().x,
fpsCameraObject->GetPos().y,
fpsCameraObject->GetPos().z );
'Physics-applied Entities + Camera' collision
Author
Alright, I'm not sure how to go about this. I have a test pile of stacked multi-coloured boxes. I have a First Person camera. When the camera moves towards the boxes, I want them to be affected and bounce off.
The physics tool I'm using allows only the physics-entities to react to each other. The camera object is a seperate entity. I thought about making a sphere with the phyics applied that follows the camera. More over... goes to the camera:
Well.... the sphere that collides with other physics-applied entities follows the camera, but it takes forever to actually respond. There also seems to be a draggy effect when I move.
What I need is the camera to 'see' what the current chracter 'sees', but I need that character to collide with other objects as well, instantly without hesistation. Has anyone else had a problem like this? Have I made my problem clear? The tool I'm usinfg for physics isn't the case. I just want to know how you solved the issue. This way, I think I can try those methods out to see if I too can fix the problem.
Thanks in advanced,
~PCN
you're doing this the wrong way imo.
You should have a character with a bounding box, and that character is just a 'normal' physics object. Then you attach a camera to the character, not the other way round.
Character physics isn't straight forward usually. Characters bodies have special cases to allow them to respond fast to inputs. This is usually implemented in the form of constraints and special friction and step-up code. It also depends what physics system you use (simple quake3 stick & slide stuff, or complex rigid body dynamics).
You should have a character with a bounding box, and that character is just a 'normal' physics object. Then you attach a camera to the character, not the other way round.
Character physics isn't straight forward usually. Characters bodies have special cases to allow them to respond fast to inputs. This is usually implemented in the form of constraints and special friction and step-up code. It also depends what physics system you use (simple quake3 stick & slide stuff, or complex rigid body dynamics).
Author
So, I should create a class with the majority of the FPS camera functions, and then maybe get some kind of returning function to get the view?
Something along the lines of that?
Thanks,
~PCN
if(glennKeyPressed("Left") ){characterBody->Rotate(&speed);}if(glennKeyPressed("Up") ){characterBody->Move(&speed);}/*Later on down the road*/cameraObject->GenerateView(characterBody, &viewMatrix);cameraObject->SetView(viewMatrix);Something along the lines of that?
Thanks,
~PCN
Pretty much. That's how FPS games roughly work. To clarify...
1) move the character about,
2) recompute the camera based on an approximation of player's head position,
3) apply some effect to the camera matrix (bobbing, tilting, shaking, zooming),
4) render the world (without rendering the character himself if the camera is attached to him and in 1st person mode),
5) render the 3D gun on the HUD over the world,
6) then render the 2D HUD on top.
You can also transition from 1st person to 3rd person camera view as well. But if you do a 3rd person camera, then you will need to attach it to another 'body', so the camera doesn't go through walls: perform a 'trace' from the character's head position and into the world, to find a safe camera position.
1) move the character about,
2) compute a 'start' position based on an approximation of player's head or torso position,
3) 'trace' the camera into the world towards the back of his head (or whatever relative direction you wish), ignore the character it is attached to during the trace.
4) compute a 'alpha' blending value based on distance from camera 'start' to camera 'end' point, to make the character transparent if the camera is too close.
5) apply some effect to the camera matrix (bobbing, tilting, shaking, zooming),
6) render the world and the character (remember he might be translucent or completely transparent if the camera is too close to him).
7) render the HUD on top.
However, the main problem in games is always with the character motion and controls. That can be a 'difficult' if you use full-on rigid body dynamics, problem but if you use a physics engine such as Bullet, that stuff can be fixed using constraints and custom-tuned friction, restitution and 'glue' code without having to bodge up your code too much.
1) move the character about,
2) recompute the camera based on an approximation of player's head position,
3) apply some effect to the camera matrix (bobbing, tilting, shaking, zooming),
4) render the world (without rendering the character himself if the camera is attached to him and in 1st person mode),
5) render the 3D gun on the HUD over the world,
6) then render the 2D HUD on top.
You can also transition from 1st person to 3rd person camera view as well. But if you do a 3rd person camera, then you will need to attach it to another 'body', so the camera doesn't go through walls: perform a 'trace' from the character's head position and into the world, to find a safe camera position.
1) move the character about,
2) compute a 'start' position based on an approximation of player's head or torso position,
3) 'trace' the camera into the world towards the back of his head (or whatever relative direction you wish), ignore the character it is attached to during the trace.
4) compute a 'alpha' blending value based on distance from camera 'start' to camera 'end' point, to make the character transparent if the camera is too close.
5) apply some effect to the camera matrix (bobbing, tilting, shaking, zooming),
6) render the world and the character (remember he might be translucent or completely transparent if the camera is too close to him).
7) render the HUD on top.
However, the main problem in games is always with the character motion and controls. That can be a 'difficult' if you use full-on rigid body dynamics, problem but if you use a physics engine such as Bullet, that stuff can be fixed using constraints and custom-tuned friction, restitution and 'glue' code without having to bodge up your code too much.
Author
Thanks for the "pocket" guide! I'll use that. However, I'm not using guns in this FPS. I also had the idea of rendering the chartacters body but without the head, so (unlike other FPSs) you can see a majority of the body.
Thanks again!
Thanks again!
no problemo. The problem with rendering part of the character is the clipping effect. The camera Z near plane maybe too far so you'll have part of the character being clipped, or you'll be lookng down the 'throat' and have some horrible artifacts by rendering the model form the inside out. but that can be acceptable.
Sometimes game use a custom animation to render parts of the character in first person (e.g. just the feet, legs and arms).
Sometimes game use a custom animation to render parts of the character in first person (e.g. just the feet, legs and arms).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
