I KNOW creating a static object is just adding a Geom to a space and not adding a Body BUT when you want to have a static Body I read somewhere you should create a FixedJoint to the World. And I don’t see what were all the problems with FixedJoints (in the guide they said “it should be used only for debugging purposes” and now you say “it can lead to a lot of troubles”).
brcause it’s a joint and joint work in some kind of way, that they apply a force to the bodies they connect to establish the joint restriction. So a fixed joint would allow the body to wobble a bit. -> Not at all stable.
Well, if the solver was perfect and if the simulation was continuous, the joint wouldn’t allow the body to wobble at all… Now I agree this is absolute talking.
[quote]I KNOW creating a static object is just adding a Geom to a space and not adding a Body BUT when you want to have a static Body I read somewhere you should create a FixedJoint to the World. And I don’t see what were all the problems with FixedJoints (in the guide they said “it should be used only for debugging purposes” and now you say “it can lead to a lot of troubles”).
[/quote]
Why do you want a static Body? what is the point? You can never apply forces to it or anything.
Creating a fixedJoint is the answer. I dunno why the people at ODE hate the FixedJoints. I do not find them problematic. I think they are just trying to put off people making massive composite geometries with loads of FixedJoints. FixedJoints should be used in situations where the joint is temporary.
I never had a problem with ball and hinge joints anchored to only one Body… I think I wrote TestCases for them.
If you want to have a surface or a wall for example, these are objects, which will always have the same position and rotation, so no forces act on them, but will take place in collision detection. This looks like a very simple logic to me: don’t apply any forces to these objects. Why should I have this complex calculations required by a joint?
yep - I already told him - by msn
JOODE primitive geometries and colliders are all implemented now 
nice 
also Box-Box?
EDIT: nep - same error, even if you did some refactoring…nah ok anyways - we won’t be needing Box anyways anymore when Tom got his Convex-Code working.
Fixed a bug, Box-Box is working now as well.
I found the piece of code that prevented static geoms to work ;D
Updated the collision tests to work with static objects.
Nonetheless there seems to be a bug in the stepper function (for example the Sphere-Sphere-Collision behaves strange)
nice, very nice 
good work!!
the SphereSphereCollisionTest looks ok. That SphereCollisionTest gives an ArrayIndexOutOfBounds.
- BoxBoxCollision seems to work, but the response action seems to be a bit too extreme. The box jumps much higher than it started…
The SphereSphereCollisionTest shows a strange behaviour on my computer as well. The straight collision looks good, but the collision of the shifted sphere shows an response that’s too extreme. That’s why I think that the Stepper (or the LCP solver) has an bug.
[quote]That’s why I think that the Stepper (or the LCP solver) has an bug.
[/quote]
Grrr. I hope it doesn’t. Its impossible to understand that code. I jsut ported it withou trying to understand it. It took me two attempts before I got what I did working
Good news, it seems not to be the Stpper and LCP solver that causes the problems. I just implemented the QuickStepper and for collisions its behaving exactly the same way like the InternalStepIsland.
I just found a bug in Body, where the inverse of the mass is stored, but never got updated. I removed the property and put the calculations in place.
If you have a look at the SphereSphereCollsionTest it looks pretty good now. The BoxBoxCollisionTest is still not working properly, but I guess there is another a bug in the collider code.
Oh awsome. Oh thats so awsome…
Great job
;D Just glad to see the bug wasn’t in LCP, heh ?
:’( :’( :’(
I have found the bug in BoxBoxCollision, but that makes everything worse. The results from BoxBoxCollider are OK, but the behaviour is not correct. In the moment I am debugging a lot and it looks like the LCP solver returns nearly fair result for one collion result, but Box-Box collision returns four result and the results from the stepper are wrong.
yep BoxBoxCollider returns several Contacts. Maybe the results add up?
How do you do the debugging? I think it’s pretty hard to debug such math stuff.
I am using Eclipse for debugging. Just set breakpoints at appropriate points. I do not understand all of the math, but I see that some of the results have certain effects on the bodies and then check if the values look OK. If they are not OK (for example the resulting forces from the LCP solver) I try to check where the values are calculated. In some cases it is obvious that there are errors (for example wrong iterations or simpel completely nonsense calculations).
Above all it is necessary to have a testcase, that reproduces the error without doing anything more. Otherwise you have to take too many constraints into consideration.
I got it, that master bug The matrix.get() function returned worng values. For QuickStepper the results look quite OK now.