thank you for your quick answer!
benelot wrote:Sounds like a cool game! Is it open source?
Yes, please check http://supertuxkart.net
(we have just done a new RC: https://sourceforge.net/projects/supert ... art/0.9.2/
Concerning your issue, it sounds strange to just hardcode the contact normal,
Well, not really 'hardcode' - I use the normal from the triangle (instead of the connection-line between the two bodies). By now I have verified that the cylinder (puck) has the same issue, and the same fix (using the normal of the triangle) solves the problem for us. I have a slightly modified patch now (I test that the triangle body has indeed mass 0), so my change should not affect any collision between dynamic triangle meshes (though we don't have them anyway, all our dynamic objects are simple shapes like cone, spheres, boxes). You can see my patch here:
https://github.com/supertuxkart/stk-cod ... e/fix-2522
It's basically the same patch applied at two locations (once for sphere triangle collision, the other for convex vs triangle). I admit it is VERY ugly code, since I have to include some dynamics code into the collision handling (in order to get the mass). A proper fix would be to include a flag from a calling subroutine (where we still have dynamical bodies) to trigger the different normal computation in the collision handling, or perhaps detect in the first place if a static body is involved and handle this case separately?. But since that would be a lot of code changes, I don't want to do this work
as it might be the base for the reflection of the ball on the ground and if you ever do triangle collision with the cars, then the cars as well.
I think that should be ok now, since only tracks would be static bodies.
In fact, the slight deviations of your contact point are typical numerical errors,
Not sure about your usage of 'numerical errors' - the error is not a floating point error, but a problem with the way of how the collision is handled. That can of course be because bullet is a simulation (or because there is a bug
Maybe it's just that in case of a static body using the connection between the two contact points is not correct since the static body is not pushed away?? But I can certainly see that if the incorrect normal is used and the speed of the object happens to be big in the 'incorrect' direction, a too large impulse is applied. Maybe if the solver would iterate longer the effect might be reduced). Just to be sure, we are not talking of a slight 'wobbling'. One of our devs made a video of it:
https://www.youtube.com/watch?v=e2SkBWH ... tu.be&t=40
Completely unmotivated the puck is suddenly pushed up higher than the kart. Admittedly it is rare that it happens that rarey, but if the velocity just happens to be large in the right direction when the normal is incorrect, the effects can be rather huge. I see that the impulse applied by the collision impulse solved causes a vertical speed of 2m/s. We actually removed the puck from our next release because it looks so bad (ball has the same effect, but at least it looks a bit more natural, people accept that a ball can bounce a bit
and it is interesting that you can observe them in the behavior of the game. Anyway, you might want to use btStaticPlaneShape, making the normal always correct. Anything preventing you from using this?
First of all, I am not sure that this would actually solve the problem - I admit I only had a very quick look, but it appears that the static plane creates two triangle to do the collision (in btStaticPlaneShape::processAllTriangles), so I am not convinced that it is worth the effort to test this
Secondly (and for us more important): it doesn't work with our pipeline. We export the whole track (including AI information and other meta information like material) from blender, and in general we don't have that flat planes to make it worth handling this as a special case. In fact, I have seen 'bowling balls' (powerups in the game) jumping up unexpectedly for a long time, and always assumed it's just our tracks being not smooth enough. Now I strongly suspect that this is actually the same issue.
Did you do many changes to the bullet code base? You might want to consider porting to the newer release, just to keep up with the future. Otherwise, if you are happy with your performance, stay with it!
We are happy with the performance, so as long as we don't hit real problem we don't intend to update (being a small team we just don't have the time to keep all our libs up-to-date).
We did apply a few changes (we basically have a somewhat modified version of the raycast vehicle: https://github.com/supertuxkart/stk-cod ... btKart.cpp
- added function to apply additional impulses (for special handling triggered by game play, not physics)
- support 'cushioning' of falls (we detect when a kart is falling and would hit the ground too hard for the suspension, so that actually the chassis would hit the ground) and in this case apply an additional upward impulse to prevent this from happening.
- have code to keep karts upright (as much as possible)
- improved jumping a bit (if a kart should have only one wheel on the ground before it finally takes off, this will add a rotation to the kart causing is to land facing in the wrong direction. And while this might be real, it's not fun playing So we ... just pretend that always both wheels on one axle are on or off ground ).
- added some bug fixes (e.g. https://github.com/supertuxkart/stk-cod ... dfd2c5fe7d which afaik was never accepted/integrated into bullet).