Collision Again

I see many posts regarding problems with collision objects falling through static collision meshes, but so far there doesn't seem to be a definitive solution, yet users have surely worked out solutions to have released games.

I too have been having problems with a simple collision test. To demonstrate, I have created a basic project based on tutorial06_1. See included files:

replacement template.mm file, a replacement tutorial06.sio2, and the .blend file that created it. The changes I have made in the template.mm file are hopefully clear.

Basically there is a box created in blender and a sphere inside it. The intention is to have the sphere bounce around inside the box everytime the screen is tapped. The box has had it's normals flipped so we can see inside it and is set to a static mesh with bounds set to triangle mesh. The sphere is set to a dynamic mesh with it's bounds set to sphere. Both objects have had CTR+A applied. A camera is also present in the scene and although tutorial06_1 creates a physics camera from this, you will see in the template.mm I have disabled this feature with an #ifdef so we don't need to have any other collisions active in the scene.

Now for me, running this modified version of tutorial06_1 appears to be working fine on the simulator when it initially starts up. When the application starts, the sphere falls and lands on the inside of the cube as expected. However, in the code you will see the line that allows the tapping of the screen to move the sphere:

mObj_Ball->_btRigidBody->setLinearVelocity(btVector3(20,0.0f,20));

The first issue with this test is now apparent when running the test and tapping the screen. You'll notice no velocity is applied to the Y component above. I therefore expect the sphere to bounce on a constant Y axis but this isn't the case. This is perhaps simply because the sphere is of course not truly round. Regardless, this is a minor issue but worth mentioning all the same.

The real issue is that after a few taps the sphere will escape the box, the collision clearly fails. This can be recreated more simply if you increase the velocity values from 20 to say, 100. It does seem that the higher the velocity, the more likely it is that the collision will fail, although it CAN fail at low velocity values as well.

I have adjusted the restitution values of both the cube and the sphere as you'll see in the code. However, even if you comment these lines out, the test will still fail. Also, the only reason the test is being carried out in a "normal reversed" cube is because of the minor problem mentioned earlier regarding the axis movement of the sphere not being constant even though the velocity applied is. Simply setting the sphere on a plane and only applying a Z velocity to throw the sphere up in the air and see if it fails to land on the plane DOES fail as well when the velocity gets high but the test is not as clear because sometimes when the sphere lands on the plane it can "roll" off it upon landing, making it difficult to test if the sphere fell "past" the plane on descent rather than "through" it. A solid cube gives a clearer test that the collision is failing.

I should say I am unable to perform this test on a real device as I do not have a handset available for this, it could be that the test only fails on the simulator but this seems unlikely?

It could be that my test itself is flawed, perhaps the order or methods used to give the sphere velocity is flawed?

I, and I'm sure many others, would appreciate someone taking the time to look at this simple test project and give the definitive answer as to why the collision is failing and, more importantly, how to solve such issues. I have personally tried all the suggested solutions mentioned elsewhere on the forums such as:

Changing margin settings (either in blender or in code)

Increasing mass of objects.

Changing the timestep of the physics and/or it's number of passes from 1 to 2.

Plus others, none have fixed this test.

Clearly the best person to solve these issues is the author of SIO2 but I'm certain he has more important things to work on with the engine going forward, once somebody has a clear solution to these collision issues it needs to be added to the WIKI someone has kindly taken the time to set up.

vinnief

<snip>

<snip>

Hey man, first off you should use code tags when putting source code up. Second, the .blend file is the important part of this puzzle and you didn't include it. Without seeing that it is impossible to tell what is happening.

Have you tried increasing the poly count of the mesh (in edit mode W -> subdivide a few times)? Have you read the Bullet docs and understand it's limitations? What margin values have you tried? Thats about all I have for you.

Good luck.

The blend file is now available here:

http://www.4shared.com/file/105408254/b61d153f/tutorial06.html

The template.mm file can be found here:

http://www.4shared.com/file/105408012/3896a160/template.html

Here are a few things to try:
add some more verts to your cube. You have the bare minimum right now. Try doubling it and see if that helps.
add a margin of something like 0.06 and try and then maybe up the margin to 0.1 if you have to. (if you havent already) This will make the bouncing seem a bit odd, but that can be fixed in other ways.

Upload the full zipped tutorial folder as well for easy testing.

What bullet stepping are you using?
Are you using the default one in EAGLView.mm->drawView()?
Defining the correct bullet stepping plays an important part for the physics and collisions detection...

Subdividing the cube faces would definitely be a good thing to do if you have not tried it yet (did not check your blend file as I'm not home)

Default marging is 0.040 _BUT_ you have to set it explicitly as a property in blender named 'margin' for your mesh otherwise it will end up as zero since SIO2 sets the margin from the property you define in blender when it creates bullet rigid bodies during sio2ResourceBindAllPhysicObjects() upon loading step.

I'll check your blender file as soon as I can...Hope this helps a bit

Ok - I was able to access it at work...

Your cube mesh does not need to have the margin defined because it is a static body and a triangle mesh - the margin for the cube will be zero and that is fine - now for your dynamic object such as the sphere, you DO NEED to set the margin in blender - right now the property is NOT defined and that is a problem (add a 'margin' property and set it to 0.040 for now - this is the default for bullet)...

You also need to subdivide your cube a few times ;-) oh yeah....that's for sure...

Do these 2 things and that should help...You might also want to increase the mass on the sphere a bit to 5 instead of 1 or even 10...This might help too and I have seen it recommended on the bullet forums...

Hope this helps

Cheers for the advice

