Design Questions w/r/t 3rd person camera, character movement

simdevode

26-09-2006 19:52:20

I've been looking at multiple examples discussed in the forum, but somehow I'm unable to make any of it work rightly. Here's the context for the game:

The scenario is mainly characters walking around in an office, and interacting through speech files. We designed the characters and the office in 3DS. Now we are trying to add physics.

So for every object in the office such as the floor ceiling, tables etc., we created convex hull collision objects. This seemed to mostly work though further testing can only happen after we get the characters to work.

For the characters, we assumed that since we only need it to walk on a straight plane, a box would do the trick. We have a walk animation from 3ds thats already added to the character, so as long as we could just make it move, it should suffice.


Here are a few questions I was hoping if you guys could help me out with:

[#1] Are our assumptions okay w/r/t to the types of primitives we are choosing -- box for the characters and convexhull for the furniture, ceiling and floor.

[#2] Should the size of the box be the same as the bounds of the node's AAB?

[#3] Do we need to create a joint and attach the character bodies to the floor?

[#4] Is there a way to see the physics body visible during game play for debugging?

[#5] Finally, to make the characters move, do we simply add velocity and force to the center of the box?


Thanks guys!

agoratim

26-09-2006 23:43:37

I'll see if I can get you started on a few of them...

1.) I'd suggest representing your characters with ellipsoids rather than boxes. Alternatively use an ellipsoid or sphere for the base of the character and have this contact the ground and stick a box on top if you think it's necessary. Boxes don't tend to slide that well and you'll find yourself picking up a lot of extra torque that you won't have the ellipsoids and spheres.

2.) This seems like a reasonable thing to do but it probably depends on what your trying to accomplish.

3.) In my system I don't do this and I'm not entirely sure what the advantage would be. Generally a joint is only necessary if you want to tie one body to another in some way. Since your characters are going to be constantly moving around on the floor this seems unnecessary.

4.) Yup, check out Debugger::showLines in OgreNewt_Debugger.cpp

5.) Fundamentally yes, all your movement should be the result of applying forces to the body but I think you'll find good character movement requires more than this. You may need to apply correcting forces to keep your characters on the right track. Materials settings and the processing of contacts have a lot to do with this so check out the materials system and the contact callbacks. One thing to keep in mind is that all your applications of force must take place within the callbacks provided by OgreNewt. Have a look at setCustomTransformCallback and setCustomForceAndTorqueCallback.

Good luck!

simdevode

28-09-2006 19:56:30

Thanks agoratim, that was extremely helpful. I've been successful in implementing most of it, though still struggling a bit with chcracter movement.

I am using an ellipsoid to represent my characters, and applying forces in the respective callback methods. However, I can't seem to stop the character when the key's released. I've set friction to 0, and obviously this then becomes like walking on ice. I assume that now I would have to apply an opposing force on key release to stop the character appropriately?

The other problem is of the character spinning while walking. I have an ellipsoid sized at 20, 35, 10 and I'm applying force at 10, 17.5, 5 -- the center of mass. I don't understand why would the character spin.

walaber

28-09-2006 21:13:13

you should be applying a force at (0,0,0). just call addForce() and it will be applied on the center of mass of the ellipsoid.

as for stopping, yes. you need to detect that the player is "not moving" (the movement keys are not pressed), and apply a force in the opposite direction of movement to stop the body.

simdevode

29-09-2006 00:04:06

Thanks walaber!

That helped, I also had to tweak elasticity and inertia a bit, but it works. Though I'm still stuck with the rotation, and sort of confused about the custom callback methods.

#1 How do I make the character turn left or right? I tried adding torque but it didn't work.

#2 I'm setting the setVelocity in the Listener class inside the frameStarted method, and that's moving the character appropriately. So, what is addForce() in the callback method really for?

#3 If everything has to be inside the callback method, and since my key events are generated outside the callback method, how do I apply custom forces and torques to different key presses? I'm missing something here.


// This is in the frameStarted method in the FrameListener Class
if (mInputDevice->isKeyDown(Ogre::KC_UP))
{
sApp->playerBody->setVelocity(Vector3(0, 0, 50));
}

// This is my callback method in another class
void SimVBSEApp::forceCallBack(OgreNewt::Body* pBody)
{

pBody->addForce(Vector3(0, 0, 0));

}


As above, on UP key, I'm moving my character through Z axis. However this is not really what I want. The idea is to make the character move forward based on his orientation then.

Any suggestions?

Badguy

30-09-2006 02:49:36

Hey I can maybe help a bit.

1.) Torque will work but as the header states, only in the forcecallback.

2.) setVelocity is a hack when used such, the physic engine should have better control over how you transform physical objects.

3.) I personally build a move mask in the key processor.
then simply utilize that mask in the force callback system.

correct me if I am wrong, addForce is expecting world coordinates, not local coordinates.

you can either transform your force vector, or use the addLocalForce method.

nikhil

21-03-2007 04:29:31

Hey I can maybe help a bit.

correct me if I am wrong, addForce is expecting world coordinates, not local coordinates.

you can either transform your force vector, or use the addLocalForce method.


Add Force is in Local coordinates with global axis.. hope it makes sense.. E.g adding gravity.. always (0,-9.8,0).. no adding the player position.. although it might be global the way addForce internally works..