JOODE Project Structure

Game Mechanics
#1

I suggest that we will do a cleanup of the JOODE project structure. Right now we have some kind of mess in the src directory, where the JOODE code is mixed up with test classes and code that is known not to be working completely. Additionally I think there are too many packages containing only two classes. I think we should aggregate some of them.

My proposal:


+ src
    + java				the pure JOODE source code
        + net.java.dev.joode
            + collision 		collision stuff
            + geom			geometry classes
            + joint			joint implementations
            + space			space classes
            + stepper			stepper interface + implementations
            + util			utility classes (check what is needed and what is obsolete)
            Body.java
            Mass.java
            World.java
            WorldObject.java
    + test
        + net.java.dev.joode		put here all the test classes
    + samples				put here some sample applications and tutorial code
+ contrib				this is a place where everyone can contribute code and documentation (give write access to anonymous user)
+ doc					the project documentation
+ lib					external libraries
+ build					directories used for builds
+ dist					packages for distribution (joode.jar, joode-src.jar, joode-api.jar, etc.)

Additionally we should think about how far we would like to integrate the Xith Binding into the JOODE source code, and if we want to add bindings for other rendering frameworks (e.g. Java3D or JME). Maybe we should add an additional package for that.

Tell me please what’s your opinion about a restructuring of the project.

#2

I think it’s good.
But for the .jar files, I suggest having :
joode.jar
joode-test.jar
joode-xith3d.jar
(joode-jme.jar)

#3

[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:27244"]
I think it’s good.
But for the .jar files, I suggest having :
joode.jar
joode-test.jar
joode-xith3d.jar
(joode-jme.jar)
[/quote]
That are just examples to demonstrate the usage of this folder.

#4

I think, it would be better, if the testcases would also be structured, like they are now:
net.java.dev.joode.test.joints
net.java.dev.joode.test.collision
net.java.dev.joode.test.space

else it looks pretty ok - maybe only the collision stuff could be splitted up more (e.g. for all this Convex-Hull collision code, and the collider-implementations itself should go in a seperate package)

#5

I agree, the testcases should have the same structure like the src packages. More subpackages are OK as well, as long as we will aggregate a centain functionality there, that consists out more than one or two classes.

Where I am not quite sure is what are tests and what are samples. On the one hand most of the code in the test package right now are moreover visual tests than unit tests. On the other hand they are nice samples as well :wink:

I would suggest that we will put only real testcases (unit tests) in the test folder and all “tests” that have a presentation will go to the samples folder.

#6

I think, all those Collider-Tests should be kept in the test packages. There is really actually only the collider tested (if we ignore the LCP part)
Also, I think, simple JointTests should go into the test packages.
Also the space-tests should stay in test.
I think, in samples should go testcases, were the interaction of different testcases is shown. e.g. several joints connected by each other, a car example, Isvans demo…

#7

Does anyone know if there is a possibility to get a shell access to the CVS repository an Sourceforge. If there is no way we will loose the current history for the code when doing the repackaging.

#8

mmh that would be really bad :frowning:

isn’t there Subversion available now at sourceforge?
so if we move all that, we could also migrate to subversion - I believe subversion supports the moving of files and such…mmh it would be even better if a move to subversion would keep the old history…anybody some informations on that?

#9

The developer CVS at Sourceforge is currently down and will be up only until tommorow again. Currently we can’t do anything.

Subversion is nice, but it is not necessary - at the moment. I do not have any experience with moving content from CVS to Subversion either.

#10

I know there is a script “cvs2svn” that is supposed to move stuff over to a Subversion repository and keep the history as best it can.

#11

maybe this clears it a bit up (just found it):

http://sourceforge.net/docman/display_doc.php?docid=29894&group_id=1

you should take a look at Chapters 15 to 17.

#12

Thanks for that hint. So we should really think about moving the project to Subversion. The migration should be quite easy - as long as the CVS server is available again (see https://sourceforge.net/docs/E09#import)

I do not know if we need t_larkworthy for doing this, but I can access the forms for setting up subversion and migrating CVS tarballs to th Subversion project. So I think I can do this as well :wink:

#13

Sourceforge CVS is up again. I just tried to setup a Subversion repository for JOODE, but it looks like I do not have permissions to do this. So we need t_larkworthy for setting up Suversion for JOODE.

#14

Hello everyone. I will move the project over to Subversion next week. My last exam is on Wed but I have visitors for the weekend so I will do it on Tue-Wed next week. Then I can get back to JOODING yay!

#15

OK, great. I am heavily waiting on this, so we can get something on again.

Could you please assign the right to create tasks to me on Sourceforge, so we can track the todos in sourceforge?

#16

I just added a Todo list to the webpage. This is no tracker, but it should give a overview of the status of JOODE.

#17

Ok - I fixed that JointSlider stuff, the testcase now works, there wasn’t a bug in the Joint, but in the testcase (sign error)
mmh … sourceforge seems to down again…or do we already have subversion?

#18

OK hdietrich and arne. I have put you on task trackers. Finished all my exams now. Woo! can JOODE again soon :slight_smile:

#19

Great, I hope your exams were successful :wink:

As soon as I find some time I will move the tasks from the homepage to the Sourceforge tasks and put a link to the page on Sourceforge.

#20

I have a very simple test for the JointSlider involving a Box and nothing else. This is nearly the same as SingleBodySliderTest, but it fails. Am I doing something wrong?


package net.java.dev.joode.test.joint;

import javax.vecmath.Vector3f;

import net.java.dev.joode.body.Body;
import net.java.dev.joode.geom.Box;
import net.java.dev.joode.joint.JointSlider;
import net.java.dev.joode.test.SimpleWorld;

public class SliderTest extends SimpleWorld {

	public SliderTest() {
		super(true);

		Box box1 = new Box(this.space, 2, 2, 2);
		Body body1 = new Body(this.world);
		body1.pos.setY(4);
		body1.pos.setX(-4);
		body1.mass.setBox(1, box1.getSide().getX(), box1.getSide().getY(), box1.getSide().getZ());
		box1.setBody(body1);
		this.gfxManager.addBinding(box1, this.view.getScene());

        JointSlider slider = new JointSlider(this.world);
        slider.attach(body1, null);
        slider.setAxis(1, -1, 0);
        
		view.getView().getTransform().lookAt(new Vector3f(0, 0, 10),
				new Vector3f(0, 0, 0), new Vector3f(0, 1, 0));
	}

	public static void main(String[] args) throws InterruptedException {
		SliderTest test = new SliderTest();
		while(test.fps.runs()) {
			test.step();
		}
	}

}

Slowly I hazard a guess that there is something wrong with the moment of inertia created for a box…