hi, ehm i have seen this strange fenomenom that my object 1 is getting stuck into object 2, object 2 is a floor and i see that the visual model is a bit penetrating the floor , so i guess it's something about elasticity of the material or something but i dont know
this is a really serious problem, because the objects tends to fall over as it sinks in the floor where the load is most heavy,
when i set the timestep to a smaller number the sinking is decrest but i dont think that's a good idea to do this, because running a 500 fps simulation is nuts
Also i would like the state that this is a humanoid robot that has many joints, and the parent is probabbly pushing the foot more down or something into the floor ... man isnt there a trick for this, I mean i bet this is a common problem that could be explained in some FAQ or something how to remove penetration
Seems to be the same as my problem: http://newtondynamics.com/forum/viewtopic.php?f=12&t=7586 Maybe it's related to a penetration treshold, so it could help to scale model up - i have not tried that yet. I'm not sure if the problem is there since i scaled my model down by a factor of 20, or since the collision system was updated in core 300.
well as you can see the heals of the robot are sinking into the floor a bit (that is below the surface) , in 0:16 you can see that the foot box is below the surface, partly
That's exactly my problem too. Julio, did you not recieve the download link for my demo via PM? There you see the same, but contacts with normals and forces visualized, and you can interact with the stuff to test.
SilentAssassin21, I see, the error is on the big rectangular box on the floor. when you running this in debug, do you get any warning message? It is possible for you to send me a test that I can runb to see what it is? I am guessing this is a mal funtion of the calculation of the first simplex on the contact calculation. That is the most critical part of the collision system, and it happens when two shapes collide face to face, in that case volume of the first simple can be zero, or near zero. that is not the real problem, the real problem is that when the values are on the vecinity of zero, then rounding float errors affect the algorithm very severelly and the calculation of the first simplex may not represent a convex tetrahedrum on the convex surface formed by the minkosky difference of two colliding shapes.
There are some warning test that warn when the cituation happens and I fixed all ocurrances in my test demos, but there may be more cases where the problem happens between the criteria that test if the first simplex is good or not, it is hard to debug without a demo.
If you can send me a test demo, I can add the fix for that.