(@hdietrich : Welcome !)You can make a FixedJoint to the static environment (just pass '0' instead of a reference to a body in the "attach" function).Ah yeah or just don't create a corresponding body, just the geom.

simply don't add a body to it. Mmh doesn't seem to work - but actually it should

I'm looking now at that Joint stuff - pretty disgusting this vtable stuff and with everywhere refering to JointUtils - nah now I'm trying to understand that and then I will clean it up before I add new stuff to it.

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.

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.

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").

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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?

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.

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org