I've performed 2 sub meshes on the cube increasing the poly count (is this a common solution as it seems a waste of polys? Though I suppose the way round that is to have an invisible collision mesh to relieve the renderer of some work if that's often the solution). Anyway, that didn't help, sphere still escapes.

Increased margin of the cube to both .06 and .1, again sphere still escapes.

p.s. I didn't want to upload the whole project, it is just a replacement sio2 blender file and the template.mm for tutorial06_1 that ships with the sdk, at least so far. If other files have to be changed and a fix is eventually found, I'll upload the full project at that point and document the solution in the wiki.

So yes, I am using the default physics stepping in tutorial06_1 ... what should this be changed to perhaps?

I note blender (2.48a - should have said earlier) has a property "Margin" under "Advanced Settings@ for the actor (value defaulted to zero in 2.48a it seems), so it is NOT enough to simply use that as SIO2 overrides it? I'm unsure at the time of writing how to add other properties, though I could set the property after loading objects in code. I'll try the suggestions regarding mass etc...

NO the Margin property of blender is NOT used by sio2

You have to create a user property named 'margin'....

You do NOT need to set it for the cube but if you want you can still...

You need to define it for the sphere - 0.040 should be the first value to try...

Yes, having an invisible collision mesh is also recommended...you might want to try with one...this is what I did for my project...

HTH

Hmm, seems better with those few changes, but still fails. Here is the latest blend file:

http://www.4shared.com/file/105417691/8c83f86/_2__tutorial06.html

I added the property margin in blender for the sphere and set it to 0.040, didn't work, currently set to 1.0f which doesn't help either. I should say I do not do anything in code with this variable, it's simply added and set in blender, is that right or does SIO@ still override it perhaps with zero?

Maybe it's this physics stepping that is wrong, it's currently set to the default:

sio2PhysicRender( sio2->_SIO2physic, 1.0f / sio2->_SIO2window->fps, 1 );

No, SIO2 does not overwrite the margin.

Leave to 0.040 I would say and try the stepping below (substeps of 2):

sio2PhysicRender( sio2->_SIO2physic, 1.0f / sio2->_SIO2window->fps, 2 );

You could also try after with:

sio2PhysicRender( sio2->_SIO2physic, 1.0f / 60, 1 );

&&

sio2PhysicRender( sio2->_SIO2physic, 1.0f / 60, 2 );

&&

sio2PhysicRender( sio2->_SIO2physic, 35, 1 );

Of course one has to make sure that the physics stepping phase does not get behind as mentioned in:
http://www.bulletphysics.com/mediawiki-1.5.8/index.php?title=Stepping_the_World

Are you going to try with an invisible (ghost) collision mesh of more polys? might be worthwhile

Cheers

sio2PhysicRender( sio2->_SIO2physic, 35, 1 );

>> ??????

Changing the timestep to (1.0 / fps, 2) seemingly fixed the collision problem at a velocity push of 40,0,40 - but increasing the velocity to large values such as 100,0,100 causes the issues again. None of the suggested timesteps fixes the collision error if the velocity is high.

Welcome to the chat SIO2, yes the last one simply didn't show the object at the start of the simulation.

I'm now pretty sure the problem with collision errors is related to the time step, perhaps even the other areas like mesh density less so. Time to read that posted wiki link.... hopefully I can make some sense of it :S

sio2interactive wrote:sio2PhysicRender( sio2->_SIO2physic, 35, 1 );

>> ??????

Oops typo, I meant 1/35 of course

lol

hmm...

sio2PhysicRender( sio2->_SIO2physic, 1.0f / sio2->_SIO2window->fps, 10 );

fixes the issue even if the velocity is as high as 100,100,100 .. but I expect the framerate will suffer having steps that high, simulator seems ok in this simple low poly test though... seems this function:

void sio2PhysicRender( SIO2physic *_SIO2physic,
float _timestep,
int _pass )
{
unsigned int i = 0;

if( _SIO2physic->state == SIO2_PHYSIC_PLAY )
{
float sub = _timestep / ( float )_pass;

while( i != _pass )
{
_SIO2physic->_btSoftRigidDynamicsWorld->stepSimulation( sub, 0 );
++i;
}
}
}

could be changed to handle low and high frame rates better, increasing the steps IF AND WHEN they are needed?

Hmm, reading the wiki I came across this section:

"maxSubSteps == 0 ?

If you pass maxSubSteps=0 to the function, then it will assume a variable tick rate. Every tick, it will move the simulation along by exactly the timeStep you pass, in a single tick, instead of a number of ticks equal to fixedTimeStep.

This is not officially supported, and the death of determinism and framerate independance. Don't do it."

Isn't that what SIO2 IS doing in the function last posted even though you shouldn't? I'm sure I'm either understanding things wrong or SIO2 has a good reason for passing 0 in this manner?

Well, SIO2 is taking into account the passed in number of passes and calling stepSimulation() accordingly so it is in a way emulating what Bullet would do internally. If you can fairly predict/determine your FPS for your project then you would fairly safe in determining a constant number of passes to process at runtime...if your FPS is not likely to be constant, then this could lead to issues where the physics would start to fall behind during pikes...

What would be interesting is to try and compute the maxSubSteps based on the passed-in timeStep and then pass this to stepSimulation()...We know the default fixedTimeStep is 1/60th of a second, so it would be possible to compute maxSubsteps based off the passed in timeStep...Of course, having maxSubSteps > 3 could lead to performance issue on the iDevice...just thinking....

I think this might be more accurate and produce better results, especially if the framerate becomes quite low and we start falling behind...

Falling behind is definitely possible with some low FPS and a maxSubSteps that is not high-enough...

timeStep < maxSubSteps * fixedTimeStep