The collision detection system checks whether physics objects and wall faces intersect, then applies corrective forces to keep the object on the correct side of the wall.
If the object has a high speed (relative to frame rate and wall thickness) then it could move from one side of the wall to the other side within one frame. To prevent this I trace a line from old position (center of bounding sphere) to new position. If the line intersects a wall, the object gets moved to a place approximately in front of the wall.

These are the three places where something could go wrong: face collision is not registered, line collision is not registered, or corrective forces are not accurate. Since the ERP/CFM settings have had an impact (and they tweak the corrective forces) I am afraid that this is where the problem comes from, which means it will be very difficult to fix.

Is it possible to move the ball automatically through level geometry in a few frames by applying large torque/forces? What are the ERP/CFM settings in order for this to occur? If anyone can achieve this, please send a script/level to mgrubert@conitec.net, so I can step through it and figure out exactly when things go wrong.

Also, there is a level restriction which is not mentioned in the manual, but was discovered by Ventilator:
Physics levels must have an enclosing volume, e.g. a skybox. If this is not present then the physics engine will assume any objects outside your level geometry to be invalid.

marble.zip i uploaded my example level with the default erp/cfm settings. just maneuver the ball to a wall and keep moving it into the direction of the wall. first it bounces a few times and then it should fall through the level after a certain amount of spin is reached. the spin doesn't have to be very extreme...

i move the ball by applying a torque but the strange thing is that when the ball moves by applying a central force it starts spinning too and falls through the level when it gets forced against a wall.

setting erp/cfm to 60000/0.01 reduces the problem to a minimum. the disadvantage is that these settings make the ball bounce a little more extreme when it intersects level geometry (overshooting?).

...
a ph command which allows individual entities to override the global erp/cfm settings would be helpful in my opinion. because i wouldn't need 60000/0.01 for every entity in this level.

i also sent you an email with an automated example. it's strange because there the problem only happens with the current beta version on my computer. collision in 6.00.6 seems to work much better...

What's happening in this example is that the ball is gaining lots of momentum and is basically "tunneling" its way into the level geometry.
Every frame I check entity/world collisions and set up temporary collision joints to prevent the entity from moving any further. The global ERP/CFM parameters define how restrictive this joint will be. An ERP of 20,000 corresponds to ca. 20% error correction per frame. Thus if the ball is 1 quant into the wall it will be approximately 0.8 quants into the wall afterwards. But since the force is still being applied next time around the ball is 2 quants into the wall, which will be corrected to 1.6 quants, etc. At some point the ball's center is inside the block and there's no hope left.

I mentioned an additional safe-guard before. Every entities center is checked whether it has crossed a wall or not. This, however, only prevents an object from missing a wall entirely. Thus if an object shoots across the room and it would penetrate a wall, A6 puts it roughly in front of the wall and the usual joint mechanism kicks in (not in this case though because the joint is too weak).

Solutions:
- higher ERP value (and lower CFM) to enforce walls more strictly
- phent_setmaxspeed to prevent objects from getting too fast
- larger objects
- more elasticity /more friction / more damping

I will look into setting different ERP values per object or per constraint.

thanks for examining this!

wouldn't it be possible to dynamically increase an entity's erp depending on how much it currently penetrates the level geometry?

...
sometimes it's really tricky to find the right combination of parameters. i wonder how they manage to make physics in games like halflife2 foolproof? for example, how do they prevent that a player collects all items of a level with the gravitation gun and throws them onto a pile? all this collisions in the pile really could freeze (<1fps) the game...

marco, have you ever worked with other physics engines like havok?

ventilator -
Here is some good words from a new guy on the scene "Newton"

"Don't worry my friend...Help is on the way!
There is a new physics engine in development that will blow away anything you have seen before. It is being integrated as we speak...Any version of Gamestudio!...any amount of objects!!... and very little programming.
No esoteric parameters to tune. sounds too good to be true, but I'm using it right now. Its in an early stage, but as an example:
- A5 commercial dropping MANY objects into a scene with EXCELLENT realistic behavior.

COMING SOON!!!

yes, it really sounds too good to be true!

is this programmer a colleague of you? what physics engine is it based on? or did he do this from scratch? what is his motivation for doing this?

Hey Ventilator,

I've been testing Newton Physics as well. It's damn cool. He is a friend of Dr. Jelly and myself. He made it from scratch a while back ago. We showed him Gamestudio and he wanted to see if it could be ported to it. It took him a day to do it. He is motivated by the fact that there isn't a good physics solution available for the Gamestudio masses and he's having fun doing it.

Eka

exactly.
He's just doing it for fun... he gets VERY excited when we brainstorm different physics functions...

actually right now we are checking out the legal issues of a public release... maybe just some demos...maybe the release, its up to Newton and what he wants to do.
I'm just the messenger until he registers...