Maybe you want to talk to Amos Wenger. Even if he doesn't have admin privs and won't be able to give you dev rights. He has dev rights on the JOODE project and could commit your work. I personally would love to see your stuff committed.

As Marvin said, I'd also love to see your stuff committed.The thing is regular devs seems to have disappeared and I don't know... well I don't know what they think of it.Whatever, just send it to me (check your PMs)

Here's my TODO list, if people voice an interest in me making further changes:

Finish staticising temp variables

Migrate to javax.vecmath

TriMesh collisions

On the point of using static rather than temporary variables, I realize a debate could rage forever. I've found it useful at other times in maintaining light overhead, and reducing the necessity of GC cycles. For me, a physics engine should be as memory-transparent as possible.

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.

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?

I've just completed basic JOODE support for finding trimesh/trimesh collisions, and was about to commit the changes when I ran into your commits of two days ago. I'll merge with your changes before committing. One conflict: we've both defined a TriMesh class.

The trimesh implementation I've done is based on GIMPACT, which is available under a BSD-like license. So far, the implementation maintains per-triangle and per-mesh AABBs, finds tri/tri collision candidates by testing these, and goes on to detect any contact points between tris. Yet to be ported are GIMPACT's sort-based AABB colliding and merging of nearby contact points. I've used javax.vecmath for point and vector representations, and created unit tests.

Please let me know what plans you have for the TriMesh class you've already committed.

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.

Hello. Phew I have had quite a hectic last 6 months. Anyway, I have passed my masters now and am moving onto my PhD. It is in reconfigurable robotics research and it requires physics simulation which was rather my motivation for JOODE in the first place. A. Pope contacted me over christmas regarding JOODE submissions, he now also has developer access. Amos, sorry I have been away so long. I did change your privalidges to Admin, you should be able to do anything I can. Not sure when when I will be committing code into JOODE again. At the moment I am doing probabalistic stuff and I need that sorted before I get into simulation. It is looking like I am going to have to implement some non-linear constrained optimization algorithms, there may be some use in JOODE for that but I am not sure. Anyway, alot of reading to do.....

Speak to you all soon

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

I recently downloaded the JOODE source from sourceforge.net (using SVN). I understand this to be the active development repo.

I integrated it into a game framework I use with little problem. I ran an existing game with a couple of physics Body(s) added with the Java Interactive Profiler profiling the code. I noticed that getX() and getY() for Vector3 were eating up lots of CPU time due to the vast number of calls to them. I removed the getters and setters that simply access m[] underneath and replaced those calls with direct access to m[]. This significantly improved performance and thus the framerate. However, it is key to note that the I updated the game framework I am using refers to the Body (now .pos.m[]) to determine some things (e.g. whether or not to render in a view). So, the framework adds quite a few more calls to these getters than you would normally see in JOODE alone.

I wanted to mention this to see if this is something a developer for the project can refactor and checkin in SVN. I understand if its not a big deal for others, just an observation and something I had to change to keep using JOODE and it would be nice if it were checked in the repo too so I can keep up with the updates.

shasheppard, did you use a new JDK? (e.g. 1.5 or 1.6) It should do these optimization on it's own after a high number of invocations. Additionally: did you compare the framerates without profiling enabled? (profiling instrumentation/listener really distorts the measurements)

I've committed code for representing trimeshes and finding trimesh/trimesh collisions based on code from GIMPACT (used under a BSD-like license).

The trimesh representation uses vecmath's Point3f's for vertices, indices to identify the vertices in each triangle, an AABB for each triangle, and Geom's usual AABB for the entire mesh. Trimesh/trimesh collision detection, which is invoked once whole-Geom AABBs have been found to intersect, first finds intersections among per-triangle AABBs, then among their associated triangles. To find intersections among per-triangle AABBs, GIMPACT uses brute force testing of all possible pairs for small numbers of triangles, and sorting for large numbers; I've implemented only the brute-force search.

Note that other types of collisions (trimesh/plane, trimesh/box, trimesh/sphere, etc.) are not yet implemented; only trimesh/trimesh collisions are detected.

GIMPACT and my port of it both suffer from a problem that occurs particularly often among trimeshes with sharp (i.e., acute-angled) creases. Such geometry can allow one triangle to approach another one from the back and then, with only a small change in position, intersect it with one triangle still lying larger behind the other. This is then reported as a deep contact yielding a large repulsive force.

Btw, Vector3.normalize() is a bit odd in that it doesn't normalize the vector in the usual sense (i.e., leaving it with unit length). I've committed a comment noting this, but haven't changed it. Perhaps someone ought to look at it.

Yeah. I am using Java 1.6. I ran a few tests with JIP turned off, and I experienced some very similar results (actually, the difference was unnoticeable almost). After going back and removing all the calls to getX() and getY() from Vector3, I replaced the JIP settings to on. I then noticed that Matrix.get() is called several hundred thousand times in a short (<30 seconds) test run. The overall time spent in Matrix.get() was slightly higher (other times slightly lower) than what was spent in the rendering/drawing methods.

I do not want to go through and the types of changes required to remove references to this method. I am beginning to feel like there is something wrong with the way I am doing business, because why would I be the only one making these types of statements?

The only thing I am doing that I do not gather others are doing is using a home-grown game framework in pure Java. So, the sad fact may be that the framework is an inefficient hog, which brings out the JOODE shortcomings (well, perhaps they're not really shortcomings).

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org