So far, so good with the physics engine.
There's only one problem I've seen – my arena is composed of many boxes, and those boxes have their widths set to .5 (aka that's a wall, and it's 20 tall and 100 wide). I am sending projectiles incredibly fast (adding forces of up to 60,000). Sometimes, the projectiles simply fly straight through the wall. Is this because it's moving so fast that it will actually "skip" the wall and not collision detect? Could I solve this by making the walls thicker? Or is it some other bug?
thats a common problem with any physics engine i guess.
you could make the projectile a capsule instead of just a sphere (which makes the chance of a collision higher) or make the wall thicker.
I wouldn't think it's a problem with any physics engine–people wouldn't accept it. They'd want to make it very rare, whereas these balls were frequently escaping.
However, I have been a fool, and I think it was I who caused this error, and that jME-Physics is not to blame.
The way I had designed the level caused the bounding boxes to behave strangely, so I think loading in a new level will eliminate this problem.
Of note, as well, is this method:
generatePhysicsGeometry(boolean b)
which will pay extra-careful attention during collisions to make sure things don't fly through the walls. This helped tremendously.
It was skipping it though. I have had problems with this in Flash. Another fix is to let the frame rate be higher and shoot it slower, if you are limiting the speed of the game.
As posted above the problem wasn't with JME-Physics at all, but with the fact I had multiple objects inside one bounding box which caused collisions to behave very strangely. No balls escape, ever, anymore.
Ok, but then it should have sensed the collision immediately since it started in the box.
Trussell said:
As posted above the problem wasn't with JME-Physics at all, but with the fact I had multiple objects inside one bounding box which caused collisions to behave very strangely. No balls escape, ever, anymore.
I said multiple objects in one bounding box, not the entire thing in the bounding box. It was just related to the way I exported the level from MW3D, nothing more.
Maybe it wasn't the problem in your case, but I've tried the physics demo at http://code.google.com/p/jme-demos/source/browse/trunk/physics_fun/src/com/jmedemos/physics_fun/util/ObjectFactory.java
, and balls go through walls when they move very fast.
Wondering : what's the rough limit on velocity before it starts acting strange in JME physics?
A simple solution is to increase the accuracy of the physics simulation. The accuracy is set relatively low by default for better performance. If you experience objects that go through other objects at high speeds, it is because the physics engine missed it (it happened between iterations). Increasing the accuracy will prevent this, at the expense of performance.
jjmontes said:
Just another example: I don't use the physics engine for bullets if I can avoid it. I shoot a ray when the bullet is fired and I precalculate where it will impact (valid only for straight paths). Then I let bullets collide only with my entities, which are moving, but not with the world, since I already know where the bullet ends.
Yes I think thats the right way to do this. It is completely equivalent to doing continuous collision detection on a particle moving linearly through space. Insted of only seeing the particle at dicrete steps, it is viewed as a continuous line.
However, it would be cool to be able to do this on more advanced shapes. e.g in a car game, one might create an approximating box around a vehicle, and do CCD to ensure that the car isn't crashing through/get tangled up in the geometry bounding roads/ obstacles.
Using CCD for single fast-moving objects in a game is cool, because it removes the need for taking smaller time-steps, which in turn could mean a huge performance gain... on the other hand, CCD is expensive so its a trait-off thing.
DrBullshit said:
Maybe it wasn't the problem in your case, but I've tried the physics demo at http://code.google.com/p/jme-demos/source/browse/trunk/physics_fun/src/com/jmedemos/physics_fun/util/ObjectFactory.java
, and balls go through walls when they move very fast.
Wondering : what's the rough limit on velocity before it starts acting strange in JME physics?
This problem is well known in the physics simulation world, its usually called tunneling or overshoot effect, and it relates to excessive relative velocities (such as bullets hitting walls). For performance, most engines use discrete collision detection, so methods only see discrete time instances during an objects motion, and therefore the risk of overlooking collisions. The solution to this is to use continuous collision detection, which takes the whole continuous path of an object into account, and thus never misses anything. The only problem is that CCD is expensive, and therefore isn't widely used. However it could be used for some objects, like bullets. As long as the bullets are modeled using simple geometries, it should be relatively cheap. There is a promising method called convex ray casting ( that assumes no angular in-between motion, good for bullets) , but im not sure if it is implemented in ode, or jbullet. Bullet engine has an implementation of convex-convex continuous collision detection.
Right now im not aware if the jME physics API allows you to specify collision detection paradigm for specific objects...
The problem quickly becomes evident when dealing with oblong shapes that is easily rotated. When those objects are hit by another object, the gain fast angular speeds, which easily cause overshoots or bad/deep intersections. I think most people simply avoid such configurations in the first place :)
You could send a ray going towards where the bullet is going and get the first collision, delete the bullet(since it is going at such high speeds you won't see it for very long anyways), and create a decal of something on the first collision.
Just another example: I don't use the physics engine for bullets if I can avoid it. I shoot a ray when the bullet is fired and I precalculate where it will impact (valid only for straight paths). Then I let bullets collide only with my entities, which are moving, but not with the world, since I already know where the bullet ends.
Thanks for the explanations guys 
I tried increasing the accuracy and it worked.
For my stuff, I actually don't care about performance, but more about precision. As long as it runs at like 1 FPS or greater…
jjmontes said:
Just another example: I don't use the physics engine for bullets if I can avoid it. I shoot a ray when the bullet is fired and I precalculate where it will impact (valid only for straight paths). Then I let bullets collide only with my entities, which are moving, but not with the world, since I already know where the bullet ends.
Do you take into account the motion of the entities and the time it takes for the bullet to hit, or you just approximate the bullet as hitting instantaneously?
No, sorry. I just do the ray thing with static geometry.
For collision between bullets and entities I just use normal bounding bound collisions, so I can indeed miss collissions.