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.
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)
There are compile errors with a “RadixSortedSomething” not found… anybody knows what is it ?
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.
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.
I’ve included a trimesh/trimesh collision test, plus unit tests for some low-level geometric operations.
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.
Art Pope
P.S. RadixSortToken was a late checkin, but should be there now, too.
irrisor,
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.