• Advertisement
Sign in to follow this  

'Physics-applied Entities + Camera' collision

This topic is 3670 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:
fpsCameraObject->Update();
cameraPhysicsFollower->SetPosition( fpsCameraObject->GetPos().x,
      fpsCameraObject->GetPos().y,
      fpsCameraObject->GetPos().z );


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

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
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?



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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement