JOODE : Build

Game Mechanics
#1

I’m trying to build JOODE, but I get the following error when running build.xml :


Buildfile: /home/bluesky/workspace/joode/build.xml
init:
prepareBuild:
compile:
    [javac] Compiling 7 source files to /home/bluesky/workspace/joode/build/classes
    [javac] /home/bluesky/workspace/joode/src/net/java/dev/joode/test/math/CholeskyTest.java:11: cannot find symbol
    [javac] symbol  : constructor TestCase()
    [javac] location: class junit.framework.TestCase
    [javac] public class CholeskyTest extends TestCase{
    [javac] ^
    [javac] 1 error

BUILD FAILED
/home/bluesky/workspace/joode/build.xml:82: Compile failed; see the compiler error output for details.

Total time: 2 seconds

What’s the matter with it ?

#2

OK, I finally managed to build it just commenting out the offending file.
Hmm… I find a bit odd that the SphereCollisionTest just displays Boxes instead of Spheres… ;D
Anyway, the joints demos look pretty. Good job !

#3

[quote]Hmm… I find a bit odd that the SphereCollisionTest just displays Boxes instead of Spheres… Grin
[/quote]
mmh yeah - that’s my fault, I was just too lazy to create a new testcase for the boxes, so I simply modified it. Must then have commited accidently ;).

But to come back to that “just” - the collision with the boxes is much harder than the one with the spheres. (Next to that we won’t need it in near future anyways)

#4

Oh yeah, That must be a junit dependancy that is not plumbed into the build file. I tend to use Eclipse for my building at the moment.

#5

mmh yeah - that’s my fault, I was just too lazy to create a new testcase for the boxes, so I simply modified it. Must then have commited accidently ;).

But to come back to that “just” - the collision with the boxes is much harder than the one with the spheres. (Next to that we won’t need it in near future anyways)
[/quote]
OK I guessed that. But I’ll do a little cleaning of the codebase anyway (adding comments, maybe a bit of refactoring : variable names aren’t always meaningful).
And yeah I now it’s much harder to make collision with boxes than with spheres. Anyway, it’s just dealing with 6 planes, heh ? Say if one of the edge of Box 1 intersect one of the faces of Box 2 or Box2.edge intersects Box1.face there’s a collision. Hmm… anyway thomas said we can handle that with a convex collision detection algorithm. So, is it working ? Where are you with that, thomas ?

I use Eclipse too but as I saw there was a build.xml file I launched it.

#6

Yeah … convex code is nearly there. By nearly I mean it is not there yet :frowning:
Its all intergrated with the code base now. I have boxes bouncing around, but sometimes they think they intersect miles away and sometimes they don’t. I think there is a problem with my low level distance measures. It needs a proper set of test cases for me to debug it properly. The advanced bit is working, i.e. the heuristics, search and BSP trees. Just the normal bit isn’t :frowning:
I will try to get it done this weekend, but I may run into more probs…

#7

You’re still trying to implement the DEEP algorithm, heh ? Or you’ve changed your mind ?

#8

I have stuck with DEEP. The actual clever bits of that algorithm are not actually that hard to implement. The hard bit is getting the low level distance metrics to work correctly, and all the rotations etc. I have got a few hours now though…

#9

OK so good luck.
I’m currently doing a little game with JOODE and it’s pretty fun. I’ll use new features when they’ll come. We could use it as a “featured game”

#10

Oh exellent. Good man, we have some testing! Woo!

#11

so i found some bulids in cvs ok, but will be in oficial version also some tutorials like in old ode and javadoc?

#12

Maybe I can do some. I’m not a crack in Maths and Physics, but that I can do.

#13

I could also help out documenting :wink: That’s something, that

  1. will make you understand the code better
  2. will have very much use in the end
  3. it’s not so mind-tackling than writing new fancy code :wink: And you don’t get so easily stuck (As I got with my OctTreeSpace - I thought, I could build a Space-Structure with Subspaces and such. But now I’ve realized, that this will probably end up in a dirty hack. So I think I’m doing it in a way similar to how they did it in ODE) Nah - lets see - I’m currently doing so much thinking about algorithms and such (IOI training), that I rarely even start up eclipse now (And there is so much to do (i.e. because of that jogl change in Xith3d) )

So don’t bother, if I’m a bit inactive :wink:

Arne

#14

i was thinking that someone could make some simple tutorials about joode use in true program for example:

  • how to make connect two joints and simoulate them or something other…
  • resting contacts (like box falling from sky in ode)

it can be anything to show how to use joode , since it is first oficial bulid (in cvs) i think that you have made some code for testing etc… you could add it to cvs (and please in one jar file)

#15

Hey. Well I was trying to simplify the construction of simulations by refactoring the test cases. So now there is a class called SimpleWorld that bundles a Xith converter with a collision system and dynamics engine and creates some nice methods like createBox() which allows a box to be placed, and a step method that handles the collision system and steps the dynamic world AND rerenders your graphics.
Fleshing out that class would be great, as it is fairly neat at the moment. As would be providing documentation for it.

[quote]it’s not so mind-tackling than writing new fancy code
[/quote]
Hehe Arne, its harsh you had to learn the hard way. Porting is alot quicker and simpler if it can be done.

#16

[quote][quote]it’s not so mind-tackling than writing new fancy code
[/quote]
Hehe Arne, its harsh you had to learn the hard way. Porting is alot quicker and simpler if it can be done.
[/quote]
Hehe - I know, but you don’t understand the code you port half as good, as you do your own code. That was the experience I had with porting those Box-Box Collisions.

#17

Yeah. That Box Box code was nasty though. like those TST macro definitions and redefinitions. Urgh, they were unreadable… Most of ODE is not quite that bad … more or less :slight_smile:

#18

[quote]Hey. Well I was trying to simplify the construction of simulations by refactoring the test cases. So now there is a class called SimpleWorld that bundles a Xith converter with a collision system and dynamics engine and creates some nice methods like createBox() which allows a box to be placed, and a step method that handles the collision system and steps the dynamic world AND rerenders your graphics.
[/quote]
Whoops, I had not commited that code. I have just done a lengthy merge with the current version. Lots of conflicts, but it has meant I have had to commit unworking code which I do not really like to do. But I did not have much choice. So some of the Convex code is now in there. Do not look at it yet … it is pretty hard to read. But SimpleWorld is in there now. Its a wrapper for basic functionality. Kylix you might like to look at that…

#19

Oh yeah … one more final thing on SimpleWorld.java

It extends TestingWorld. TestingWorld has all the code for creating simple geometries that are connected to the graphics engine in single method calls. That is the way I want that class to work, so you can do everything in one method call. (less verboe when you are writing TestCases!)
It also allows you to link bodies with joints in one liners as well … but only linkSlider is implemented so far. I wonder if someone could carry with adding the rest of the functionality. Try and make the methods as general as possible, and not relying on Data objects passed in too much. So lots of floats instead of vectors please. (and a method for destroying bodies and joints … delegate to world.java)

But I would like some good functionality added to SimpleWorld as well. I would like some kind of proper implementation of a game loop. Something that automatically steps the world with a good implementation of timing. at the moment my test classes just sleep for x amount of millis, which gives inconsistant performance across different machines. I would like something that waits for a user specified time amount. Now this is not a trivial problem. Don’t fall into the System.currentTimeInMillis, thread.sleep() trap. There is lots of material on these forums for doing it properly. Bundle this functionality into a asyncronous method called run(). and create a sister method to stop the thing in a method called stop().