Jump to content
  • Advertisement
Sign in to follow this  
Khaos Dragon

character controlling with a physics library

This topic is 5007 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

Has anybody ever attempted to represent the main player character as a physical entity of a physics library in an fps game? I currently am using Novodex, but am just wondering what are the common methods for doing this are and also if anybody has any good ideas. I was thinking of making the player's physical entity a sphere so as to to minimize friction. Every frame I could directly set the new position of the player based on his movement inputs. However since this basically overrides the physics control on the entity I would have to check to make sure it is not colliding with anything and adjust it until it is not colliding each frame.

Share this post

Link to post
Share on other sites
on the ODE mailing list was a post talking about how ODE was used in bloodrayne [2?]

the character was a capsule [like a sphere has no pointy parts, but is somewhat the proportion of the player]

I don't belive the author mentioned how the character was moved though [q12.org and ode.org seem to be down at the moment, I can't find the post]

I personally would set the character's velocity [as opposed to position], and if the physics decides to change it [for example, I run into a wall] I would then change my animation speed and possibly let the game logic know [perhaps to have it play another animation...]

w00t, found the post:
For character movement in BloodRayne 2, we used our own simple
simulation. Rayne's collision was a capsule (or swept sphere) and had
a corresponding "geom" associated with her (but no body). If she hit
anything that was simulated in a frame of movement, she would add a
force/moment to that object. Then her geom's position was updated.

For a stack of boxes, well, this is a little more complicated. Here
is what we did, and it was totally stable 100% of the time...

We wrote our own world collision routine for BR2. We created our own
"sweep-and-prune" collision space using ODE extentions. Then inside
of this routine, we would first collide each geom with a body with the
game world, then each other. Each geom had a custom collision routine
with the world, and then collision points would get reduced. We
mostly used ODE's geom to geom collision, but we reworked the
capsule-box some, and wrote our own cylinder collision.

We then wrote our own auto-disable that would disable an island of
bodies, rather than one individual body. This is subtle, but the
effect was amazing. Dead bodies, box stacks, etc. became totally
stable with this. In one test level, I had 20 boxes stacked one on
top of another. You could run into the stack, it would sway, then
stop. If you hit it hard enough, then it would fall over.

ODE ran at a fixed frame rate of 30fps on PS2 and 60fps on Xbox. This
can help collisions be more predictable and stable. Remember F * t =
m * deltaV. Understand how impluse works in ODE land.

Also, understand what CFM and ERP do for you. Sometimes it is
appropriate to use a large ERP, and sometimes a small one. Then tune
the CFM to get the desired spring effect. If you run at multiple
frame rates, you need multiple ERP/CFM pairs.

I suspect that you need to look carefully at the collision library you
are using and make sure it is returning values that make sense for
what you are colliding with. I highly recommend writing your own geom
to world collision routine.

Mark Randel
Terminal Reality Inc.

Share this post

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

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!