You are a freaking genius. I could go back to writing 2D stuff based solely on how cool the demo was.

I like the idea of sharing code between the projects for the time being. I hope sincerely that Phys2D keeps simplicity and speed, while I'd like to see JOODE become highly configurable and full-featured, with several choose-able integrators and a priori detection. Both projects can benefit from going down slightly different paths.

look under branches/ , instead of trunk.

Indeed there seems to be some unfinished work in the build.xml file. Since I can't get a fix on Tom's mind to read it properly, I simply cleaned it up a bit. Should work now.

I'd say two mailing lists- one for SVN commits (I like to read them as they come), and dev: joode-dev joode-commit

Sure, but there are some MathUtils methods giving me trouble, plus I still don't see the point of the RealPointer class. Those are the only reason the vecmath patch is not complete.

After that, I assume it's easy to switch to openmali.

Tell you what, try out ODEJava and JOODE; they both use very similar APIs. For JOODE, check the examples. ODEJava is more mature, but JOODE is a pure-Java implementation.

For which Vectors are best. Come on everyone! Let's join the cascade!

I also noticed this when refactoring for static variable use, but mostly left it alone. I think though, that we should discuss it on the joode-dev mailing list:

http://sourceforge.net/mailarchive/forum.php?forum_id=51541

That's what I was getting at.


cool. I plan to commit the branch (mostly complete) this evening.

Don't take me as any indication of the larger project community. It is still a very young project, and has no general "spirit" yet. Tom has already stated he's happy with the contrib, and the thread is becoming an off-topic about Java portability when using "magic" algorithms that rely on specific standards and/or architectures.

I don't like to simply say "Thanks for the contribution, move along." I prefer a public discussion of the patch, what the submitter has done and why, as per the spirit and guidelines of the project. It leads to a better quality of patches. I'm not saying it has to be a hearing before a committee either, but it does not justice to the patch writer to simply take their patch and trash it.

I hope that you will contribute in the future, and I hope you will at least consider JOODE for volatile.

Try SPARC, anything MIPS, or Cell.


*Is JOODE accuracy v. speed configurable


Did they prove it in Java?

If you look at the change log, you will notice that this code is already in place (with a different initial value). I put it there myself (well, with Amos' help). However, I left it commented out, since there is currently no way to choose, nor was there a concensus on its use.

I'm on

How much force does the AMotor have?

o noes! Well, it's biggeruniverse. I know, I ought to be more creative...

Well, what accuracy is JOODE guaranteeing to the user? Is accuracy v. speed configurable? At what point of accuracy is this slower than Math.sqrt?


JOODE is Java, that code is converted C code. It was written to be close to the hardware, which of course makes me suspicious of it. Has this Java code been shown to work on any non-x86 environment? (It should of course, but better to test these things before they are relied upon to be always correct)


I hope we take it, as it is faster, but first it has to be proven out.


Well, first thing first, let me finish the conversion to pure vecmath. I'll branch it for easy testing, and then it can be decided what to do about optimizations.

Ok, it checks out for pure speed. But two hurdles remain:

1. Correctness of computed values
2. Portability to other platforms (and correctness there too)

Also, if it is decided that JOODE should use javax.vecmath throughout, we would rely on the vecmath implementation for vector length (Math.sqrt()):

https://vecmath.dev.java.net/source/browse/vecmath/src/javax/vecmath/Vector3f.java?rev=1.3&view=auto&content-type=text/vnd.viewcvs-markup

Because, as referenced here: http://www.java-gaming.org/forums/index.php?topic=15677.msg125477#msg125477 the biggest slow-down that JOODE currently experiences is in the implementation of the Real class, and its derivatives.

This code is in Real, but I left it commented out because it's no longer as fast to do it in integer as in floating point instructions. Esp. for Java, it's probably slower.

@t_larkworthy: I sent you a PM a while back! Check you PMs!

Actually, you are on the right track. I'm working on an entire fix for this but, as I'm sure you have seen, it will take time. There will also be time to test, and verify that the conversion has happened correctly. It is being worked on.

I'm not seeing any compile errors. Can you post some compiler output, or line numbers or something?

EDIT: looks like Art already uploaded it.

Actually, what I had planned (not sure if this is concensus) is to replace the internal geometry classes with javax.vecmath classes. This will take a little time to get changed and tested.

Actually, in testing most of the options, my personal favorite has been Groovy. pnuts has some odd little quirks.

What do you mean by "AI"? That's anywhere from path-finding to Neural Nets. What you use will really depend on what kind of gameplay you are going for, and will probably be a combination of several things.

Go ahead get rid of mine- it's a stub. I like that you used javax.vecmath, I've been planning to convert all of JOODE to using it. I found from traces that the slowest part of the collider was lookups of indices in the Matrix3/4 classes.

Anyway, I'm excited to see some trimesh collisions!

No, it can detect the collisions, but it won't know how to "fix" them correctly. If it sees that a sphere is inside a box, all it knows is exactly that. It doesn't know where the sphere or box came from, or where they are going, hence how can it know which side of the box the sphere entered from?

EDIT: I wish JOODE devs were around to talk to about this.

This entire forum thread is multiple sub-threads within the main thread, which I think is undue given the definition of the problem.

Anyway, never use a simple dictionary, always get the etymology of a word: http://www.etymonline.com/index.php?term=complex

I like the 1715 version.

Probably the quickest thing to do is make your step size half as big, and step the simulation twice per frame. That should help a lot of cases, though of course it will not help when the sphere still ends up within the box on the far side from where it entered. The problem is that the collider has no idea about the velocity of the body, and therefore cannot do tests a priori.

If you weren't at work I would kiss you.

EDIT:
@Markus_Persson: I know the ball flies through. That's why you use the lines and not the ball itself. Given oNyx' wikipedia reference, I've been describing an a priori method whereby you see if a collision will occur in the time step, and where it will occur. Then you place the ball at the position of line intersection (not quite of course, since the intersection is the on the edge of the ball) and give it a new velocity which is the mirror of the current velocity around the perpendicular to the paddle line.

steps:

1. (time step begins) calculate line that represents paddle, given current paddle orientation
2. fire ball velocity ray, get list of collisions, take the first one
3. if it intersects the paddle line (or any line technically, but the paddle line is special)
    place the ball at the intersection point, set new velocity, add paddle angular velocity to ball linear velocity
4. else update ball position by ball velocity
5. (time step ends)

And what do you mean pretending won't work? The entire thing is about pretending!

I'll work on it.

Hmm. Ok. Would adding something like World.ignoreStaticContacts (default value true) suffice?

Wow. You're right, that's phenomenally complex. But, I don't see where the *exact* time matters, only that the simulation is believable (i.e., if a collision occurs within the time step, which is usually pretty small, react). So let's cut out the idea of sub-steps. Let's look at each of the first row of cells as if each is a full time step. Assuming a time step <1/30 sec, I think that would be sufficiently close to "exact". Now it's simply as I said, the intersection of two lines. This method also ignores "contacts" where the paddle is technically within the sphere, but the sphere is moving away from the paddle (assuming you move the sphere line segment to the edge of the sphere. This is similar to what bleb was saying, with some simplification