I’m prototyping a little game to see how it will work, and it works well, but the physics and other things like real time shadows are a bit unstable. Like how if you run up against a wall your character may shake back and forth a bit, and falling through relativly slow moving platforms, or floating above and sinking into platform moving up and down. Also, using sphere collision is really the only stable collision.
Is it just a BGE thing? Are there plans to fix it up? No offense to any of the developers. I’d really like to use BGE, but the character physics aren’t really up to the task, and rigid bodies are rather unstable.
using sphere collision is really the only stable collision.
dynamic is the most stable one, and physics correct.
dynamic has no problems with moving platforms or falling trough meshes.
you need to ensure that the ground is static (no bounding box) player a cube with dynamic, and box collission.
as soon as you use triangle mesh for terrain/ground/walls etc your character will fall/walk trough it at some point.
Like how if you run up against a wall your character may shake back and forth a bit
it all depends how you have build its movement, my character does not shake at all when walking against a wall.
in short its not bge but you are the problem (well the way you programming the stuff).
No, the problem is bge. And also bullet - unless something has changed, I looked into this stuff ages ago. It has to do with the fact that while the code claims himself to be “CCD” (that is Continuous Collision Detection) it, quite surprisingly, doesn’t use bullet ccd at all. It’s one of the feature of the bge codebase, you get stuff like that. It also has a quite severe case of weirdness in the time step computation that it is used to carry on the physics simulation so I’m not even sure if introducing CCD will fix the problem.
The bullet problem comes from the fact (again, it might have been changed now) that CCD is only applied to objects that are not in a prolonged contact situation. That is an airplane using CCD will never tunnel while a car using CCD will still occasionally fall under the street.
It is by no means a bge exclusive problem though. I’m playing Fallout 4 and it has hilarious tunneling issues.
It looks to me that “character” is does not use physics as rigid body, dynamic or soft-body do.
It feels like “teleporting” rather than moving. Teleporting always has problems with collisions as there is no motion direction which allows to calculate the first collision point or a reflective continuation.
I use a compound rigid body assembly, with its simple child shapes bounds unpartented and reparented each frame to match a armature,
can go right up and down stairs.
no falling through the unless you launch them really really fast down at a thin mesh, or you use triangle mesh collision shapes,
anything that moves really fast, just cast rays forward based on linV,
you can set up your own ccd.
edit: though we need a system that breaks up triangle mesh into many simple bounds, or even many convex hulls (though I prefer the simple bounds)
hitting any of these physics objects with a ray or sensor returns the name / data about the triangle mesh used to form it *
Ok, cotax, although rude, was partly correct. The character physics model is not viable for games. It’s not stable. But, using dynamic physics mode does work better, but it is nessecary to make manual jumping and stair climbing (not a problem for me, I like Python whenever possible).
Here’s what I got so far. You can use the scripts and sound effects in the blend in you projects, commercial or not, if you want. The jump sounds are made by me and the wind is public domain.
Here are the controls: “S” is jump and the left and right arrow keys are move.
Unfortunately it is not a matter of setup. You can test it by simply creating a cube, set to dynamic, and place a static floor a few units under it. Then you can apply a starting z- force to the cube until you find the value that makes the box tunnel through the floor. Note that there is no way this could happen with ccd detection enabled for the falling box.
@pgi: Why do you think BGE has CCD enabled? You’ll notice the API has acontrol to enable CCDwith the warning that is likely unstable. But I’ve never used it, nor had reason to. Non-CCD physics has been fine for games for the past 20 years.
I have no idea why bge has ccd enabled. I do know that it doesn’t work. The control to enable the ccdMode does nothing: it sets a member field (m_ccdMode) that, to the best of my knowledge, doesn’t appear to be used anywhere in the game engine.
While I do understand its merits, I’m not a particular fan of the “you can do without it” approach because taken to one extreme it basically says “do it with another piece of software” and that is not a productive contribution to the codebase.
Unfortunately the solution I found requires a deep change to the core loop of the engine that results in loosing the fixed-time step function introduced to support animation recording (a blender feature that kind of pollutes the engine’s loop leading to its strange look). And it won’t be a complete fix, since there still is the prolonged contact situation to deal with.
Ok, cotax, although rude, was partly correct. The character physics model is not viable for games. It’s not stable. But, using dynamic physics mode does work better, but it is nessecary to make manual jumping and stair climbing (not a problem for me, I like Python whenever possible).
It was not meant to be rude. Sorry.
Anyway, indeed you need to setup the jump and stair walking manually.
depending on the way you make the game, stairs can be easy faked with a plane, but this method needs additional programming for the character, because dynamic objects will slide from slopes, so you need to give it an additional z upforce, or messing with the friction setting of the material.
(well the way you programming the stuff).