|
|
Re: PH_CHAR
[Re: 3run]
#397403
03/18/12 20:15
03/18/12 20:15
|
Joined: Oct 2004
Posts: 900
Lgh
rojart
User
|
User
Joined: Oct 2004
Posts: 900
Lgh
|
Any ideas, guys, or should I ask directly in "Ask the Developers" forum? From physX sdk documentation you should read the friction trouble (orange color), maybe it helps. Character ControllerThe goal of the character controller SDK is to provide a default built on top of the NVIDIA PhysX SDK. Roughly it has to support the following:
Character control
Character interactions
This covers a very high number of features, which can be implemented in numerous ways. The goal is not to implement all of them (which would be a daunting task), but to offer a default implementation that people can use as a starting point. For example, the character's bounding volume could be anything, from a box to an inverted pyramid; therefore, in our initial implementation we support two common bounding volumes: an AABB and a capsule.
One might wonder why we didn't use the physics engine directly to implement the character controller. Here is the story.
Implementation Decisions
In the past, games didn't use "real" physics engines. However, they still used a character controller to move a player in a level. These games, such as Quake or even Doom, had a dedicated, customized piece of code to implement collision detection and response, which was often the only piece of physics in the whole game. It actually had little physics, but a lot of carefully tweaked values to provide a good feeling while controlling the player. The particular behavior it implemented is often called the " collide and slide" algorithm, and it has been tweaked for more than a decade. The result is that players expect to find the same well-known behavior in new games, and providing them with anything else is often dangerous (a few games come to mind but I’m not sure it’s appropriate to name them). This is especially true if provided behavior is not as robust and stable as before, which is exactly what happens if you use a typical physics engine directly to control players.
In particular, here is a (non-exhaustive) list of typical problems when using a physics engine for character controllers:
(Lack Of) Continuous Collision Detection: Typical physics engines use discrete collision checks, leading to the famous tunneling effect that has plagued various commercial & non-commercial physics packages for years, which leads to three main problems:
The tunneling effect itself - if the character goes too fast, it might tunnel through a wall.
As a consequence, the maximum velocity of the character might be limited (hence also limiting the game-play possibilities).
Even without tunnel, the character might jitter when pushed forward in a corner. For example, the engine keeps moving it back and forth to slightly different positions.
No Direct Control: A rigid body is typically controlled with impulses or forces. It is nearly impossible to move it directly to its final position until you have converted the delta position vector to impulses or forces and applied them in hopes that the character will be where you wanted it to be as a result. Usually it doesn't work very well, in particular when the physics engine uses an imperfect linear solver.
Trouble with Friction: When the character is standing on a ramp, you don't want it to slide. Infinite friction is desired. When the character is moving forward on that same ramp, or sliding against a wall, you don't want it to slow down, thus a null friction is needed. These are usually defined with either 0 or infinite. However, the friction model might not be perfect, and what you actually get is very little friction, so you can still feel the character slowing down, or a high-but-not-infinite friction, so the character slides very slowly on that ramp no matter how artificially high the friction parameters are. The conflicting requirements for ramps mean that usually there is simply no way to perfectly model desired behavior.
Trouble with Restitution: Basically you don't want any restitution, ever. When the character moves fast and collides with a wall, you don't want it to bump against it. When the character falls from a height and lands on the ground, flexing his legs, you definitely don't want any bumps, which would visually look terrible. But once again, even when the restitution is exactly zero, you sometimes get a small bump nonetheless. This is not only related to the non-perfect nature of the linear solver, but also has to do with how typical penetration-depth-based engines recover from overlap situations, sometimes applying too high a force that repels objects more than desired.
Undesired Jumps: It is often important that a character stick to the ground, no matter what the physical behavior should be. For example, characters in action games tend to move fast, at unrealistic speeds. When they reach the top of a ramp, the physics engine often makes them jump a bit, in the same way a fast car would jump in the streets of San Francisco. But that is often not desired: the character should stick to the ground regardless of its current velocity. This is sometimes implemented using fixed joints, which is a terrible, terrible solution to a very simple problem that has been solved for years without requiring all the modern complexity of a physics engine.
Undesired Rotations: Finally, a character is always standing up and never rotating. However, a physics engine often has poor support for that kind of constraint, and a great deal of effort is put into just preventing a capsule around the character from falling (it should always stand up on its tip). This too is sometimes implemented using artificial joints, and the resulting system is neither very robust nor very fast.
In summary, a lot of time is spent in disabling the physics engine's features, one after the other, for the whole purpose of emulating an otherwise simple piece of customized code. This is not the correct approach.
--------------------------------------------------------------------------------
Copyright © 2008 NVIDIA Corporation, 2701 San Tomas Expressway, Santa Clara, CA 95050 U.S.A. All rights reserved. www.nvidia.com
|
|
|
Re: PH_CHAR
[Re: 3run]
#397414
03/18/12 22:13
03/18/12 22:13
|
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB
Expert
|
Expert
Joined: Feb 2008
Posts: 3,232
Australia
|
Hey 3run... Heres a simple test...
TRY using PH_CAPSULE instead of PH_BOX or your player.
But give it a thorough test. This MAY crearte new peoblems...
"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
|
|
|
Re: PH_CHAR
[Re: 3run]
#397440
03/19/12 11:16
03/19/12 11:16
|
Joined: Oct 2004
Posts: 900
Lgh
rojart
User
|
User
Joined: Oct 2004
Posts: 900
Lgh
|
Of course, read especially this sentence here: "Let's here why PhysX is against Dynamic Character Controllers:" I make an movie that show you the "Sample Character Controller": (Click on the picture to see the movie. Best view on Google Chrome)  Do you believe me now?
|
|
|
Re: PH_CHAR
[Re: 3run]
#397612
03/21/12 11:52
03/21/12 11:52
|
Joined: May 2009
Posts: 5,370
Caucasus
3run
OP
Senior Expert
|
OP
Senior Expert
Joined: May 2009
Posts: 5,370
Caucasus
|
For the problem with crawling, as I said, I've tried painkillers approach, but with PH_CHAR, it didn't work.. Download link I hope, someone could share his / her experience / ideas about this.
|
|
|
Re: PH_CHAR
[Re: 3run]
#397655
03/21/12 20:49
03/21/12 20:49
|
Joined: Mar 2012
Posts: 927
cyberspace
Wjbender
User
|
User
Joined: Mar 2012
Posts: 927
cyberspace
|
I was thinking would it be possible to use a animated convex hull ,or to add remove hull shapes during transition from stance to crawl ? Just randomly thinking of ideas here ..Also i thnk i remember having acces to newton bodys do we have acces to physx bodys for manipulation or is that not a feature of physx
Last edited by Wjbender; 03/21/12 20:53.
Compulsive compiler
|
|
|
|
Thank you for video. So, problem isn't solvable?