[quote]This is what I wanted to introduce when I talked about “GeomGroup”, but, err… it’s a bit more logic to do “BodyGroup(s)”, you’re right (or CompositeBody if you want).
[/quote]
Well certainly its possible. There are alot of places it could go wrong though. I have had no sleep for the last 2 days as I have been tearing my hair out getting planar subdivisions calculated properly. I just solved it and I have realised they are not powerful enough. Hmpf! I have a presentation 2morrow as well so I think I am gonna have to present “planar subdivisions”.
I am desperatly trying to get convex trimeshes completed for the weekend, so I can then relax for a while 
Yes indeed. I have finished my presentation. It had to be a 5 min presentation on anything I liked and as there is only one thing I know anything about at the moment it had to be something to do with planar subdivisions.
Those of you with open office impress might like to see the presentation becuase it does give a rough thoery of how I am takeling the trimesh problem (very rough as I have to present the talk in 5 mins)
http://homepages.inf.ed.ac.uk/s0570397/planar.sxi
Ii is intended to be amusing, dunno if that will carry over the internet quite so well… :-\
[quote]Ii is intended to be amusing, dunno if that will carry over the internet quite so well… Undecided
[/quote]
It is 
Nice, you’re advertising joode
I traced now loads of errors in BoxBox collisions, but it still doesn’t work, because now I get some ArrayOutOfBoundsException, from a part of the code I haven’t touched and I don’t know how my changes could cause this problem (I propbaly don’t know enough). I hope you can help me out there.
Stack-trace:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 216
at net.java.dev.joode.util.RealPointer.setValue(RealPointer.java:77)
at net.java.dev.joode.util.MathUtils.dMultiply2(MathUtils.java:575)
at net.java.dev.joode.stepper.InternalStepIsland_x1.step(InternalStepIsland_x1.java:234)
at net.java.dev.joode.stepper.InternalStepIsland.step(InternalStepIsland.java:27)
at net.java.dev.joode.stepper.StepUtils.dxProcessIslands(StepUtils.java:116)
at net.java.dev.joode.world.World.step(World.java:159)
at net.java.dev.joode.test.step.SphereCollisionTest.step(SphereCollisionTest.java:137)
at net.java.dev.joode.test.step.SphereCollisionTest.main(SphereCollisionTest.java:195)
I’ve commit my changes (they are only used by BoxBox collisions, so everything else should work still).
It’s great to see this project taking off. I am sorry to have not been of much help, I have been rather busy with my new job. On the plus side I have had to learn C++ (fast), so I might be able to help (and be more of a help) porting a few classes.
On the topic of formus (raised a few pages back), I suggest using these ones, this is where everyone is. Post in Game Physics prefix it with [JOODE] or something.
Will.
I think it would be better to make childboards in the “Game Physics” section :
- General Physics
- ODEJava
- JOODE
[quote]I traced now loads of errors in BoxBox collisions, but it still doesn’t work, because now I get some ArrayOutOfBoundsException, from a part of the code I haven’t touched and I don’t know how my changes could cause this problem (I propbaly don’t know enough). I hope you can help me out there.
[/quote]
Yeah. I have supsected those family of math methods are faulty. dMultiply2 & dMultiply0 & dMultiply1. I think that is what is stopping the step_island_x2 from working as well. I realised one problem with them a while ago, and its a general thing to look out for when using the RealPointer class:-
When pointers are passed in C, they can be incremented and stuff like
foo (Real * A){
A++
}
The effect of incremeneting them does not show itself out of method scope, however in the way I have implemented them in joode as a class, incrementing them and suchlike will be seen outside the method, so ANY METHODS THAT ALTER THE INDEX OF A RealPointer should clone the RealPointer first. It will still work on the same underlying data but the index will be a fresh copy so it will work more like it does in C. I corrected this once for these methods, but I realise I did not go far enough. So I have fixed what I think will be a problem and maybe it will work for you now arne. I could not find a test case for the BoxBox system so I could not check it.
Hope it did work
Tom
I was thinking it might be a good idea to gradually replace the calls to the obscure math functions in ODE and use stuff based on vecmath instaed. Looking back again on the methods I implemented for the Mass class, they seem to calculate things the obscure way. The equations for intertia would be much more readable if using Matrix4f.
That said, I know it would not be easy changing some of ODE’s fundimental data types. What does everyone else think?
to code functions the clearer way is always good. But we’ll probably not be able to code all functions like this, but I think a mixing of obscure code and clear code is still better than only obscure code.
- If you code such functions put them into a location, where it makes sense for them to be (e.g. Matrix4 in your case), then MathUtils is the class for obscure math.
Yeah. I have supsected those family of math methods are faulty. dMultiply2 & dMultiply0 & dMultiply1. I think that is what is stopping the step_island_x2 from working as well. I realised one problem with them a while ago, and its a general thing to look out for when using the RealPointer class:-
When pointers are passed in C, they can be incremented and stuff like
foo (Real * A){
A++
}
The effect of incremeneting them does not show itself out of method scope, however in the way I have implemented them in joode as a class, incrementing them and suchlike will be seen outside the method, so ANY METHODS THAT ALTER THE INDEX OF A RealPointer should clone the RealPointer first. It will still work on the same underlying data but the index will be a fresh copy so it will work more like it does in C. I corrected this once for these methods, but I realise I did not go far enough. So I have fixed what I think will be a problem and maybe it will work for you now arne. I could not find a test case for the BoxBox system so I could not check it.
Hope it did work
Tom
[/quote]
It doesn’t work still. I’ve modified SphereCollsionTest to do BoxBox Collisions, so this should be the test-case. (Sorry, but I accidently commited it, but if you want the old example back, you’ll only have to flip one comment)
Yeah. I would love it if the math stuff was replaced with readable stuff. It is not an easy task though.
[quote]It doesn’t work still. I’ve modified SphereCollsionTest to do BoxBox Collisions, so this should be the test-case. (Sorry, but I accidently commited it, but if you want the old example back, you’ll only have to flip one comment)
[/quote]
Hmmmm. I have had a go at it. It still does not work but it seems a bug has been fixed in Multiply2. step_island_x2 partially runs now. It still does nto work but its not crashing now. It seems the A matrix in the step is not setup properly in the BoxBox collisions situation. Its weird that the other collision scenarios work though.
Hmmm… ???
Wow I’m impressed this has taken off. Thumbs up guys, hope it goes well!
I have had another hack at it arne. I find the behaviour that screws up the LCP algorithm is that the boxes seem to hit each other then force themselves closer rather than further away. I tried swaping the direction of the contact normals in the BoxBox Collisions and that seems to make the system semi work. Now the boxes fly away from each other when they hit each other, but at a grossly exagerated spped. This suggests the the penetration depth has been calculated far too high.
Maybe the the contact normals were right in the first place but the penetration depth was calculated with the wrong sign for some reason!?
good - at least we’ve found the problem now
mmh - maybe we should try to create the Boxes on a greater Area? I believe the simulation starts with them intersecting each other - so this might not be very good.
mmh one thing that came across my mind with that problem - isn’t there really a better method for that? Understanding the stuff you code is the best wa to prevent errors. - I’ll google for a better method or at least to give me a better idea of what they are doing there.
Some news ?
Maybe we would have done better to start another physic engine and take ODE as a reference rather than as a basis. Because what I’ve seen is we take more time to understand how this crappy code works than adding features or fixing bugs (that aren’t due to the port).
What’s your opinion ?
You may take a look at the “Physic resources” post I’ve just created and add your favorites docs about physic simulation, so we have a good knowledge basis.
Yeah you might be right, It seems as if we’ve got stuck at the moment 
Haha. I am happy with JOODE at the moment. Yes implementaion has ground to a halt at the moment, but I am really busy at uni at the moment. I hope to get some work crammed in Jan before the next round of work comes in.
I have basically been trying to get arbitary collisions working so that all our woes with BoxBox collisions can be skipped. The work is quite tricky to get working properly though so nothing has come of it as yet. In Jan I shall first do some of the small jobs like joints and things just to make everyone feel comfortable that stuff is being done and then I shall go back to my arbitary collision nightmares.
I want to use the JAMA library. One of the outstanding problems in JOODE is the Cholsky decompositions don’t work. The offer an alternative to the LCP algoirthm for actually performing the physics math. I think they are a much simpler way of doing things and would be great for testing. Slow though. Anyway the JAMA library does Cholsky stuff … and eigenvectors which could come in handy much later on (for OBB trees). The whole package might even be usable for replacing our matrix math with something readable. Though I really suspect we may never have readable math for JOODE ???.