A few friendly suggestions for JOODE

Game Mechanics
#1

I figure that since joode is still a work in progress and that the authors actually frequent and respond on this forum, that it’s a good place to post some suggestions that I thought would be nice to include in physics engine.

  1. Quickly scanning through the api for joode, I was unable to find a heightmap shape. I think that it is a key feature in order to implement large scale terrain maps and still perform well. I know ODE has some plugins (not sure if it’s been moved to a core feature)

  2. I haven’t looked at the exacts of joode’s new step functions, but with the euler integration fast moving objects (ie bullets) could easily jump over the player’s intended target and they’d be none the wiser. I had a thought of implementing it with rays to get more continuous collision. Set the ray’s length to the approximate distance that the object would travel in a time step, and at each time step move it’s position to the tip of the previous ray and angle slightly down according to gravity. This would give an approximate path of the bullet while not skipping over anything, but it would be a nice feature if this were automated or somehow done more elegantly.

  3. I was sure I had another idea, but now I forgot it, so maybe I’ll post it once it comes to me again.

#2

Cheers for the suggestions.

  1. New collision shapes are not something I would like to prioratize at the moment. Its an incredible amount of work. Maybe heighmaps could be faked by putting lots of trimeshes together. However, trimesh-to-anything else colliders are not written either :confused:

  2. I have a plan for this actually. At some point I intend to implement apriori collision detection using the existing collision infrastructure. Each time step the last AABB is combined with the new AABB to form a space-time axis aligned bounding box. If intersections occur between these boxes we search for the first point in time the two objects intesect (if one exists). Some heuristics may be necissary to guide the search intelligently (eg, veloctity and size of geoms), and perhaps the routine will not be gauranteed to find a solution in every case, but it will solve the problem you mention (and for me it will solve lots of approximated dynamics related problems)

  3. Please do.

#3

Oh and as for your actual bullet problem, I think the better solution for now is:-
Create a ray that is velocty * 1/timestep * safteyFactor (e.g. 1.1) in size and attach it to a body. Then simulate as normal. The gravity will affect the body as normal, and the ray should never pass through anything. Rays are placable, so you do not need to manually move them every time step or calculate the effect of gravity on them.

modified:-
actually I don’t think that will work. The bullet will remain horizontal throughout its trajectory, while the path through space will be curved becuase of gravity. The ray direction is defined by the bodies rotation matrix which will remain constant. So the ray will not actually point in the direction of the path taken. Hmmm, I can think of various solutions but none of them elegant. It would be nicer if rays in JOODE were defined by a vector, so that they did not have to point in the Y axis direction (I think it is y). Hmmmmm, maybe that should go on the todo.

#4

The actual solution is not so important, since that part of the physics engine is not needed right now. However I did finally remember the 3rd idea, and I’m fairly sure that it’s been brought up before:

Switch to using javax.vecmath instead of using your own defined vector math classes since it would seem to allow for more portability.

And I have one other question, in the documentation for the util class Real, it says to use object pools instead of constantly creating new instances. I was wondering if all of the code you’ve written for your steppers and whatever else uses Real follows that guideline?

Thanks,

#5

Switching over to using pools is not complete. Last time I profiled though with java 1.6 there was no garbage once the simulation was up and running. This probably means what garbage is created, is able to be tidied up with the new features of 1.6.
I don’t often work on Collision detection, but I expect that has alot of departures from the project coding standards.

The use Vector math argument has gone backwards and forwards. Basically Vecmath is not sophisticated enough for our usage. Standard vecmath also creates garbage. We do use a bit of Open mail, but really we are looking for a really good vector library, something like MTJ, but with floats.

I think everyone agrees that having every game engine with its own vector implementation is bad for all of us, but there doesn’t seem to be an implementation that yet suits everyone. There are other reasons which mean that switching vector implementation is very hard for JOODE to actually do, and the benifits are not much other than its slightly nicer to interface with.

#6

@t_larkworthy : may I mention (since I’m the project owner of it :slight_smile: ) that OpenMali is open-source, welcome contributors and is open to changes ! As long as it’s backward-compatible with sun-vecmath (which mean don’t delete/rename methods/fields), you can add whatever is missing. We could even think about further change but then supporting Java3D would need an additionnal data-structure-conversion layer.