JOODE love

Game Mechanics
#1

Well, I’ve been trying off and on to get java-gaming.org to allow me to log in, and I still haven’t gotten any emails. Obviously I have gotten around it, but as you see I used a different id.

Anyway, I have a large patch for JOODE that increases performance and reliability (and making it easier to port directly from ODEJava), but I’m not sure how it should be submitted.

The patch is roughly 1400 lines worth of changed/added/deleted code.

I also have a question: why isn’t JOODE using javax.vecmath, instead of what appears to essentially be WildMagic geometric classes?

#2

Ok, ChrisM got my account straightened out. I’m back to my old self!

#3

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.

Marvin

#4

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)

#5

Well, and so I have.

Here is a list of what I have changed:

  • Most temporary calculation variables (Vector3, Matrix3/4, Quat4) are now class-level static, for much nicer memory usage
  • static-static collisions are ignored
  • dxBodyGravity flag for toggling effect of gravity on a body
  • dxBodyDisabled is honored
  • DOS CR/LFs removed
  • Added many “convention” methods to Body to make porting from ODEJava easier
  • You can now cap the number of interactions per step (World.maxStepInteractions)
  • Overall per-step memory usage is significantly reduced
  • Sphere colliders now jitter the contact so that spheres dropped straight down onto flat objects to not bounce up and down there forever.
  • Contact is now a ContactGeom, thus merging functionality (contact.geom. becomes contact.)
  • The basis class for TriMesh is added
  • The net.java.dev.joode.test.CollisionManager now uses simple JointContact caching

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.

#6

the fact that static-static collisions are ignored is most annoying for me… first I thought it was a bug, then I found out why in the code and I saw your post.

The issue is, I’m using JOODE Geoms without Bodies but I want collision detection because they are dynamic in my world (say, I use JOODE collision detection but not physic simulation here).

So this should be adjustable somewhere.

#7

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

#8

For now I use the (previously unused) skip parameter.
When 0, it does static-collisions. When 1, it skips static-static collisions.

#9

Sphere/Box collider should be fixed : depending on which side the sphere collide with the box, it goes through it…
biggeruniverse, if you have any idea…

#10

I’ll work on it.

#11

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.

#12

Do the collider really need to know something about velocity to detect collisions correctly ?

#13

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. :frowning:

#14

biggeruniverse,

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.

Art

#15

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!

#16

SURE ! @apope : great !

@biggeruniverse : Yeah I see what you mean with collision detection and how to “solve” a collision. But the step size is really small and it should be able to know from which side it comes !

#17

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

#18

Oh sorry Amos, you don’t have admin privalidges…
Anyway I am about again now.

#19

So cool to hear about you again !

Welcome back 8) (and thanks for admin access, we never know if you’re unavailable again for some months…)

#20

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.