Woo, we have a new developer. Welcome hdietrich
welcome 
Hey, this time you were really fast 
Until now CVS doesn’t let me check in code. I guess it takes some time until the new settings will be applied.
yeah there is a bit of a delay, CVS is working for me again now. I have not updated yet though (my uni account has exceeded is disk quota gain, sigh)
Code for primitive geometries and colliders has been added.
For each collider a test has been added.
Be aware that not all of the colliders have been implemented and therefor not all tests show a valid behaviour. I just wanted to add them to have an overview of what is working and what is still missing.
what do you think , what is current status of joode development in %,
50 % , 70 %, of course in your opinion
For a complete integration of ODE functionality it is still a long way to go, but I think its worth having releases before that.
Things to do in the next days:
- implementation of all primitive colliders (could be accomplished quite soon)
- implementation of convex colliders (don’t know what’s the status of t_larkworthy)
- basic support of limits and motors in joints (see above)
- clean up of the API
After that has been done I think 80% of the functionality has been ported. The rest will be the more complex stuff, which will take some time.
Further things to do:
4. implementation or TriMesh geometry and colliders
5. full support of limits and motors in joints
Of course thats my personal opinion and I am quite new to the code, so I could be totally wrong ;D. Please correct me.
good job hdiertich
I just looked at the CapsuleSphereCollisionTest (but it’ll be similar with the other Test-cases you made) There you set the mass of the second Body to 0.
The collision looks fine, which is why I’m wondering. So for example the first Body actually gets slower when the collision happens, but because the second body has no mass at all, it cannot give some of it’s kinetic energy to the other body - so it actually shouldn’t slow (no matter what the other body does)
-> there might be a problem in the basics of our collision algorithm. 
I’m currently digging into this, because I expected a body without mass to behave like a static object (F=m*a is always zero for m=0).
actually I expected a division by 0
a = F/m
how would I declare a geometry to be static (=does not move)?
(@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.
Yes, it is really distgusting. I am looking at the InternalIslandStepper stuff and wonder, if this is Java code or still C code
I think it is really necessary to get the code cleaned up, so it is understandable for everyone. I already hate this Real and RealPointer stuff.
[quote]simply don’t add a body to it. Mmh doesn’t seem to work - but actually it should Sad
[/quote]
That’s what I remembered from my earlier work with ODEJava, but it did not work. So I tried setting the mass of the body to zero, but this does not work properly either.
The use of a FixedJoint to the environement sounds like a dirty hack
That’s what I remembered from my earlier work with ODEJava, but it did not work. So I tried setting the mass of the body to zero, but this does not work properly either.
[/quote]
I thinks its a reaction-problem not a collision-finding problem. - So yes InternalIslandStepper is probably the correct direction.
yeah sadly it will also require a full understanding of the underlying math stuff (you simply can’t understand that, what the ODE coders hacked together)
yeah sadly it will also require a full understanding of the underlying math stuff (you simply can’t understand that, what the ODE coders hacked together)
But it is easier to understand if the code is completely OO and not this pointer and real array madness. After a cleanup it would not be that difficult anymore. It’s only math
I will check where we could start with an cleanup without interfering to much with the expected changes in the convex implementation from t_larkworthy.
What’s the target for vector math: use of the vecmath library or own implementation (as seen in Vector3, Matrix3, MathUtils)?
I would tend to use the vecmath library but do not want to make any changes until this is clarified.
It may be, but it’s what was recommended by the ODE User Guide…
Errr…no it doesn’t
Creating a Static object is just adding a Geom to a space and not adding a body to the world. Having a FixedJoint to the world can lead to alot and alot of trouble.
DP